相同数据量表结构，线上执行12s 本地执行0.1s过程分析
1. 慢SQL信息
SELECT t1.id,t2.idFROM t_platform_target_standard_target_index t1LEFT JOIN t_platform_target_standard t2 ON t1.target_number = t2.target_numberWHERE t1.delete_flag = 0 AND t2.user_num = 'user001' AND t2.dimension = 5AND 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开发手册的很多要求，看似简单但都是经验的血泪史，遵守的话能减少很多不必要的问题。
