Mysql 不正确的优化器工作

Question

我有下一个 innodb 表：

CREATE TABLE events (
  id bigint(20) UNSIGNED NOT NULL AUTO_INCREMENT,
  server int(11) UNSIGNED NOT NULL,
  internal_id bigint(20) UNSIGNED NOT NULL,
  pid int(11) UNSIGNED NOT NULL,
  event_datetime DATETIME NOT NULL,
  event_stamp int(11) NOT NULL,
  status tinyint(3) UNSIGNED NOT NULL DEFAULT 1,
  PRIMARY KEY (id),
  INDEX IDX_events (event_stamp, pid),
  INDEX IDX_events2 (event_stamp),
  UNIQUE INDEX UK_events_hash (internal_id, server)
)
ENGINE = INNODB;

记录数为 ~ 5 百万。当我执行下一条 SQL 时：

EXPLAIN SELECT SQL_NO_CACHE id, internal_id, pid, status FROM events WHERE event_stamp BETWEEN UNIX_TIMESTAMP('2017-01-01') AND UNIX_TIMESTAMP(CURDATE());

Profiler 说有 2 个可能的索引，但没有使用。总执行时间为 0.105 毫秒。然后我添加“FORCE INDEX (IDX_events2)”，分析器说使用了索引，总执行时间为 0.02 毫秒。

那么为什么优化器认为不使用 index 并遍历大约 200 万条记录比使用 index 更快？使用索引执行得更快，而且合乎逻辑。

解释输出：
1 SIMPLE c (null) ALL IDX_events,IDX_events2 (null) (null) (null) 5944539 50 Using where

并且用力：
1 SIMPLE c (null) range IDX_events2 IDX_events2 4 (null) 2972269 100 Using index condition

Answer 1

大多数数据库使用B树进行索引。在这种情况下，数据库优化器不使用索引，因为它在没有索引的情况下扫描速度更快

2mil / 5mil > 20%，我猜做表扫描比使用索引更快。索引并不总是最好的解决方案Avoid full table scan

当 MySQL 使用 全表扫描以解决查询。这通常发生在 以下条件：

您正在使用低基数的键（许多行与键匹配 值）通过另一列。在这种情况下，MySQL 假设由 使用密钥它可能会进行许多密钥查找和一个表 扫描会更快。

在您的查询中使用范围运算符。在大多数情况下，它可以更快地避免索引扫描。当您创建索引时，扫描索引页面以查找匹配项的成本更高。