当表有其他字段时，Mysql 不使用 DATETIME 索引答案

【问题标题】：Mysql not using DATETIME index when table has other fields当表有其他字段时，Mysql 不使用 DATETIME 索引
【发布时间】：2011-07-30 22:46:06
【问题描述】：

我需要一些帮助来解决这个问题。我正在尝试让 Mysql 在 DATETIME 字段上使用索引。

如果表中有其他（未使用）字段，Mysql 决定不使用索引。考虑以下两种情况：

一个包含 2 个字段的简单表格可以正常工作：

DROP TABLE IF EXISTS datetime_index_test;
CREATE TABLE  datetime_index_test (
id INT UNSIGNED NOT NULL AUTO_INCREMENT ,
created DATETIME NOT NULL ,
PRIMARY KEY (id) ,
INDEX (created)
) ENGINE = InnoDB ;

INSERT INTO datetime_index_test (created) VALUES
('2011-04-06 00:00:00'),
('2011-04-06 01:00:00'),
('2011-04-06 02:00:00'),
('2011-04-06 03:00:00'),
('2011-04-06 04:00:00'),
('2011-04-06 05:00:00'),
('2011-04-06 06:00:00'),
('2011-04-06 00:00:00');

EXPLAIN SELECT * FROM datetime_index_test
WHERE created <= '2011-04-06 04:00:00';

+----+-------------+---------------------+-------+---------------+---------+---------+------+------+--------------------------+
| id | select_type | table               | type  | possible_keys | key     | key_len | ref  | rows | Extra                    |
+----+-------------+---------------------+-------+---------------+---------+---------+------+------+--------------------------+
|  1 | SIMPLE      | datetime_index_test | range | created       | created | 4       | NULL |    4 | Using where; Using index |
+----+-------------+---------------------+-------+---------------+---------+---------+------+------+--------------------------+

一个有 3 个字段的简单表格，不能正常工作：

DROP TABLE IF EXISTS datetime_index_test;
CREATE TABLE  datetime_index_test (
id INT UNSIGNED NOT NULL AUTO_INCREMENT ,
created DATETIME NOT NULL ,
user int(10) unsigned DEFAULT 0,
PRIMARY KEY (id) ,
INDEX (created)
) ENGINE = InnoDB ;

INSERT INTO datetime_index_test (created) VALUES
('2011-04-06 00:00:00'),
('2011-04-06 01:00:00'),
('2011-04-06 02:00:00'),
('2011-04-06 03:00:00'),
('2011-04-06 04:00:00'),
('2011-04-06 05:00:00'),
('2011-04-06 06:00:00'),
('2011-04-06 00:00:00');

EXPLAIN SELECT * FROM datetime_index_test
WHERE created <= '2011-04-06 04:00:00';

+----+-------------+---------------------+------+---------------+------+---------+------+------+-------------+
| id | select_type | table               | type | possible_keys | key  | key_len | ref  | rows | Extra       |
+----+-------------+---------------------+------+---------------+------+---------+------+------+-------------+
|  1 | SIMPLE      | datetime_index_test | ALL  | created       | NULL | NULL    | NULL |    8 | Using where |
+----+-------------+---------------------+------+---------------+------+---------+------+------+-------------+

最后，我的问题； 谁能给我解释一下为什么Mysql决定不使用索引？

【问题讨论】：

扫描仅包含 10 条左右记录的索引是浪费时间，因为全表扫描需要大约相同的时间，所以 mysql 只进行全表扫描。尝试添加几千条记录，看看情况是否会发生变化。
@Mark 谢谢你的建议。我尝试添加 20000 条记录并做了一个分析表。 EXPLAIN 仍然给了我相同的结果，并搜索了 20008 行（选择类型仍然是 ALL）。

标签： mysql optimization indexing innodb

【解决方案1】：

这是由于我称之为基于关键群体（元组基数）的 5% 规则。

如果您索引存在不平衡基数的表，MySQL 查询优化器将始终选择阻力最小的路径。

示例：如果一个表有一个性别列，基数是两个，M 和 F。

你是什么索引这样一个性别列？？？你基本上得到了两个巨大的链表。

如果您将一百万行加载到具有性别列的表中，您可能会得到 50% 的 M 和 50% 的 F。

如果键组合的基数（我所说的键填充）超过总表数的 5%，则索引在查询优化期间将变得无用。

现在，关于您的示例，为什么两个不同的 EXPLAIN 计划？我的猜测是 MySQL Query Optimizer 和 InnoDB 作为一个标签团队。

在第一个 CREATE TABLE 中，表和索引虽然很小，但大小大致相同，因此决定通过索引扫描而不是全表扫描来支持索引。请记住，非唯一索引在其索引条目中携带每行的内部主键 (RowID)，从而使索引的大小几乎与表本身相同。

在第二个 CREATE TABLE 中，由于引入了另一列 user，您现在让查询优化器看到一个完全不同的场景：表现在比索引更大。因此，查询优化器对如何使用可用索引的解释变得更加严格。它符合我之前提到的 5% 规则。该规则惨遭失败，查询优化器决定支持全表扫描。

【讨论】：