MySQL 正式上线前，有四项关键检查绝不能省略：先执行SELECT VERSION()，确认当前运行版本与应用文档要求完全一致，避免因为版本差异在生产环境中“翻车”；再通过SHOW VARIABLES核对my.cnf中的关键参数是否已经真正生效，重点检查innodb_buffer_pool_size、wait_timeout等核心配置；接着使用SELECT user,host和SHOW GRANTS，把线上数据库账号权限逐项核查清楚，确保授权精确到库和IP范围，同时不包含高危权限；最后还要确认slow_query_log=ON、log_error对应路径具备写入权限，并且通过tail -f能够实时看到ready for connections日志。只有这四步都验证到位，MySQL 生产环境才算真正准备完成。
在 MySQL 项目上线之前，必须完成四项硬性验证：版本兼容、配置生效、权限最小化以及日志可写。这四项缺一不可，否则上线后很容易出现连接中断、SQL 执行失败或性能异常，甚至在深夜紧急排障。
确认 MySQL 版本与应用是否真实兼容
很多 MySQL 上线故障并不是代码本身有问题，而是数据库版本与应用依赖的特性不匹配。比如应用中使用了 JSON_CONTAINS 函数，却实际部署在 MySQL 5.6 上——而这个函数从 5.7.8 开始才支持。
- 不要只看安装包名称，务必执行
SELECT VERSION();查询实际运行中的 MySQL 版本 - 检查应用文档，重点关注“最低支持版本”和“已知不兼容的小版本”，例如 8.0.22 修复了
GROUP BY在严格模式下的解析 bug - 如果使用 Docker 部署，像
mysql:8.0这样的 tag 并不稳定，建议固定到mysql:8.0.34（当前最新 patch 版本） - 本地测试能通过，不代表线上一定没问题：还要检查
sql_mode是否包含STRICT_TRANS_TABLES，因为旧版本默认关闭，而新版本通常默认开启
验证 my.cnf 关键参数是否已经真正生效
修改完配置文件，并不意味着 MySQL 参数一定已经生效。数据库启动时可能加载了其他配置文件路径，或者被命令行启动参数直接覆盖。
- 先确认实际加载路径：
mysqld --verbose --help | grep "Default options"，确保你修改的是 MySQL 真正读取的那个my.cnf - 再检查运行时参数值：
SHOW VARIABLES LIKE 'innodb_buffer_pool_size';，将查询结果与配置文件中的值进行比对，不一致就说明没有生效 - 重点关注三类核心参数：
wait_timeout（避免连接池连接被服务端静默断开）、max_connections（不要设置过高以免引发 OOM）、innodb_buffer_pool_size（通常建议为物理内存的 50%–75%，但绝不能超过可用内存） - 如果通过 systemd 启动 MySQL，还要检查
/etc/systemd/system/mysqld.service是否在ExecStart中硬编码了--max-connections=100，因为这会覆盖配置文件中的设置
检查用户权限配置与网络连通性
开发环境中使用 root@localhost 可能问题不大，但在线上生产环境必须做好账号隔离。权限授予过大或过小，都会影响 MySQL 安全性和业务稳定性。
- 执行
SELECT user, host FROM mysql.user;，确认不存在'%'@'%'或'root'@'%'这类过于宽泛的授权方式 - 查看具体业务用户权限：
SHOW GRANTS FOR 'app_user'@'10.20.%.%';，通常只应保留SELECT、INSERT、UPDATE、DELETE，禁止授予DROP、CREATE、FILE等高风险权限 - 不要只靠
ping测试 IP 是否可达，更要实际连接验证：mysql -h，输入密码后能正常进入才算真正连通线上IP-u app_user -p -P 3306 -D app_db - 同时留意
bind-address配置：如果设为127.0.0.1，则只能本地访问；生产环境一般配置为0.0.0.0或指定内网 IP
确保慢查询日志与错误日志已开启且具备写入能力
没有日志的线上 MySQL，就像没有刹车系统的车辆——一旦出问题，排查时只能靠猜，效率极低。
- 先检查日志开关：
SHOW VARIABLES LIKE 'slow_query_log';，结果应为ON；同时long_query_time建议设置为1.0，不要设为0，否则可能快速写满磁盘 - 确认
log_error对应目录存在，并且 MySQL 运行用户具备写权限：ls -ld /var/log/mysql/，再执行sudo -u mysql touch /var/log/mysql/test.log进行验证 - 检查磁盘空间是否充足：
df -h /var/log，如果剩余空间低于 20%，就应尽快预警并处理 - MySQL 启动后执行
tail -f /var/log/mysql/error.log，等待几秒看到ready for connections，才能说明日志功能真正正常；如果只有启动信息却没有后续内容，可能是 SELinux 阻止了写入
最容易被忽略的细节通常是：配置文件虽然改了，却没有重启 MySQL；或者已经重启了，但没有 reload 权限（FLUSH PRIVILEGES）。因此在 MySQL 上线 checklist 中，这两步必须通过手动命令逐项验证，不能只凭经验、记忆或截图判断。
