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

相同数据量表结构，线上执行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配置是否优化

	线上	本地
服务器信息
SQL执行时间	12S	0.1S
MySQL版本	5.6.44	5.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的target_number索引，而且先是t2（小表）后是t1（大表），既然本地快，那就让线上索引跟本地一致。

4. 修改索引

  删除idx_classify 索引，执行计划分析如下。查询时间8.734s ，又走了classify_index_number索引，无效果。

  继续删除classify_index_number索引,执行计划分析如下。查询时间为0.095s！ 索引顺序与执行索引与本地一致，问题解决。

总结

  MySQL版本不同导致旧版本的MySQL走了错误的索引，查询时间奇慢。条件允许的情况下升级MySQL好处还是很多的，会解决老版本的安全漏洞，同时避免此类索引优化错误的问题，更好的索引选择也会带来更高的效率。
  不是所有慢SQL都是句加索引就能解决的，排除环境问题的情况下，要结合表结构设计、数据量、SQL，修改或创建索引。
  索引名创建需规范

Java开发手册的很多要求，看似简单但都是经验的血泪史，遵守的话能减少很多不必要的问题。