Question

有一个表格tb_tag_article，如

CREATE TABLE `tb_tag_article` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `tag_id` int(16) NOT NULL,
  `article_id` int(16) NOT NULL,
  PRIMARY KEY (`id`),
  KEY `key_tag_id_article_id` (`tag_id`,`article_id`) USING BTREE,
) ENGINE=InnoDB AUTO_INCREMENT=365944 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci

当我这样查询时，结果为 5120 。

SELECT count(*) FROM tb_tag WHERE tag_id = 43

但是当我解释这样的查询时

EXPLAIN SELECT count(*) FROM tb_tag WHERE tag_id = 43

检查的行 13634 。

+------+-------------+----------------+------+-----------------------+-----------------------+---------+-------+-------+-------------+
| id   | select_type | table          | type | possible_keys         | key                   | key_len | ref   | rows  | Extra       |
+------+-------------+----------------+------+-----------------------+-----------------------+---------+-------+-------+-------------+
|    1 | SIMPLE      | tb_tag_article | ref  | key_tag_id_article_id | key_tag_id_article_id | 4       | const | 13634 | Using index |
+------+-------------+----------------+------+-----------------------+-----------------------+---------+-------+-------+-------------+

查询使用Index但检查的行数大于实际数据的数量。有什么问题？

Answer 1

来自MySQL参考（http://dev.mysql.com/doc/refman/5.0/en/explain-output.html#explain_rows）：

rows列表示MySQL认为必须的行数   检查以执行查询。

对于InnoDB表，此数字是估算值，可能并非总是如此   精确。

也可能是因为它必须分析索引，它会考虑索引中的记录数加上表中的记录数。但这只是一个假设。

此外，看起来MySQL 5.1中存在一个带有Explain Row估计的错误，导致数字大幅下降：http://bugs.mysql.com/bug.php?id=53761这可能解释了一些奇怪的原因。

文档的主要内容似乎是将EXPLAIN行列添加到一层盐中。

Answer 2

问：问题是什么？

答：看起来没有任何问题。

EXPLAIN输出中“rows”列的值是估算值，而不是确切的数字。

参考：http://dev.mysql.com/doc/refman/5.5/en/explain-output.html

为了评估每个可能的访问路径的“成本”，优化器仅需要估计，以便比较在索引上使用范围扫描操作的效率与表中所有行的完全扫描的效率。优化器不需要表中总行数的“精确”计数，也不需要满足谓词的行数。

对于这个简单的查询，MySQL只会考虑几个可能的计划。

13684的估计与行的确切数量相差不远。它的关闭时间是2.5，但是MySQL提出了正确的执行计划：使用索引，而不是检查表中的每一行。

没有问题。

MySQL很多行由简单查询检查

2 个答案: