Why are my MySQL queries on large tables with text field extremely slow despite index and supposedly small query times?

Question

I'm running a MySQL databases and access it through php for my website (LAMP stack). The database is filled with days (=~ separate tables) that contain log data for certain devices. Each row contains some IDs, a timestamp and a text field (up to 200 characters). On that text field, a fulltext index is applied.

My queries are now rather simple and of the following form:

SELECT [timestamp,ID,text] 
FROM TABLE_FOR_THAT_DAY 
WHERE MATCH(text) 
AGAINST('+ONEWORD' IN BOOLEAN MODE);

Having tested the query via a phpmyadmin-interface and via php (without fetching the rows), I can only say the performance is really bad. The tables contain about 100 million rows each, and the result set roughly 500000.

I'm full aware that -for this purpose- a relational database is not the best option, but I can't change this circumstance.

Puzzling to me now is the fact that in the phpmyadmin interface, the query time shows times between 0.5s up to 7.5s, while the actual loading time is 5min+... At first I thought this was due to the fact that this is a remote server and the actual data transfer might take long, but testing it locally via a php-script showed the same results in terms of performance. The machine has 8gb of RAM and a good CPU (Intel Xeon Gold 6140, 2.3GHz, 8Cores), which is never working at full capacity.

Now the actual questions: Why is there such a strong discrepancy between the shown query time and the actual loading time? Is it memory based? Can I reduce the overall query/loading time (I tried several InnoDB buffer options, but to no effect.)?

Many Greetings

Answer 1

Here's something to try to get the raw query time:

SELECT AVG(LENGTH(text)) FROM .. WHERE MATCH ..

That will be required to do all the I/O work to pick the rows, but not the time to send them.

Run that twice -- There could well be I/O caching issues that interfere with understanding how long the query takes.

Please provide the AVG returned by the query; it may include another clue. After all, 500K rows takes a lot of time to send across the wire, and a lot of space to instantiate in PHP.

FULLTEXT is the best way to search for such data; don't rush to other solutions.

I am confused as to "query time" versus "load time". The above query may address the "query time". However, all 500K rows must be fetched from disk and "loaded" into the server's RAM, then transmitted and "loaded" into the PHP app. Those are separate servers? Which machine is phpmyadmin on?

There are two ways to fetch data. The default for PHP is to pull all 500K rows before letting you do anything with them. The alternative pulls a few at a time, giving you the illusion that it is faster. In reality, it takes longer to get all 500K.

You say "I'm not fetching the complete table". My point is that it is probably happening inside the PHP API.

Meanwhile, I don't know which method phpmyadmin uses.