记录一次Sql性能优化

场景：

主业务表 contract（合同表），对于不同主体（人员），能查看的合同是不一样的。系统企业业务用到了，系统资源表 PERMISSION_RESOURCE 、员工对于资源关系表：ENTRY_JOIN

正常情况下。查询个人能看的合同。sql如下：简化版、且 对应索引都已加
 

SELECT
	COUNT( DISTINCT C.id ) 
FROM
	CONTRACT C
	INNER JOIN PERMISSION_RESOURCE PR ON PR.resourceId = C.id
	INNER JOIN ENTRY_JOIN EJ ON PR.entryId = EJ.entryId 
	AND EJ.joinId = 2931819442069999624 
	AND PR.canview = 1 
WHERE
	C.STATUS != 'DELETE' 

根据，sql优化建议，内联性能更好。对于业务说contract 往往历史合同查看/

第一次优化，通过id 约定查询范围（id 是 根据时间戳 偏移得到）

SELECT
	COUNT( DISTINCT C.id ) 
FROM
	CONTRACT C
	INNER JOIN PERMISSION_RESOURCE PR ON PR.resourceId = C.id
	INNER JOIN ENTRY_JOIN EJ ON PR.entryId = EJ.entryId 
	AND EJ.joinId = 2931819442069999624 
	AND PR.canview = 1 
WHERE
	C.STATUS != 'DELETE' 
	AND C.id > 3016248654885646520 
	AND C.id < 3036245744471820304

结果：查询的效果非常低。达到 4.283 秒

 

通过解释sql 可以看到 对于 PERMISSION_RESOURCE 查询 使用了 where 。这步没有问题。

问题在于 contract 是资源主体。 PERMISSION_RESOURCE 是资源表。

contract 是小表（9k条），PERMISSION_RESOURCE 是大表（58w）

小对多  内联是 比较耗费性能的

因此 改成 匹配子查询

SELECT
	COUNT( DISTINCT C.id ) 
FROM
	CONTRACT C 
WHERE
	C.STATUS != 'DELETE' 
	AND C.id > 3016248654885646520 
	AND C.id < 3036245744471820304 
	AND EXISTS (
	SELECT
		1 
	FROM
		PERMISSION_RESOURCE PR
		INNER JOIN ENTRY_JOIN EJ ON PR.entryId = EJ.entryId 
	WHERE
		PR.resourceId = C.id 
		AND EJ.joinId = 2931819442069999624 
	AND PR.canview = 1 
	)

修改后 新能飙升了 。 

 总结：

对sql性能优化时，不能照搬书上知识或者网络文章。还是需要有扎实的技术对实际情况进行分析。