那么挑战来了,这条 sql 还能有更优化性能的写法吗?

2016-06-15 17:04:10 +08:00
 teemoer

http://ww3.sinaimg.cn/large/e38a7f8bgw1f4w0tyljcuj20kt0k1juw.jpg

SELECT m.id, m.name, mc_diag.count_size AS mc_diag_count, mc_thers.count_size AS mc_thers_count, mc_me.count_size AS mc_me_count FROM medicine m LEFT JOIN medicine_count mc_diag ON mc_diag.medicine_id = m.id AND mc_diag.doctor_id = 47 AND mc_diag.diagosis_name = '急性上呼吸道感染' LEFT JOIN medicine_count mc_me ON mc_me.medicine_id = m.id AND mc_me.doctor_id = 47 LEFT JOIN medicine_count mc_thers ON mc_thers.medicine_id = m.id AND mc_thers.doctor_id <> 47 WHERE (m.name LIKE '%w%' OR m.help_code LIKE '%w%') AND m.type = 0 GROUP BY m.name ORDER BY mc_diag_count DESC, mc_me_count DESC, mc_thers_count DESC, m.id DESC LIMIT 0, 10;

########################################## 鄙人的智商也就这么多了,诸位 SQL 大神多多指教

6176 次点击
所在节点    MySQL
69 条回复
teemoer
2016-06-15 17:05:44 +08:00
shit = = ! 格式乱了 我上图

banksiae
2016-06-15 17:45:59 +08:00
like '%w%'要扫全表的
est
2016-06-15 17:50:00 +08:00
急性上呼吸道感染
teemoer
2016-06-15 17:52:28 +08:00
@banksiae = = 先 and type=0 再 like 呢? 或者 有比 like 更好的办法吗
teemoer
2016-06-15 17:52:45 +08:00
@est = = 看到你头像我忍不住笑出声
Infernalzero
2016-06-15 18:03:14 +08:00
没有索引如何谈优化,况且看到那么多 join 而且还同时 group by order by 以及 like '%'的要想不是慢查询也难
ayumilove
2016-06-15 18:05:27 +08:00
medicine 表 有多少条数据
500miles
2016-06-15 18:06:19 +08:00
对同一张表 join 三次, 三次的条件还互补, 看不懂 看不懂
ango
2016-06-15 18:09:27 +08:00
不要为一条 sql 而一条 sql ,注意 IO 瓶颈,
应该在语言层来做一些逻辑处理,这样顶多消耗一点 CPU 性能。


我们公司不允许 联表 查询。不到万不得已,不允许使用 联表 查询。
magicdawn
2016-06-15 18:10:56 +08:00
对啊...
left join 同一张表啊
ixiaozhi
2016-06-15 18:14:26 +08:00
@ango 不允许 联表 查询的理由是什么,有点儿不理解
omygod
2016-06-15 18:18:03 +08:00
抛开数据量,谈 left join 的个数就是耍流氓
ango
2016-06-15 18:21:51 +08:00
@ixiaozhi
说是联表会产生临时表,导致 db 压力大。

老人说是总监要求的,我做为新人也只能执行了。
其实我也不能理解,简单的索引联表复合查询能有什么压力,现在搞得都得在 PHP 语言层做数据组合。
tomczhen
2016-06-15 18:24:29 +08:00
又是 jion ,又是 like ,又是 or ,数据量上来光靠修改 sql 语句想提高查询速度是不可能的。
JiShuTui
2016-06-15 18:25:47 +08:00
分拆成多个查询,合理利用缓存
murmur
2016-06-15 18:32:15 +08:00
自己 join 自己是什么情况呢。。。看到 like 基本就确定没法优化了
fireapp
2016-06-15 18:33:07 +08:00
这条 sql 有点毛病, 查询的结果集因为 group by 的存在所有很随机, group by 出来的结果集除了 group by 的对象 m.name 是明确的外, 其他字段都有不确定性
Ouyangan
2016-06-15 18:36:41 +08:00
@ango 我自己写业务的时候也经常纠结是不是要联表查询 ,好纠结啊 , 各有个的好处 .
petelin
2016-06-15 18:41:37 +08:00
@ango 不对啊,单表查要是写 for 循环是更慢的,因为查 sql 的次数多了啊。
welefen
2016-06-15 18:42:31 +08:00
拆成多个语句执行吧

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/285960

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX