SELECT语句不使用possible_keys

我有一个没有主键的遗留系统表。它记录在工厂发放材料的交易数据。SELECT语句不使用possible_keys

为了简单起见，可以说每行都包含job_number，part_number，数量为& date_issued。

我在发布的日期列中添加了一个索引。当我运行一个EXPLAIN SELECT * FROM issued_parts WHERE date_issued> '20100101'，它显示了这一点：

 
+----+-------------+----------------+------+-------------------+------+---------+------+---------+-------------+ 
| id | select_type | table   | type | possible_keys  | key | key_len | ref | rows | Extra  | 
+----+-------------+----------------+------+-------------------+------+---------+------+---------+-------------+ 
| 1 | SIMPLE  | issued_parts | ALL | date_issued_alloc | NULL | NULL | NULL | 9724620 | Using where | 
+----+-------------+----------------+------+-------------------+------+---------+------+---------+-------------+

所以它看到的关键，但它不使用它呢？有人可以解释为什么吗？

来源

2011-03-31 Paul Wieland

命名一个'key'列不会使它成为一个。虽然我没有完全理解这个问题，但是如果您想要这种功能，请将'key'列作为主键。如果不是，你需要提供更多的信息（比如当前的模式）。 – 2011-03-31 17:25:32

东西告诉我MySQL查询优化器正确决定。

以下是你可以告诉。运行这些：

行计数的行符合查询条件的

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

如果你实际上是在检索的行数超过了表的总数，MySQL的5％

SELECT COUNT(1) FROM issued_parts;

计数查询优化器决定执行全表扫描将会花费更少的精力。现在

，如果您的查询更精确，例如，本：

SELECT * FROM issued_parts WHERE date_issued = '20100101';

那么，你会得到一个完全不同的解释计划。

来源

2011-03-31 18:33:32 RolandoMySQLDBA

您的答案在技术上是正确的，但“MySQL查询优化器正确决定”不是。我或多或少处于相同的情况，在我的情况下使用密钥（强制它）使查询更快。 – 2013-01-14 11:38:03

我从200k中获得1500条记录。仍然没有使用可用的密钥。 – kellogs 2013-10-21 11:47:51

我也是...在709,743中有15,080 – 2014-07-11 13:47:51

possible_keys带有相关列的名称键，但这并不意味着它中的每个键都将对查询有用。在这种情况下，没有。

来源

2011-03-31 18:44:25

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

另一方面，B-Tree索引可以帮助您，因为它对正在索引的元素进行排序。例如，请参阅：http://dev.mysql.com/doc/refman/5.0/en/mysql-indexes.html for mysql（搜索B树索引特征）。您可能想要检查您的表是否在其索引列中使用了b-tree索引。

来源

2011-03-31 18:56:12 Zak

SELECT语句不使用possible_keys

回答

相关问题