当在4.5Gb MySql数据库上运行时,以下查询在2.5Ghz双核Windows Server 2008 R2 Enterprise上花费0.7s。 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
这与在列上具有单独的索引不同。
这里的所有都是它的。
Index Cookbook