How fast is this query?
SELECT id
FROM msg_body
WHERE MATCH(body) AGAINST( 'WORD')
If it's fast , you may have to re-state your query so that you are not FT
searching and joining tables in the same statement. The optimizer can only
use 1 index at a time from any table. We may be running into a
Hi Fredrik,
a LEFT JOIN could be faster (I'm not sure, try it). And you don't have a
fulltext index on msg_header.list.
What about this?
SELECTmsg_header.bodyid, msg_header.id, msg_header.subject,
msg_header.mfrom, msg_header.date, msg_header.list
FROM msg_header
LEFT JOIN msg
Hi all,
I'm running a small mail archive and have a little problem with the
fulltext search performance.
I really appreciate any tips/design suggestions (even if it dont have to
do with the search problem ;) ).
Database schema:
mysql> describe msg_header;
+-+--+--+-+-
I am considering an upgrade on our server from 512 megs of RAM to 1 or
possibly 1.5 gigs, and would like to know if I'm going to get a
significant performance boost. Any suggestions or information is much
appreciated. Our configuration is as follows:
The table has around 100,000 records (but will
Hi!
On Nov 21, Mike Hunt wrote:
>
> All we want is for something like
>
> SELECT * FROM book WHERE MATCH(author) AGAINST
> ('stephen') AND MATCH(author) AGAINST ('king') LIMIT
> 100 /* these queries are ALWAYS limited like this */,
> a pretty normal kind of query, to return in an
> acceptable
We are having very serious performance issues (the
client is angry, very angry) with full-text searches
that return a large number of results. The problem is
roughly as follows:
we have a 2-million record database of books, a bit of
a mess, each record is a mass of unstructured data.
A search t
> Possible fixes:
o Maybe (I know we've talked about this before), another solution is to have
the FT index in another file which could have its own cache size settings.
o Lastly, we could switch to using word tables that would use already
optimized caching of table and index data, but would req
