IN 子句不使用索引

Question

这是表定义

CREATE TABLE `dt_prdtime` (
  `TCompany` varchar(3) NOT NULL DEFAULT '',
  `TPerCode` varchar(8) NOT NULL,
  `TBegDateTime` datetime NOT NULL DEFAULT '0000-00-00 00:00:00' COMMENT 'วันที่',
  `TQPay` int(1) NOT NULL DEFAULT '2',
  `TYear` int(4) NOT NULL,
  `TMonth` int(2) NOT NULL,
  PRIMARY KEY (`TCompany`,`TPerCode`,`TBegDateTime`),
  KEY `TMonth` (`TMonth`) USING BTREE,
  KEY `TPerCode` (`TPerCode`,`TYear`,`TMonth`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8

这是数据样本。此表有 10000+ 条记录，TMonth 字段中的值各不相同

+----------+----------+---------------------+-------+-------+--------+
| TCompany | TPerCode | TBegDateTime        | TQPay | TYear | TMonth |
+----------+----------+---------------------+-------+-------+--------+
| S10      | 000001   | 2016-01-02 17:33:00 |     1 |  2016 |      1 |
| S10      | 000001   | 2016-01-02 07:48:00 |     1 |  2016 |      1 |
| S10      | 000001   | 2016-01-03 17:39:00 |     1 |  2016 |      1 |
| S10      | 000001   | 2016-01-03 07:30:00 |     1 |  2016 |      1 |
| S10      | 000001   | 2016-01-04 17:49:00 |     1 |  2016 |      1 |
| S10      | 000001   | 2016-01-04 07:54:00 |     1 |  2016 |      1 |
| S10      | 000001   | 2016-01-05 17:50:00 |     1 |  2016 |      1 |
| S10      | 000001   | 2016-01-05 07:36:00 |     1 |  2016 |      1 |
| S10      | 000001   | 2016-01-06 17:37:00 |     1 |  2016 |      1 |
| S10      | 000001   | 2016-01-06 07:35:00 |     1 |  2016 |      1 |
+----------+----------+---------------------+-------+-------+--------+

使用EXPLAIN，此查询使用TMonth 索引：

SELECT * FROM dt_prdtime WHERE TMonth = 5

虽然这个拒绝使用索引：

SELECT * FROM dt_prdtime WHERE TMonth IN (5,6)

我用另一个简单的表测试，

CREATE TABLE `table1` (
  `id` int(11) NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1

SELECT * FROM table2 WHERE id IN (5,6)

并且使用了该表的索引

谁能解释一下？ dt_prdtime 表有问题吗？

Answer 1

我会说这是因为您使用的是 MyISAM 引擎。

在我的Answer 中可以看出，它与 INNODB 完美配合。

我会尽量在这件事上找至少 1 个值得尊敬的参考资料。

这里，The range Join Type，显然是 INNODB 的焦点，因为它是默认引擎。并且当某些文档层次结构的手册中没有明确提及时，它是假定的。

注意，我的示例链接中的 id 没有任何连续性。意思是，不要在其 EXPLAIN 输出中过度关注type=range。速度是通过优化器（CBO）得出的。

在我的示例中，cardinality 非常高（430 万）。目标 id 计数相对较低（1000）。使用索引。

您的情况可能正好相反：您的基数可能非常低，例如 3，而优化器决定放弃使用索引。

要检查您的索引cardinality，请参阅手册页SHOW INDEX Syntax。

一个简单的调用如：

show index from ratings;

+---------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| Table   | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment |
+---------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| ratings |          0 | PRIMARY  |            1 | id          | A         |     4313544 |     NULL | NULL   |      | BTREE      |         |               |
+---------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+

Answer 2

MyISAM 和 InnoDB 在需要获取“太多”表时都不太可能使用索引。

IN (5,6) 可能意味着需要扫描表的 2/12？或者数据可能存在偏差，以至于这两个月的行数超过了他们的份额？

优化器可能在这种情况下避开索引的原因...

在使用这样的索引时，需要花费大量时间在索引（一个BTree）和数据之间来回弹跳。

不使用索引时，它只是浏览数据，忽略 10/12 的行。这可能实际上更快。