mysql 递归查询 效率_性能优化实战-sql递归查询效率低下

今天在做一个热门赛事列表查询的接口压测

http://192.168.10.98:8094/match/page?matchType=0&matchTime=0&matchStatus=0&matchName=

和开发讨论，说matchName字段采用like匹配，会导致查询慢，建议采用http://192.168.10.98:8094/match/page?matchStatus=0压测

最初的压测效果如下：

http://192.168.10.98:8094/match/page?matchStatus=0

发现

http://192.168.10.98:8094/match/page?matchType=0&matchTime=0&matchStatus=0&matchName=&page=1&rows=20

压测场景如下：查询热门赛事列表

压测脚本如下

压测前：

200线程并发：平均tps大约207左右，平均耗时1.3s

第一轮优化：

查看原始sql：

优化后

性能优化将近提升2倍，但是性能还没有达到理想值

通过监控mysql服务器的资源消耗：

发现mysql的资源基本完全消耗完毕，所以目前优化空间在mysql上

通过监控mysql慢查询

SELECT

T2.*

FROM (

SELECT

@area_id AS child_id,

(SELECT @area_id := parent_id FROM

dict_area WHERE AREA_ID = child_id) AS

parent_id,

(@area_level :=

@area_level + 1) AS area_level

FROM

(SELECT @area_id := 11959,

@area_level := 0) v,

dict_area h

WHERE @area_id <>

0 ) T1

JOIN dict_area T2

ON T1.child_id = T2.AREA_ID

where

T2.lang_type='zh_CN'

ORDER BY T1.area_level ASC;

这条sql采用了递归查询，普通执行很快，但是高并发就很慢

通话程序代码优化，重新打包压测，性能测试结果tps提升一倍多

此时，http://192.168.10.98:8094/match/page?matchStatus=0 只带matchStatus字段，压测效果比较理想，但是随后再加上

http://192.168.10.45:8094/match/page?matchStatus=0&page=1&rows=20

性能还是回到tps平均在350左右

所以得持续分析优化