Question

在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可提供的性能顶级？在这一点上投资硬件是唯一的前进方向吗？

Answer 1

WHERE meta_oid=336799 AND sIndex10 = ''

请求复合索引

INDEX(meta_oid, sIndex10)  -- in either order

与列上的单独索引相同。

这就是它的全部内容。

Index Cookbook

Answer 2

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

因此尝试运行并查看它是否表现更好。您还应该在测试时添加SQL_NO_CACHE以更好地了解查询的执行方式。

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

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

MySQL慢速查询'COUNT'

2 个答案: