MySQL线上慢SQL问题分析处理小记

2023-12-29 19:30:38

相同数据量表结构,线上执行12s 本地执行0.1s过程分析

1. 慢SQL信息

	SELECT t1.id,t2.id
        FROM t_platform_target_standard_target_index t1
        LEFT JOIN t_platform_target_standard t2 ON t1.target_number = t2.target_number
        WHERE t1.delete_flag = 0 AND t2.user_num = 'user001'  AND t2.dimension = 5
        AND t1.classify_index_number IN  (  
	'TA-001',...省略大概20个记录
)

2. 确认环境及MySQL配置是否优化

线上本地
服务器信息image.pngimage.png
SQL执行时间12S0.1S
MySQL版本5.6.445.7.27-log
数据量及索引情况线上表拷贝至本地,所以表与索引一致

??看着服务器差距不是太大,于是排查配置,发现线上无任何配置,开始优化配置
关闭Selinux,效果不明显。加上一些Mysq基础配置优化如下, 其中innodb_buffer_pool_size 影响最大。时间降至8s ,同时可以排除是硬件问题。

#具体参数大小,请根据服务器配置做调整
innodb_buffer_pool_size = 10G 
max_connections=1000 
skip_name_resolve = 1
transaction_isolation = READ-COMMITTED
group_concat_max_len = 102400
tmp_table_size = 1342177280
max_heap_table_size = 1342177280
binlog_cache_size = 524288

3. 分析执行计划

??以为同样的数据与索引,执行计划应该是一模一样的,但是走的索引不同发现问题。
??t1数据量为900549,t2数据量为55311,两表索引情况如下。
t1索引情况
t2索引情况
执行计划分析情况
本地:
image.png
线上:
image.png
??两个环境居然走的索引不一样!本地,只走了一个t1的target_number索引,而且先是t2(小表)后是t1(大表),既然本地快,那就让线上索引跟本地一致。

4. 修改索引

??删除idx_classify 索引,执行计划分析如下。查询时间8.734s ,又走了classify_index_number索引,无效果。
image.png
??继续删除classify_index_number索引,执行计划分析如下。查询时间为0.095s! 索引顺序与执行索引与本地一致,问题解决。
image.png

总结

??MySQL版本不同导致旧版本的MySQL走了错误的索引,查询时间奇慢。条件允许的情况下升级MySQL好处还是很多的,会解决老版本的安全漏洞,同时避免此类索引优化错误的问题,更好的索引选择也会带来更高的效率。
??不是所有慢SQL都是句加索引就能解决的,排除环境问题的情况下,要结合表结构设计、数据量、SQL,修改或创建索引。
??索引名创建需规范
Java开发手册 索引规约对命名要求
Java开发手册的很多要求,看似简单但都是经验的血泪史,遵守的话能减少很多不必要的问题。

文章来源:https://blog.csdn.net/qq_42397121/article/details/135296099
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。