帮忙mysql 语句调优

wangyuanzju

要降低查询优化的影响的话，在MySQL中还有个方法是自己安排好join顺序，然后用straight_join让MySQL不要去优化了

jinguanding

这个方法还是建议不要用..可能某个时候是正确的..但是当记录发生了变化的情况下...就效果不一样了..还是让查询优化器自己处理比较好....

cyt2005

建立联合索引又要考虑前缀
index（a，b）
如果where先出现 b=***那么这个索引就失效了吧，而且目前我的这个应用里面就有这么个情况
我想问，加入我建立了index（a，b），然后在建立index（b）
这样好不好呢？会有什么问题呢？

jinguanding

应该没什么问题....就是增加索引的存储空间....已经insert的时候多做点事情....update更新到该字段的时候也需要多做点事情...


建议使用联合索引的时候.写语句要有意加上括号 ()

cyt2005

晕死
之前用到的
AND bo_inst.submit_flag = 1
  AND bo_inst.save_flag = 1
即使这俩个字段一起筛选，也只能过滤掉10%的数据
90%的数据都集中在这里
这可咋办啊

WESTLIFE_XU

原帖由 cyt2005 于 2008-1-22 08:50 发表
建立联合索引又要考虑前缀
index（a，b）
如果where先出现 b=***那么这个索引就失效了吧，而且目前我的这个应用里面就有这么个情况
我想问，加入我建立了index（a，b），然后在建立index（b）
这样好不好呢？会有什么问题呢？

那你可以这么建index(b,a)啊！

你的条件过滤不了几条数据，那你这个sql是做什么用的，是用来显示的？

anlinew

此sql是否会查出所有数据的很大一部分出来
然后交给应用层去处理
最终需要的可能仅仅是区区几页而已？

anlinew

这条语句根本问题应该是没有高选择性的条件
这样的语句无论怎么优化，随着数据量的增大最终也只有死路一条
其实际得到的数据量很大，需要扫描的数据块也无法降低

jinguanding

原帖由 anlinew 于 2008-1-22 09:51 发表
这条语句根本问题应该是没有高选择性的条件
这样的语句无论怎么优化，随着数据量的增大最终也只有死路一条
其实际得到的数据量很大，需要扫描的数据块也无法降低

呵呵...两位看来是经验丰富者啊........所以我建议LZ创建联合索引.......表的设计与数据已经存在..估计叫LZ改是不现实的...

对于只有1,2,3,4这几种散列的值单独创建索引是效果不一定好的(可能加快了 Select,而insert与update的开销更大,其实效果可能抵消掉了)....
不修改程序处理方式的话........只能创建联合索引...小弟给LZ的建议就这样...

anlinew

[

原帖由 anlinew 于 2008-1-22 09:51 发表
这条语句根本问题应该是没有高选择性的条件
这样的语句无论怎么优化，随着数据量的增大最终也只有死路一条
其实际得到的数据量很大，需要扫描的数据块也无法降低

这种设计方式的后果：
1、数据库层扫描大量的数据，耗费大量数据库资源
2、传输给应用层，耗费大量网络资源
3、应用层排序、筛选，耗费大量应用服务器资源


实际上你只要在数据库层的sql做好分页，每次只取所需即可