免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
最近访问板块 发新帖
查看: 7016 | 回复: 5
打印 上一主题 下一主题

where字段条件多,至少3个以上,如何优化 [复制链接]

论坛徽章:
0
跳转到指定楼层
1 [收藏(0)] [报告]
发表于 2013-02-05 22:08 |只看该作者 |倒序浏览
where gid not in (54725,98926) and t_category_id = 21 and t_cityid!=15 and t_cityid!=1 and t_delivery=1 and t_starttime<1359993600 AND t_endtime >= 1360070513 and t_isdelete=0 ORDER BY t_starttime desc;


就上面这个where,10W行纪录,每个字段唯一性都不强,如何处理比较好。

我目前的处理办法,找唯一最好的字段建索引,尽可能少扫描数据。


我试过复合索引效果不大,大家还有什么好的建议吗?谢谢。

论坛徽章:
93
2015年辞旧岁徽章
日期:2019-10-10 10:51:15CU大牛徽章
日期:2014-02-21 14:21:56CU十二周年纪念徽章
日期:2020-10-15 16:55:55CU大牛徽章
日期:2014-02-21 14:22:07羊年新春福章
日期:2019-10-10 10:51:39CU大牛徽章
日期:2019-10-10 10:55:38季节之章:春
日期:2020-10-15 16:57:40ChinaUnix元老
日期:2019-10-10 10:54:42季节之章:冬
日期:2019-10-10 10:57:17CU大牛徽章
日期:2014-02-21 14:22:52CU大牛徽章
日期:2014-03-13 10:40:30CU大牛徽章
日期:2014-02-21 14:23:15
2 [报告]
发表于 2013-02-06 10:03 |只看该作者
这个有 not in 又有 != 看上去就应该是不那么快。
我以为 gid 不是应该是唯一的字段吗,不过即使是索引了,也是除了两个值之外的所有数据,和全表扫描没什么区别了。
这样看来,只有利用starttime 和 endtime 的复合唯一性最好了,可是感觉又不够科学。
纠结呐。

论坛徽章:
0
3 [报告]
发表于 2013-02-06 10:49 |只看该作者
回复 2# seesea2517

这个语句,基本上没什么可优化的,下面是准备拆分,如何拆分,效率更高,这点是我比较关心的。


   

论坛徽章:
0
4 [报告]
发表于 2013-02-06 11:58 |只看该作者
总数据量和返回的数据量各是多少。返回量太大,那么什么索引也没意义,还没全表快呢。
如果结果集比较小的话,我觉得时间和排序进行索引应该有可能提高性能。

论坛徽章:
0
5 [报告]
发表于 2013-02-06 12:43 |只看该作者
回复 4# wlmouse

starttime endtime返回近50%的数据,所以索引也不是太好。


   

论坛徽章:
0
6 [报告]
发表于 2013-02-06 17:47 |只看该作者
回复 5# todayhero


    所以我问你返回的结果集有多大呀。结果集过大,用索引还不如不用。
您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

  

北京盛拓优讯信息技术有限公司. 版权所有 京ICP备16024965号-6 北京市公安局海淀分局网监中心备案编号:11010802020122 niuxiaotong@pcpop.com 17352615567
未成年举报专区
中国互联网协会会员  联系我们:huangweiwei@itpub.net
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP