SELECT 语句不使用 possible_keys答案

【问题标题】：SELECT statement not using possible_keysSELECT 语句不使用 possible_keys
【发布时间】：2011-07-27 02:25:58
【问题描述】：

我有一个来自旧系统的表，它没有主键。它记录了工厂发放材料的交易数据。

为简单起见，假设每行包含 job_number、part_number、quantity 和 date_issued。

我在发布日期列中添加了索引。当我运行 EXPLAIN SELECT * FROM issue_parts WHERE date_issued > '20100101' 时，它会显示：

+----+-------------+----------------+------+------ ----------+------+---------+------+---------+-- ------------+ |编号 |选择类型 |表|类型 |可能的键 |关键 | key_len |参考 |行 |额外 | +----+-------------+----------------+------+------ ----------+------+---------+------+---------+-- ------------+ | 1 |简单 |已发行零件 |全部 | date_issued_alloc |空 |空 |空 | 9724620 |使用位置 | +----+-------------+----------------+------+------ ----------+------+---------+------+---------+-- ------------+

所以它看到了密钥，但没有使用它？谁能解释一下原因？

【问题讨论】：

将列命名为 key 并不能使其成为一个列。虽然我没有完全理解这个问题，但如果您想要这种功能，请将 key 列指定为主键。如果不是，您将需要提供更多信息（例如当前架构）。

标签： mysql select indexing explain

【解决方案1】：

有些事情告诉我 MySQL 查询优化器的决定是正确的。

您可以这样判断。运行这些：

行数

SELECT COUNT(1) FROM issued_parts;

匹配您的查询的行数

SELECT COUNT(1) FROM issued_parts WHERE date_issued > '20100101';

如果您实际检索的行数超过表总数的 5%，MySQL 查询优化器会认为进行全表扫描会更省力。

现在，如果您的查询更准确，例如，这样：

SELECT * FROM issued_parts WHERE date_issued = '20100101';

然后，您将获得完全不同的 EXPLAIN 计划。

【讨论】：

您的答案在技术上是正确的，但是“MySQL 查询优化器决定正确”不是。我或多或少处于相同的情况，在我的情况下使用键（强制它）使查询更快。
我从 200k 中获得了 1500 条记录。仍然没有可用的密钥。
我也是……709,743 人中有 15,080 人
@kellogs，@Serge，试试force key，对你有用吗？

【解决方案2】：

有多种类型的索引（索引？）。哈希索引是一种在给定特定值的项目上进行查找的快速方法。如果您有一堆要查询的离散值（例如，10 个日期的列表），那么您可以计算每个值的哈希值，并在索引中查找它们。由于您不是对特定值进行查找，而是进行比较，因此哈希索引对您没有帮助。

另一方面，B-Tree 索引可以为您提供帮助，因为它为它所索引的元素提供了排序。例如，请参见此处：http://dev.mysql.com/doc/refman/5.0/en/mysql-indexes.html for mysql (search for B-Tree Index Characteristics) 。您可能需要检查表的索引列是否使用了 b-tree 索引。

【讨论】：

【解决方案3】：

possible_keys 命名包含相关列的键，但这并不意味着其中的每个键都对查询有用。在这种情况下，没有。

【讨论】：