'COUNT'的MySQL慢查询答案

【问题标题】：MySQL Slow query for 'COUNT''COUNT'的MySQL慢查询
【发布时间】：2016-11-21 08:01:18
【问题描述】：

在 4.5Gb MySql 数据库上运行时，以下查询在 2.5Ghz 双核 Windows Server 2008 R2 Enterprise 上需要 0.7 秒。 sIndex10 是 varchar(1024) 列类型：

SELECT COUNT(*) FROM e_entity
WHERE meta_oid=336799 AND sIndex10 = ''

EXPLAIN 显示以下信息：

id: 1
select_type: SIMPLE
table: e_entity
type: ref
possible_keys: App_Parent,sIndex10
key: App_Parent
key_len: 4
ref: const
rows: 270066
extra: Using Where

有 230060 行匹配第一个条件，124216 行匹配带有AND 运算符的子句。 meta_oid 已编入索引，尽管 sIndex10 也已编入索引，但我认为正确地没有将该索引作为FORCE INDEX (sIndex10) 获取，需要更长的时间。我们查看了诸如innodb_buffer_pool_size 之类的配置参数，它们看起来也正确。

鉴于该表已经有 642532 条记录，我们是否达到了 mysql 可以提供的性能的顶峰？现在投资硬件是不是唯一的出路？

【问题讨论】：

你有 'possible_keys: App_Parent,sIndex10' 你没有 meta_oid 吗？ .你在这个列上有正确的索引吗？最终显示您的表架构
App_Parent 是meta_oid 列的索引名称
如果 app_parent 覆盖 BOTH 列，则可能会获得少量性能提升

标签： mysql sql innodb sql-tuning

【解决方案1】：

WHERE meta_oid=336799 AND sIndex10 = ''

求一个复合索引

INDEX(meta_oid, sIndex10)  -- in either order

这不与在列上具有单独的索引相同。

仅此而已。

Index Cookbook

【讨论】：

使用meta_oid而不查询sIndex10的查询呢？
他们也可以使用该索引（假设给定的顺序）。仅使用 sIndex10 的查询不能。 Cookbook 说“WHERE aaa = 123 AND ...：以aaa 开头的索引开始很好”，等等。
这没有任何区别
如果大多数行都有sIndex10 = ''，那么我建议的索引不会有太大帮助。
53% 匹配meta_oid 的记录也有sIndex10 = ''

【解决方案2】：

我经常做的一件事就是 count(id)，因为 id （几乎）总是被索引，只计算 id 只需要查看索引。

所以尝试运行，看看它是否表现更好。您还应该在测试时添加SQL_NO_CACHE，以便更好地了解查询的执行情况。

SELECT SQL_NO_CACHE COUNT(id) FROM e_entity
WHERE meta_oid=336799 AND sIndex10 = ''

注意：这可能不是您问题的完整答案，但对于仅发表评论来说太长了。

【讨论】：

谢谢，但这没什么区别
SQL_NO_CACHE 绕过查询缓存，如果开启，可以为重复查询提供非常快的计时。
COUNT(x) 检查x 是否为NULL。这很少是你想要的，所以COUNT(*)是通常的写法。不，索引无关紧要，因为 WHERE 子句需要索引。