为什么mysql使用错误的索引来按查询排序？

这是我的表，具有约10,000,000行数据

CREATE TABLE `votes` (
  `subject_name` varchar(32) COLLATE utf8_unicode_ci NOT NULL,
  `subject_id` int(11) NOT NULL,
  `voter_id` int(11) NOT NULL,
  `rate` int(11) NOT NULL,
  `updated_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (`subject_name`,`subject_id`,`voter_id`),
  KEY `IDX_518B7ACFEBB4B8AD` (`voter_id`),
  KEY `subject_timestamp` (`subject_name`,`subject_id`,`updated_at`),
  KEY `voter_timestamp` (`voter_id`,`updated_at`),
  CONSTRAINT `FK_518B7ACFEBB4B8AD` FOREIGN KEY (`voter_id`) REFERENCES `users` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

这是指数基数

因此，当我执行此查询时：

SELECT SQL_NO_CACHE * FROM votes WHERE 
    voter_id = 1099 AND 
    rate = 1 AND 
    subject_name = 'medium'
ORDER BY updated_at DESC
LIMIT 20 OFFSET 100;

我期望它使用索引，voter_timestamp 但是mysql选择使用它来代替：

explain select SQL_NO_CACHE * from votes  where subject_name = 'medium' and voter_id = 1001 and rate = 1 order by updated_at desc limit 20 offset 100;`

type:
    index_merge
possible_keys: 
    PRIMARY,IDX_518B7ACFEBB4B8AD,subject_timestamp,voter_timestamp
key:
    IDX_518B7ACFEBB4B8AD,PRIMARY
key_len:
    102,98
ref:
    NULL
rows:
    9255
filtered:
    10.00
Extra:
    Using intersect(IDX_518B7ACFEBB4B8AD,PRIMARY); Using where; Using filesort

而且我得到了200-400ms的查询时间。

如果我强迫它使用正确的索引，例如：

SELECT SQL_NO_CACHE * FROM votes USE INDEX (voter_timestamp) WHERE 
    voter_id = 1099 AND 
    rate = 1 AND 
    subject_name = 'medium'
ORDER BY updated_at DESC
LIMIT 20 OFFSET 100;

MySQL可以在1-2ms内返回结果

这是解释：

type:
    ref
possible_keys:
    voter_timestamp
key:
    voter_timestamp
key_len:
    4
ref:
    const
rows:
    18714
filtered:
    1.00
Extra:
    Using where

那么mysql为什么不voter_timestamp为我的原始查询选择索引呢？

我曾试图为analyze table votes，optimize table votes，丢弃索引，然后重新添加，但MySQL的仍然使用了错误的指标。不太明白是什么问题。

MySQL使用相对简单（比其他RDBMS简单）的成本模型来计划查询，其中过滤数据集具有很高的优先级。在您使用合并索引的第一个查询中，估计将需要扫描约9000行，而使用索引提示的第二个查询将需要18000行。 。您可以通过打开optimizer_trace，运行查询并评估结果来确认这一点（或找到其他原因）。

set global optimizer_trace='enabled=on';

-- run your query 

SELECT SQL_NO_CACHE * FROM votes WHERE 
    voter_id = 1099 AND 
    rate = 1 AND 
    subject_name = 'medium'
ORDER BY updated_at DESC
LIMIT 20 OFFSET 100;

select * from information_schema.`OPTIMIZER_TRACE`;

关于index_merge以下几点：在大多数情况下，您会发现它非常昂贵。尽管对于OLAP类型的方案非常有用，但可能不适用于OLTP，因为该操作可能会花费大量的查询时间，并且您可以看到有时次佳的执行计划实际上更快。

幸运的是，MySQL为优化器提供了开关，因此您可以根据需要自定义它。

对于所有选项，您都可以运行：

show global variables like 'optimizer_switch';

要更改一个，您无需复制就粘贴整个字符串。它的工作方式如dict.update()python。

 set global optimizer_switch='index_merge=off';

如果可能的话，我还将看一下您的表结构并进行改进。真正建议不要使用〜100字节的主键和许多辅助键。

您有四个辅助键，其中一些是多余的，例如(voter_id)index是(voter_id, updated_at)

对于该查询，您需要以下索引：

INDEX(voter_id, rate, subject_name, updated_at)

的updated_at必须是最后一个; 其他三个可以任意顺序排列。（ypercube的三列索引不是很有用，因为它们在到达WHERE列之前不会结束ORDER BY列。）

添加此索引时，您可能会摆脱所有其他辅助键：

KEY IDX_518B7ACFEBB4B8AD（voter_id） -的FK可以使用我的索引键subject_timestamp（subject_name，subject_id，updated_at） -主要是多余的KEY voter_timestamp（voter_id，updated_at）， -可能是你的企图

使用4列索引，您就有机会优化“分页”并避免OFFSET。 请参阅此博客。

关于另一个主题...当我看到X_name和时X_id，我认为“规范化”正在进行中。我希望看到表中的这两列，几乎没有其他内容。我不希望在其他表格中看到这两者。

(voter_id, updated_at)不会过去，voter_id因为它尚未完成过滤（WHERE）。然后，由于另一个索引较小，因此将其选中。我的3列用于过滤，然后列ORDER BY。