MySQL-改善慢查询性能

Question

Iam running my Rails application with MySQL. I started reviewing my MySQL slow query log and I saw there were around 6000 lines which has mostly repeated the following query.

SET timestamp=1488423689;
SELECT COUNT(*) FROM `system_events`
    WHERE (notified
      AND id != 476200
      AND customer_id = 1
      AND classification = 50039
      AND created_at >= '2017-02-27 03:01:26');
# Time: 170302  3:01:49
# Thread_id: 2972915  Schema: ash####  Last_errno: 0  Killed: 0
# Query_time: 7.195183  Lock_time: 0.000029  Rows_sent: 1  Rows_examined: 26296  Rows_affected: 0  Rows_read: 26296
# Bytes_sent: 63

System Events Table

System Events Explain:

Does select count(*) have performance issues? How to resolve them?

Answer 1

The issue is that you only have single column indexes, while the where criteria would be served by a multi-column index. MySQL tries to make up for by using index merge, but that is not as efficient as using a single index.

I would create a multi-column index on customer_id , classification , and created_at fields and I would also move the notified field back of the where criteria (it should be the last condition.

Based on how you use the notified field, it seems to be a Boolean field with 0 or 1 value. Therefore adding it to an index will not really increase the selectivity of the index.

Answer 2

INDEX(notified, customer_id, classification, created_at)

created_at needs to be last; the rest can be in any order.

• With all 4 columns only the relevant number of rows will be touched.
• Leaving out notified requires looking at more rows, and having to skip over any with the wrong value for that column. (Hence, I disagree with @Shadow on whether to include notified .)
• The existing indexes did an "index merge intersect" of two columns, which is probably always slower than having a composite index.

• Without seeing SHOW CREATE TABLE , I cannot say whether the following "covering" index might be better, or whether it implicitly exists:

  INDEX(notified, customer_id, classification, created_at, id)

If you are not expecting 2 billion customers, consider using something smaller than a 4-byte INT . A 2-byte SMALLINT UNSIGNED allows up to 64K ids. (Ditto for other INTs .)