This posts neglects to mention a few key points about the FULLTEXT search....
1. You have to use MyISAM tables which dosen't support transactions like InnoDB tables do.
2. You need to make sure you adjust the FT MAX LENGTH parameter which I believe is 4 by default meaning you can search on 3 letter words like say "USB" for example
in addition to the peer comment to this one, using a 3rd party daemon is a way of taking load off your database. in addition, updates to the 3rd party daemon can be incremental ("deltas") or flat-out swapped. further, as the amount of information increases, searching all of it slows down. Sphinx lets you create clusters where the data is partitioned, the search executed on all of the boxes, and the results put together in the right order (with easy setup!) Further still, you can do impressive things like fulltext search on complex joins very fast. This is fast because you are actually doing the join ahead of time (google ETL) and then just searching on the combined, denormalized, data. This doesn't muddle up your schema and is very very fast.
A few additional alternatives if you're using InnoDB:
1. Lucene
2. Sphinx (already mentioned below - really easy to work with)
3. SOLR (built on Lucene and also very nice to work with)
If you're indexing Asian language content and doing things like keyword density analysis, etc. then the above will only get you so far without additional work. If you're only working on latin based languages, you should be fine.
Ummm... since no one seems to have mentioned this,
Use Postgres. Integrated FTS (with the new 8.2 i think versions). Complete transaction support, full ACID support, more obvious behavior and drastically better scaling.
1. You have to use MyISAM tables which dosen't support transactions like InnoDB tables do.
2. You need to make sure you adjust the FT MAX LENGTH parameter which I believe is 4 by default meaning you can search on 3 letter words like say "USB" for example