两行日志的时间差很大,有经验的开发者会分析为...
先看下面代码截图:

然后看下面log:

1)
观察第一个红框中的两行log,16:40:02.446 - 16:40:01.964 = 482ms, 这个时间程序在做什么?
有经验的开发者会分析:可能是服务器GC过长、内存占用过大,导致业务处理能力下降。
2)
再来看看sql执行耗时 16:40:02.988 - 16:40:02.446 = 542ms,
执行的sql语句是'select * from emax_enterprise where enterprise_id=1723705456764793 AND products IN('BossKG','SHENBIANYOUHUO') limit 1'①。 对比 'select * from emax_enterprise where enterprise_id=1723705456764793 AND products IN('BossKG','SHENBIANYOUHUO') limit 1'②,再对比去掉limit③,我们来看看3个sql的执行计划:
| # | select_type | table | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
|---|---|---|---|---|---|---|---|---|---|---|
| ① | SIMPLE | emax_enterprise | range | idx_enterprise_products | idx_enterprise_products | 311 | (null) | 2 | 100 | Using index condition |
| ② | SIMPLE | emax_enterprise | ref | idx_enterprise_products | idx_enterprise_products | 8 | const | 1 | 100 | (null) |
| ③ | SIMPLE | emax_enterprise | ref | idx_enterprise_products | idx_enterprise_products | 8 | const | 1 | 100 | (null) |
可以看到后2个是一样的,均比①要优。 也就是说,程序可以直接按 enterprise_id 来查询数据,然后在程序里对product进行过滤。
3)
执行完sql后,又出现一个莫名的时间差,16:40:03.433 - 16:40:02.988 = 445ms。
这个与1)的原因相似:可能是服务器GC过长、内存占用过大,导致业务处理能力下降。
当看到一些不好的代码时,会发现我还算优秀;当看到优秀的代码时,也才意识到持续学习的重要!--buguge
本文来自博客园,转载请注明原文链接:https://www.cnblogs.com/buguge/p/19188311
浙公网安备 33010602011771号