Today, while on the MySQL manual page, I typed in ‘select’ in the search manual box to confirm the SELECT syntax.
The result was not what I expected, the “SELECT” command. Instead I only got two options “Speed of SELECT …” and “Optimizing SELECT and …”.
Ok, well that’s not what I want, there is a suggestion box to the right so I pick the top option “mysql select”. Not only is this worse with “Type Conversion in …”, “Searching on Two Keys” I also get 3 totally useless “Keymatch” records
Download MySQL -http://dev.mysql.com/downloads/
MySQL Training – http://www.mysql.com/training/ KeyMatch
Buy MySQL Enterprise -http://shop.mysql.com/enterprise/
I know in the past just entering ‘SELECT’ worked, because I’ve been presently writing tests on JOIN syntax and I wanted to link in my blog reference.
Images of my searches.
Agreed, I never use MySQL’s built-in site search. If MySQL.com is trying to use MySQL technology for its site search, then this is a misapplication of “eating our own dog food” that’s more like the “not invented here” antipattern. MySQL is not a search engine!
Instead, they should just embed a Google Custom Search box. It’s super easy. See:
See http://www.google.com/coop/cse/
The same applies to quite a few other vendor websites, by the way.
I have found that plain old Google searches do a great job of finding what you want in the MySQL documentation. For example, a Google search on “mysql select” gives:
MySQL :: MySQL 5.1 Reference Manual :: 12.2.8 SELECT Syntax
as the very first result!
Hi!
Don’t use MySQL Fulltext
Take a look at sphnix. There are much better solutions to fulltext search that are now available.
Cheers,
-Brian
That first comment by Bill is quite funny… The main problem here is that its not a custom custom search, but the Google Custom Search.
If my memories are right, that search used a real custom search once, a search that “understood” the mysql keywords, and showed the correct results (e.g. a link to the SELECT page in the documentation).
Google search obviously doesn’t understand this, so it tends to “break”, or at least fail badly.
Most likely, some extra foo HTML was added to the web pages, combined with the use of cookies and overtly strict search criteria, resulted in getting the limited results you see because the pages were deemed un-indexable.
Lets look at the headers…
HTTP/1.1 200 OK
Date: Tue, 07 Apr 2009 03:49:21 GMT
Server: Apache/2.0.58 (Unix) mod_ssl/2.0.58 OpenSSL/0.9.7f
Set-Cookie: MySQL_S=1b0cenjp0a404mhtfbsl5j0b3t80g7mm; path=/; domain=mysql.com
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Connection: close
Content-Type: text/html
Also, uncacheable pages tend to be unindexable too… Perhaps the site admin should consider changing the Apache config to serve pages to the search appliance which are cacheable and without cookies.
Just sysadmin/human error at work here. Otherwise, nothing to see.
For a command x description on the mysql.com site, search for ‘x syntax’. For example, to find the description of the SELECT command, search for ‘select syntax’. This usually makes the command the top hit in the search results.
MySQL site doesn’t use and never used MySQL Fulltext.
It uses Google appliance now – as you can see from the every screenshot above “Powered by Google Search Appliance”.
Easy fix… if you’re looking for “SELECT syntax” use that for your search term. “mysql select” is a pointless search after “select” because you’re already at mysql.com so every page should be about mysql. Being a Google Search Appliance serving up these queries I’d assume it it follows similar rules of page rank for the popularity of the page and number of times it is linked to. So it would seen that the SELECT syntax page is just less popular than the optimizing select page.
It works for me. I searched for ‘select’ in the ‘search manual’ box and got 2 results: select syntax, speed of select.