inner join关联查询-索引问题

最新推荐文章于 2025-07-17 06:10:29 发布

原创最新推荐文章于 2025-07-17 06:10:29 发布 · 5.2k 阅读

2 ·

CC 4.0 BY-SA版权

文章标签：

#sql #数据库 #mysql #索引

问题解决专栏收录该内容

18 篇文章

订阅专栏

通过重新审视索引原理，作者优化了一个线上列表的加载性能，从5秒缩短到1秒。关键在于调整查询策略，利用额外字段标记最新评论，结合索引策略，最终解决了E表排序查询慢的问题。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

今天重新看了一遍索引的原理及如何避免索引失效的办法，详见：
索引原理
 索引原理延展
 如何避免索引失效
原本想着只是温故，突然想到线上有个列表加载速度一直很慢，大概5s左右。这还是优化过的，还没优化前10s左右。因为也不是非常重要的功能，就一直放着，今天看完也就想着实践一下的想法去尝试优化，最后优化到了1s内，也是…惊喜，优化过程如下：

有or_mainten表和or_mainten_inner_evaluate表，后面都用M和E代替
业务场景是M表需要关联E表，E表为评论表，所以可能存在M表中的一条数据对应E表中多条评论，而查询的时候，M只要E表中最新的那一条评论。

刚开始的实现方式是通过M表关联 (E表自身排序查询最新一条评论)，发现E表自身排序查询太慢了，拖了整个查询的时间。后面想到在评论表中新增一个状态值，最新的那条用1标志，其它的重置为0。这样直接通过inner join和where就能查询，省去了查询最新的步骤，如下：

SELECT
	M.ID
FROM
	OR_MAINTEN M
	INNER JOIN or_mainten_inner_evaluate omie ON omie.RELATED_ID = M.ID
	WHERE omie.IS_LAST = '1'

优化第一次后，列表加载从原来的十几秒降到了5s左右。
初始加载的SQL语句如下：

 SELECT
	M.ID,
	M.MAINTEN_NO,
	M.LOT_ID,
	M.LOT_NAME,
	M.FAULT_DESC,
	M.INFORMATION,
	M.REAL_MAINTEN_PERSON,
	M.BILL_TYPE,
	M.STATUS,
	M.FINISH_TIME,
	M.DATA_SOURCES,
	M.ADDRESS,
	M.PROBLEM_LEVEL,
	M.DEAL_MODE,
	M.CUSTOM_INITIATE,
	M.BILL_TYPE AS billTypeName 
FROM
	OR_MAINTEN M
	INNER JOIN or_mainten_inner_evaluate omie ON omie.RELATED_ID = M.ID
	WHERE omie.IS_LAST = '1' AND omie.EVALUATE_STATUS ='0' AND M.STATUS = '2' AND M.FINISH_TIME >= '2021-09-18 00:00:00'  AND M.FINISH_TIME <= '2021-10-18 23:59:59'
	ORDER BY M.FINISH_TIME DESC

此时两表的索引：
M表
在这里插入图片描述

E表
在这里插入图片描述
此时的查询：
explain

查询时间

explain相关分析可以看这篇关于mysql inner join 连接查询的优化

仔细看了SQL查询和索引后发现，这边走的索引是INDEX_STATUS_DATA_SOURCES
在这里插入图片描述

根据最左前缀匹配原则，M表根据status去匹配索引，自然就是上面这个了，但是初始SQL中还有和finish_time没有，于是我把

改成了

再执行

查询时间明细提升。
要理解上面所讲，需要理解索引的原理，建议详细阅读开头有关索引原理及避免失效的文章