一次MySQL数据库迁移遇到的坑

今天给一个跑了近十年的程序做数据库的迁移，遇到了不少的问题，记录一下…
原数据库版本为5.1.73，新数据库版本为5.7.22，原程序JDBC版本为3.1.8，跑在tomcat上。
头天晚上没什么问题，用mysqldump将原数据库导出来然后导进新库，改了数据库连接配置后应用启起来就可以了。
第二天一大早，发现应用用不了，报连接池超时错误。看了下数据库线程，好嘛，200多个连接，而且大多是sleep，看下默认的最大连接参数配置，果然满了
mysql> show variables like ‘%conn%’

+———————————————–+—————–+
| Variable_name | Value |
+———————————————–+—————–+
| character_set_connection | utf8 |
| collation_connection | utf8_general_ci |
| connect_timeout | 10 |
| disconnect_on_expired_password | ON |
| init_connect | |
| max_connect_errors | 100 |
| max_connections | 214 |
| max_user_connections | 0 |
| performance_schema_session_connect_attrs_size | 512 |
+———————————————–+—————–+
临时把参数调大

set global max_connections=500;

程序可以用了，但是在多了几个连接过后又报同样错误，数据库这边连接也一直阻塞在220个左右，即使是设了最大连接为500.sleep连接没有释放，之前的数据库就没有出现这个问题，思考了各个方面，怀疑是JDBC版本过低，于是换了个8.0.12的版本，新问题出现了
Cannot load JDBC driver class ‘com.mysql.jdbc.Driver’
java.lang.UnsupportedClassVersionError: com/mysql/jdbc/Driver : Unsupported major.minor version 52.0
jdk什么的又不支持？算了，十年前的程序，东西动多了太麻烦也不好控制了，还是从数据库层面解决一下。
既然sleep连接不释放，那就数据库设个超时自动释放吧

set global interactive_timeout=300;
set global wait_timeout=300;

两个同时设置才能生效，关于两个参数详解，可参考https://www.cnblogs.com/ivictor/p/5979731.html
OK，这个问题就解决了。
然后，后面又出现了问题，应用查一个模块的数据，查不出来，到300秒后就超时了，这没问题，跟数据库配置一致。原数据库查的时候要用个6，7秒，但好歹能查出来…
于是临时打开数据库general_log，再查询一次，抓出有问题的SQL

SELECT
    a.item_code,
    i.item_name,
    a.item_date,
    a.item_amt_01,
    o.org_name
FROM
    vender_amt_hf a
LEFT JOIN t_sys_org o ON (a.org_code = o.org_code)
LEFT JOIN vender_item i ON (
    a.item_code = i.item_code
    AND a.org_code = i.org_code
)
WHERE
    a.vender_code = 'S08033A'
AND a.item_date = (
    SELECT
        max(item_date)
    FROM
        vender_amt_hf
    WHERE
        vender_code = 'S08033A'
)
ORDER BY
    a.item_code

把这条SQL拿出来在数据库跑是能跑出来的，要5秒多。老旧数据库这条SQL差不多都要跑这么久，但表现就是连老数据库应用能出结果，新数据库出不了结果，最后超时。给这张表加个索引

CREATE INDEX idx_vah_001 ON vender_amt_hf (vender_code, item_date);

这条查询很快就能出结果，然后应用连新数据库也能出结果了。很奇怪，找不到原因，但还是怀疑数据库方面有某个参数在控制…留个问题在这儿，以后再研究下。

总结：
1、生产环境做这种事最好还是要先测试下…这次没做测试直接搞了后面出问题很难受。
2、这种跨多版本的数据库迁移还是应该谨慎啊…