9. Monitoring and fixing "slow queries" in MySQL

# Time: 090603 23:07:28
# User@Host: queuemetrics[queuemetrics] @ localhost [127.0.0.1]
# Query_time: 18  Lock_time: 0  Rows_sent: 3260  Rows_examined: 2474525
SELECT time_id , call_id , queue , agent , verb , data1 , data2 , data3 , data4
  FROM queue_log  WHERE  partition =’P001’ AND (time_id >= ’1243980000’ AND time_id<=’1577833260’)
  AND queue IN ( ’’, ’NONE’  , ’none’  , ’ABCD’ )
  ORDER BY time_id ASC , unique_row_count ASC;

18 seconds for what is essentially a simple query. Compare the "rows sent" versus "rows examined". There are 2.4m rows in the database. (2.4m rows is not a lot of data, I have worked on tables with 100m rows in them).

That can only mean our query is not using an index or our indexes are not working.

So, I did an "explain"…and saw that you do have a multiple column index and that it is being considered and in fact used. But the mysql query is still slow.

mysql> explain SELECT time_id , call_id , queue , agent , verb , data1 , data2 , data3 ,   data4   FROM queue_log  WHERE  partition =’asterbox4’ AND (time_id   >= ’1253608910’ AND time_id<=’1577836860’)     AND queue IN ( ’’, ’NONE’    , ’65’  , ’none’  , ’15’ )   ORDER BY time_id ASC , unique_row_count ASC;
+----+-------------+-----------+------+----------------------+--------------+---------+-------+--------+-------------+
| id | select_type | table     | type | possible_keys        | key | key_len | ref   | rows   | Extra       |
+----+-------------+-----------+------+----------------------+--------------+---------+-------+--------+-------------+
|  1 | SIMPLE      | queue_log | ref  | idx_sel,partizione_b | partizione_b | 22      | const | 310379 | Using where |
+----+-------------+-----------+------+----------------------+--------------+---------+-------+--------+-------------+
1 row in set (0.10 sec)

9.1. Prerequisites

  • A working QueueMetrics instance
~~~~~~~~~~~~~~~~~~~~~

9.2. Changes to QueueMetrics

None required.