场景：

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

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

SELECTCOUNT( DISTINCT C.id ) 
FROMCONTRACT CINNER JOIN PERMISSION_RESOURCE PR ON PR.resourceId = C.idINNER JOIN ENTRY_JOIN EJ ON PR.entryId = EJ.entryId AND EJ.joinId = 2931819442069999624 AND PR.canview = 1 
WHEREC.STATUS != 'DELETE' 

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

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

SELECTCOUNT( DISTINCT C.id ) 
FROMCONTRACT CINNER JOIN PERMISSION_RESOURCE PR ON PR.resourceId = C.idINNER JOIN ENTRY_JOIN EJ ON PR.entryId = EJ.entryId AND EJ.joinId = 2931819442069999624 AND PR.canview = 1 
WHEREC.STATUS != 'DELETE' AND C.id > 3016248654885646520 AND C.id < 3036245744471820304

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

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

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

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

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

因此 改成 匹配子查询

SELECTCOUNT( DISTINCT C.id ) 
FROMCONTRACT C 
WHEREC.STATUS != 'DELETE' AND C.id > 3016248654885646520 AND C.id < 3036245744471820304 AND EXISTS (SELECT1 FROMPERMISSION_RESOURCE PRINNER JOIN ENTRY_JOIN EJ ON PR.entryId = EJ.entryId WHEREPR.resourceId = C.id AND EJ.joinId = 2931819442069999624 AND PR.canview = 1 )

修改后 新能飙升了 。 

 总结：

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