MySQL缓慢查询'COUNT'

以下查询在4.5Gb MySql数据库上运行时，2.5Ghz双核Windows Server 2008 R2企业版需要0.7s。 sIndex10是一个varchar（1024）柱类型：MySQL缓慢查询'COUNT'

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可以提供的性能的顶部？在这一点上投资硬件是唯一的出路吗？

来源

2016-11-21 Rafael Diaz

你有 'possible_keys：App_Parent，sIndex10' WHT宇没有meta_oid？。你在这个专栏有适当的索引吗？最终显示您的表格架构 – scaisEdge

'App_Parent'是'meta_oid'列的索引名称 –

如果app_parent覆盖BOTH列，可能会实现小的性能增益 – Strawberry

-1

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

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

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

注意：这可能不是您的问题的完整答案，但它只是一个评论太长。

来源

2016-11-21 08:55:21

谢谢但这没有什么区别 –

'SQL_NO_CACHE'绕过了查询缓存，如果为ON，可以为_repeated_查询提供非常快的时间。 –

'COUNT（x）'检查'x'是否为NULL。这就是你想要的，所以'COUNT（*）'是写出它的方法。不，索引是不相关的，因为'WHERE'子句是索引所需要的。 –

WHERE meta_oid=336799 AND sIndex10 = ''

乞求一个复合指数

INDEX(meta_oid, sIndex10) -- in either order

即不一样具有在列单独的索引。

就是这样。

Index Cookbook

来源

2016-11-21 19:25:36

如何在不查询'sIndex10'的情况下使用'meta_oid'的查询？ –

他们也可以使用该索引（假设给定顺序）。仅使用sIndex10的查询不能。 Cookbook说：'WHERE aaa = 123 AND ...'：一个INDEX _starting_ with'aaa'很好，等等。 –

这没有什么区别 –

MySQL缓慢查询'COUNT'

回答

相关问题