SQL语句优化

philip_zhong

txwdhs 发表于 2011-11-16 16:54
谢谢你！我大体明白了，还是有个别的地方不太清楚：

3>当前两者都不满足时，存储引擎会自动创建一个六 ...

问题1：
"你说的这种情况，如果是这样，我从哪里能看出这个存储引擎自动建在了哪里呢",你可以从源代码中check下逻辑，在table定义中是看不到的。
问题2：
你的sql中首先建立的索引是没有status这个字段的，那么意味着你需要获取status的具体值，由于mysql是PK的cluster index，所有字段的数据是挂靠在PK的叶子节点下的，因此你需要额外的访问PK获取这个status的值，从而再做filter操作，如果你的index已经包括了status字段，就无需访问PK去获取值了。

你需要深入的看下mysql的innodb的索引结构。

icer_repls

@justlooks: 谢谢指出

@txwdhs:  主键索引的叶子节点包含了全部字段。这样的话走主键索引能得到你所需要的全部信息，因为所有的字段都在主键索引的叶子节点里面

jinguanding

LZ的SQL问题，最大的问题出现在：OWNUNO字段的过滤性太差，只有18个，而SQL种除了出现此字段之外 还有一个：REMOVESTATUS='n' 条件
唯一想办法提供性能的办法就是，再创建一个索引：ALTER TABLE TLI_HOME_71 ADD INDEX idx_oNo_RStatus（OWNUNO,REMOVESTATUS）;
然后这条SQL就可以利用索引覆盖的原理解决性能的问题。

另外唯一性索引创建也不对，组合索引的顺序应该是：(`DIRECTID`，`OWNUNO`) 而不是 (`OWNUNO`,`DIRECTID`)

因为字段DIRECTID的过滤性好，有利于减少数据的查找能力，因为唯一索引字段值发生变化都可能需要检查，为此必须修改下组合索引的顺序...




TIMELINE_ITEM_HOME_71        0        PRIMARY        1        TLID        A        728085        \N        \N                BTREE      
TIMELINE_ITEM_HOME_71        0        IDX_TLI_HOME_71_UNIQUE        1        OWNUNO        A        18        \N        \N                BTREE      
TIMELINE_ITEM_HOME_71        0        IDX_TLI_HOME_71_UNIQUE        2        DIRECTID        A        728085        \N        \N                BTREE      
TIMELINE_ITEM_HOME_71        1        IDX_TLI_HOME_71_CREATEDATE        1        CREATEDATE        A        1309        \N        \N                BTREE   

txwdhs

明白了，非常谢谢大家给我的指点，我再去好好看看Innodb索引方面的资料，再次感谢大家！

txwdhs

又来麻烦大家了，对那个列增加了组合索引，进行压力测试，在慢日志里还是会有400秒的查询，应该从哪里再进行优化呢？执行计划里也都走了索引，100多W的数据，为什么会那么慢呢？硬盘没做RAID，7200转的，不至于吧？