帮忙mysql 语句调优

jinguanding

原帖由 anlinew 于 2008-1-22 10:01 发表
[
这种设计方式的后果：
1、数据库层扫描大量的数据，耗费大量数据库资源
2、传输给应用层，耗费大量网络资源
3、应用层排序、筛选，耗费大量应用服务器资源


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

前三我站同..........之前的贴我也提到了....


但是 "sql做好分页"  对提高查询语句有什么效果嘛.....那只能用来控制显示的...

anlinew

原帖由 jinguanding 于 2008-1-22 09:59 发表




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

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

如果不改程序，我的建议是删掉索引（oracle），除非你有需要访问那剩下的10%

anlinew

原帖由 jinguanding 于 2008-1-22 10:11 发表


前三我站同..........之前的贴我也提到了....


但是 "sql做好分页"  对提高查询语句有什么效果嘛.....那只能用来控制显示的...

mysql 的limit、oracle 的rownum< 、mssql 的top n以及db2 的 fetch first是分页算法常用的方法
利用好这个功能，其key stop算法可以大量减少实际访问的数据块

anlinew

性能优化的终极目标是
  提高响应时间

时间的公式是这样的 T＝S工作量/V工作速度

那么减小T就有两个方法：
一、减小S  二、增大V

一、减小S的方法：通过索引减少所需访问的块，等

二、增大V的方法：并行处理，内存处理，提高IO能力等

写着玩儿。。。

[ 本帖最后由 anlinew 于 2008-1-22 10:41 编辑 ]

cyt2005

呵呵
我也觉得既然返回数据量这么大还不如全表扫描得了
这个sql的作用是显示所有的代办信息，
在前台多了分页处理
但是唯独这个sql前台想让他全部显示出来所以 LIMIT 0, 2147483647 他limit了一个无穷大的数为了全显
至于表的设计上的问题，这个我想很多时候大家都是无可奈何的吧，没有办法重新设计

anlinew

原帖由 cyt2005 于 2008-1-22 11:11 发表
呵呵
我也觉得既然返回数据量这么大还不如全表扫描得了
这个sql的作用是显示所有的代办信息，
在前台多了分页处理
但是唯独这个sql前台想让他全部显示出来所以 LIMIT 0, 2147483647 他limit了一个无穷大的数为了全显
至于表的设计上的问题，这个我想很多时候大家都是无可奈何的吧，没有办法重新设计

这个不是表设计的问题，应该算业务设计的问题

前台如果要全部显示的话也不应该每次都去扫描全部

信息数据是有生命周期的，对于你的表里的数据，大量数据应该是不活跃的，这类数据应该在前台生成静态页面
显示全部实际上是显示当前活跃数据加上直接调用的前期静态数据

cyt2005

原帖由 jinguanding 于 2008-1-22 09:59 发表




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

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

经常用的俩个字段
AND bo_inst.submit_flag = 1
AND bo_inst.save_flag = 1
联合起来也就能过滤掉10%的数据
所以选择性还是不好

cyt2005

原帖由 anlinew 于 2008-1-22 11:18 发表

这个不是表设计的问题，应该算业务设计的问题

前台如果要全部显示的话也不应该每次都去扫描全部

信息数据是有生命周期的，对于你的表里的数据，大量数据应该是不活跃的，这类数据应该在前台生成静态页面
显示全部实际上是显示当前活跃数据加上直接调用的前期静态数据

我还想把不同的根据不同flag，把表拆分然后拆分的表建立主键id
看来病根不在于此啊？

anlinew

原帖由 cyt2005 于 2008-1-22 11:11 发表
呵呵
我也觉得既然返回数据量这么大还不如全表扫描得了
这个sql的作用是显示所有的代办信息，
在前台多了分页处理
但是唯独这个sql前台想让他全部显示出来所以 LIMIT 0, 2147483647 他limit了一个无穷大的数为了全显
至于表的设计上的问题，这个我想很多时候大家都是无可奈何的吧，没有办法重新设计

最终显示到页面的数据有多少？
几万，有点儿过分吧
业务的实际需求是什么

[ 本帖最后由 anlinew 于 2008-1-22 11:46 编辑 ]

WESTLIFE_XU

原帖由 cyt2005 于 2008-1-22 11:11 发表
呵呵
我也觉得既然返回数据量这么大还不如全表扫描得了
这个sql的作用是显示所有的代办信息，
在前台多了分页处理
但是唯独这个sql前台想让他全部显示出来所以 LIMIT 0, 2147483647 他limit了一个无穷大的数为了全显
至于表的设计上的问题，这个我想很多时候大家都是无可奈何的吧，没有办法重新设计

显示几万行，页面受得了不，更别说可读性了。


为什么要显示无穷大？