LIKE is faster than FULLTEXT search in MySQL

Question

I have a table called documents that have around 30 columns, around 3.5 million rows at a size of about 10GB. The most important columns are:

system_id , archive_id , content , barcodes , status and notes .

As you can see this is a multi-tenant application where each tenant is a system and references through system_id .

I have 2 indexes on this table where the first one is a BTREE and have the columns system_id , archive_id and status in it's index.

The other one is a FULLTEXT index containing the columns content , barcodes and notes .

I have two different tenants that I want to highlight. The first one (Customer A) has system_id = 1 and have say 1000 records in the documents table. The second one (Customer B) have system_id = 2 and say 400 000 records in this table.

The LIKE query for Customer A is:

SELECT * 
FROM documents 
WHERE system_id = 1 AND
      CONCAT_WS(' ',content,barcodes,notes) LIKE '%office%' AND
      status = 100

The above query will run in about 0.02 seconds. If I run a similar query but with the FULLTEXT search like

SELECT * 
FROM documents 
WHERE system_id = 1 AND
      MATCH(content,barcodes,notes) AGAINST ('office' IN BOOLEAN MODE) AND
      status = 100

This operation takes around 4 seconds?. I have read that the FULLTEXT search index should be a lot quicker than LIKE.

If I run the same queries but for Customer B (that has 400 000 records in the documents table) the LIKE search is a little bit slower than FULLTEXT but not with a lot.

• What can the reason for this be?
• Should I go with LIKE or FULLTEXT search in above situation (8GB RAM database server)?

I'm a little bit confused of why my queries with FULLTEXT search is taking so long. The text in content is probably not just words that a normal person would use because it's OCR-read from the document so there will be a lot of different words that might blow up the index?

Answer 1

The EXPLAINs will show that the fast query is using your index on system_id and status, not the LIKE. It was fast, not because of LIKE, but because of that filtering.

And the slow query decided to use the FULLTEXT index because the Optimizer is too dumb to realize that lots of rows contain "office".

LIKE , especially in conjunction with CONCAT_WS is not faster than FULLTEXT .