以下查询在 2.5Ghz 双核 Windows Server 2008 R2 Enterprise 上运行 4.5Gb MySql 数据库时需要 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所能提供的性能的顶部？目前投资硬件是唯一的出路吗？
最佳答案
WHERE meta_oid=336799 AND sIndex10 = ''
求一个复合索引
INDEX(meta_oid, sIndex10) -- in either order
这与在列上有单独的索引不同。
仅此而已。
关于MySQL 慢查询 'COUNT'，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/40715325/