我有好几次遇到这样的情况:在没有任何更改的情况下,快速运行的查询在一瞬间开始运行速度慢了 1000-10_000 倍。 MySQL 停止使用正确的索引,我必须使用 FORCE INDEX(..)
。查询具有 10-300M 条记录的大表时会发生这种情况。
MySQL:5.6.23(AWS RDS、db.r3.xlarge)
还有最后一期:
表1(175M记录)
CREATE TABLE `table1` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`site_id` int(11) NOT NULL,
`created_at` datetime DEFAULT NULL,
`type` varchar(25) DEFAULT NULL,
...
PRIMARY KEY (`id`),
UNIQUE KEY `index_table1_on_site_id_and_..._and_type_and_...` (`site_id`,`...`,`type`,`...`),
KEY `index_table1_on_created_at_and_site_id` (`created_at`,`site_id`),
KEY `index_table1_on_site_id_and_type_and_created_at_and_...` (`site_id`,`type`,`created_at`,`...`) USING BTREE,
KEY `index_table1_on_site_and_type_and_..._and_created` (`site_id`,`type`,`..._id`,`created_at`),
) ENGINE=InnoDB AUTO_INCREMENT=... DEFAULT CHARSET=utf8
表2(2M条记录)
CREATE TABLE `table2` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`table1_id` int(11) NOT NULL,
...
PRIMARY KEY (`id`),
...
) ENGINE=InnoDB AUTO_INCREMENT=... DEFAULT CHARSET=utf8
请求:
SELECT `table1`.* FROM `table1`
INNER JOIN `table2` ON `table2`.`table1_id` = `table1`.`id`
WHERE `table1`.`type` IN ('...', '...')
AND `table1`.`site_id` = ...
AND (table1.created_at >= '...')
AND (table1.created_at <= '...')
ORDER BY `table1`.`id` DESC LIMIT 30 offset 0;
约为 10-80 毫秒 现在 > 420 秒
带有FORCE INDEX
的请求:
SELECT `table1`.* FROM `table1` USE INDEX (`index_table1_on_site_id_and_type_and_created_at_and_...`)
INNER JOIN `table2` ON `table2`.`table1_id` = `table1`.`id`
WHERE `table1`.`type` IN ('...', '...')
AND `table1`.`site_id` = ...
AND (table1.created_at >= '...')
AND (table1.created_at <= '...')
ORDER BY `table1`.`id` DESC LIMIT 30 offset 0;
~85 毫秒
解释一下:
没有FORCE
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: table1
type: index
possible_keys: PRIMARY,index_table1_on_site_id_and_..._and_type_and_...,index_table1_on_created_at_and_site_id,index_table1_on_type,index_table1_on_site_id_and_type_and_created_at_and_...,index_table1_on_site_and_type_and_..._and_created
key: PRIMARY
key_len: 4
ref: NULL
rows: 9257179
Extra: Using where
*************************** 2. row ***************************
id: 1
select_type: SIMPLE
table: table2
type: eq_ref
possible_keys: ...
key: ...
key_len: 4
ref: db.table1.id
rows: 1
Extra: Using index
与FORCE
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: table1
type: range
possible_keys: index_table1_on_site_id_and_type_and_created_at_and_...
key: index_table1_on_site_id_and_type_and_created_at_and_...
key_len: 88
ref: NULL
rows: 499
Extra: Using index condition; Using filesort
*************************** 2. row ***************************
id: 1
select_type: SIMPLE
table: table2
type: eq_ref
possible_keys: ...
key: ...
key_len: 4
ref: db.table1.id
rows: 1
Extra: Using index
是否有任何解决方案可以避免这种不可预测的 MySQL 行为?我无法向所有请求添加 FORCE INDEX
,该怎么办?
附注:
SELECT * FROM `table1`
INNER JOIN `table2` ON `table2`.`table1_id` = `table1`.`id`
WHERE `table1`.`site_id` = ... ;
仅返回 122 条记录
P.S.S:疯狂,但请求在更宽的时间段内工作得更快
AND (table1.created_at >= '2016-07-01') AND (table1.created_at <= '2016-07-07)
420 秒
AND (table1.created_at >= '2016-06-01') AND (table1.created_at <= '2016-07-07)
85毫秒
最佳答案
如果表已更改,您可以尝试运行 ANALYZE TABLE
( http://dev.mysql.com/doc/refman/5.7/en/analyze-table.html ) 以同步更新统计信息。 InnoDB persists optimizer stats其中有一些limitations 。
根据日期范围,我还想知道如果您这样做的话是否会一样快
AND (table1.created_at >= '2016-06-01') AND (table1.created_at <= '2016-06-07)'
假设较旧的数据具有更稳定的统计数据,并且造成差异的不是大小。
关于mysql - 有时 MySQL 会停止使用正确的索引,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/38255894/