A few things:

If you are importing a lot of data in a batch it is probably faster to disable indexing during the import (by defining CA_DONT_DO_SEARCH_INDEXING as a constant to true) and then do a single reindex after the import.

What are the odd results? Please report indexing bugs so they can be fixed. In theory 4gigs of text should not be a problem for the MySQL Fulltext engine, but you never know... it has all sort of surprises. On the other hand we have been consistently surprised at how well it works. It was originally started as a quick hack so we wouldn't have to use PHP Lucene (which is still supported, but really really slow) or set up SOLR (which works great, but is work to set up) for smallish systems. It turns out to work nicely for even pretty large datasets (and most museum data sets rarely exceed "pretty large" in scale). We've yet to see anything so large that it completely breaks, esp. if you tune the MySQL config and cache sizes. Did you bother to tweak your my.cnf yet?

One more thing: you can usually gain quite a lot of indexing performance by setting innodb_flush_log_at_trx_commit to 0 or 2 in your MySQL config (usually in /etc/my.cnf), rather than 1. However, the faster settings mean you may lose transaction data committed within 1 second of a crash. See http://dev.mysql.com/doc/refman/5.1/en/innodb-parameters.html for more information, and to figure out if the potential loss of small amounts of data in a crash is worth it for the performance gains (in our experience it is).

There are at least a handful of users running SOLR that we know about. I'll try to get some of them to post.

seth