mysql - 有时 MySQL 会停止使用正确的索引

Question

我有好几次遇到这样的情况:在没有任何更改的情况下，快速运行的查询在一瞬间开始运行速度慢了 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毫秒

Answer 1

如果表已更改，您可以尝试运行 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)'

假设较旧的数据具有更稳定的统计数据，并且造成差异的不是大小。