分享一次简单sql优化过程。
客户反馈他们有个功能返回结果较慢，大概要300s左右，具体执行的sql如下：
从这个SQL一眼我们能看到几个性能瓶颈点：
1.全表扫描风险
-
LIKE条件以通配符开头会导致索引失效，但此处条件是以固定前缀C0311...%开头，若字段有索引仍可能走范围扫描。
-
多个OR条件可能导致优化器选择全表扫描。
2.索引缺失
-
若YLBXID、MULULB或LIKE字段无索引，查询效率会显著下降
3.select *
-
返回所有字段可能导致不必要的I/O开销（尤其是大字段或LOB类型）
进一步确认信息：
1.MULULB和YLBXID字段上有索引，但是全是301和600，即MULULB = '301'和YLBXID = '600'是无效条件；
2.所有字段都需要返回
优化思路：
1.尝试给like字段添加索引后，发现效率还是没有提升，大概率多个or条件导致
2.拆分or条件为union all（和客户确认业务不会重复）
改写后的sql如下：
sql改写后，执行时间为0.1s。
（注意：这种改写可能加重重复数据，需要提前和业务方做确认，根据业务逻辑决定是否使用union去重）。
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/29956245/viewspace-3079793/ ，如需转载，请注明出处，否则将追究法律责任。
上一篇：
ASM磁盘组掉后坏快处理（一）
请登录后发表评论
登录
全部评论
