我有以下查询:
EXPLAIN SELECT *
FROM glean2_saves
WHERE username = '1d85d5aed8b02b3d6b0c155a563293ef'
AND ses_id = 'e4fa3ae216f5033fbd16d6c66370954c'
AND save_status =1
ORDER BY id DESC
结果是这样的:
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE glean2_saves ref save_status,username,ses_id save_status 2 const 286315 Using where; Using filesort
以下是我的索引:
Action Keyname Type Unique Packed Column Cardinality Collation Null Comment
Edit Edit Drop Drop PRIMARY BTREE Yes No id 331837 A
Edit Edit Drop Drop save_status BTREE No No save_status 3 A YES
Edit Edit Drop Drop nickname FULLTEXT No No nickname 7374 YES
Edit Edit Drop Drop username FULLTEXT No No username 7717 YES
Edit Edit Drop Drop ses_id FULLTEXT No No ses_id 11442 YES
我在右列上确实有索引,但为什么不使用它们?为什么它们在"可能的密钥"(save_status,用户名ses_id)中,但实际上只使用了一个"密钥":save_status
如果没有索引,查询时间太长(有时超过 15 秒),应该不到一秒。数据库超过 330k 个条目。
对于此查询,您需要一个涵盖where
和order by
子句的索引。 该指数将是:
glean2_saves(username, ses_id, save_status, id)
请注意,由于您正在执行相等比较,因此前三列可以按任意顺序排列。 但是最后一列需要为order by
id
.
至于为什么MySQL不使用单个索引。 假设合并where
子句的索引是一项繁重的工作,并且可能比扫描一个索引并测试其余列会导致更多的工作。