mysql优化实践之distinct和模糊查询一起使用的慢查询优化

场景：tableX中有60W条数据
原sql:模糊匹配加去重
SELECT DISTINCT up_stream
FROM tableX
WHERE down_stream
LIKE ‘%疫苗%’ AND (save_flag is null or save_flag = ‘’) AND is_deleted = 0

这条SQL耗时大概7秒左右，使用分页插件后会更慢，查询索引类型为index

调优过程：
控制变量法：
方案一:去掉该SQL中的DISTINCT后该SQL耗时0.8秒，但不能满足去重需求，查询类型为全表扫描。
方案二:去掉该SQL中模糊查询前面的%后该SQL耗时0.3秒，但查询结果不完整，查询类型为range。

此时思考问题，为什么方案一与原SQL对比走了索引却慢了那么多，这一点我暂时不知道为啥。

此时我感觉自己没办法去优化这条SQL了，但是我仍然相信一定有决绝办法，然后继续百度，最后终于找到了一篇博客https://blog.csdn.net/went_m/article/details/79815411?utm_medium=distribute.pc_relevant.none-task-blog-searchFromBaidu-7.control&depth_1-utm_source=distribute.pc_relevant.none-task-blog-searchFromBaidu-7.control

解决思路：引用了上文博客中的思想
先不distinct，而是将数据范围缩小，只取down_stream与“疫苗”有关的数据，然后用这部分数据作为一个表与原表自身join,对很少量的数据进行distinct ，性能大大提升。

优化后的SQL：

SELECT DISTINCT B.up_stream
FROM tableX A
JOIN
(SELECT id, up_stream FROM tableX WHERE down_stream LIKE ‘%疫苗%’ AND (save_flag is null or save_flag = ‘’) AND is_deleted = 0 ) B
ON A.id = B.id

做java快两年了，最近写代码开始考虑性能问题了，希望我的经验对初入职场的小伙伴有帮助，嘿嘿！然后文中提到的问题有没有大佬看看 --> 文中问题 “此时思考问题，为什么方案一与原SQL对比走了索引却慢了那么多，这一点我暂时不知道为啥”， 这个问题有木有数据库大佬解释一下。