MySQL Fulltext Index Stopwords
The list of stopwords is essential if you’re thinking of using MySQL’s FULLTEXT index type, and it hasn’t been mentioned in other places I’ve seen the fulltext index discussed.
One Comment
→
-
Recent Articles
- tcprstat – TCP response time
- Sorting a ListBox of ListItems the WPF Way
- Trek Tech Today
- Oracle’s Really (not) Ruining Things
- Windows 7 Home First Boot Experience
- The Precise Amount of Luck that US Air 1549 Experienced
- Organization on the Mac / OneNote Replacement
- Why I Don’t Program Much Anymore
- Flux for OSX – Ding Dong, Dreamweaver’s Dead
- WordPress 2.9 and ACLs
-
Categories
-
Archives
- September 2010
- August 2010
- July 2010
- May 2010
- April 2010
- March 2010
- February 2010
- January 2010
- November 2009
- October 2009
- September 2009
- August 2009
- July 2009
- May 2009
- April 2009
- March 2009
- February 2009
- January 2009
- December 2008
- November 2008
- October 2008
- September 2008
- August 2008
- July 2008
- June 2008
- May 2008
- April 2008
- March 2008
- February 2008
- January 2008
- December 2007
- November 2007
- October 2007
- September 2007
- August 2007
- July 2007
- June 2007
- March 2007
- October 2006
I would heavily dissuade you from letting MySQL do full-text searching. It is currently very slow and you will take a big hit in system resources. Instead, I would suggest you consider some other alternatives, like Sphinx or Lucene. I can’t say much for Lucene, as I haven’t used it personally, but we used Sphinx originally for full-text searching, which it can do within a fraction of a second for even complex searches. However, since the most recent version, it also supports adding filters on other fields, which means that you can with a bit of effort effectively discard sending complex queries to MySQL on large datasets, instead letting Sphinx do the heavy work and passing the id’s to MySQL to get the resulting records… and all very very very fast.