上线前须验证MySQL版本兼容性、配置生效性、用户权限最小化及日志可用性，否则易引发查询失败、连接中断等可预防故障。

确认 MySQL 版本与线上应用兼容性

线上部署前最常踩的坑是版本不匹配：比如应用依赖 JSON 类型字段，却在 MySQL 5.6 上部署（该类型仅从 5.7.8 起支持）；或用了 GROUP BY 严格模式，但在旧版默认关闭时本地能跑、线上报错。

• 用 SELECT VERSION(); 查看实际版本，而非仅看安装包名
• 检查应用文档中明确声明的最低/推荐版本，特别注意小版本号（如 8.0.28 修复了某些连接池超时 bug）
• 若使用 Docker，确认 mysql:8.0 这类 tag 对应的是具体 minor 版本（Docker Hub 上 8.0 可能指向 8.0.33 或 8.0.34，行为有差异）

检查 my.cnf 中关键上线参数是否生效

很多团队把配置文件拷过去就认为“配好了”，但 MySQL 启动时可能没加载到预期配置，或被命令行参数覆盖。必须验证运行时实际值。

• 执行 SHOW VARIABLES LIKE 'max_connections';，对比 my.cnf 中设置值，不一致说明配置未生效
• 重点关注：innodb_buffer_pool_size（建议设为物理内存 50%–75%，但不能超过可用内存）、wait_timeout（避免连接池因超时被服务端断开）、sql_mode（线上建议包含 STRICT_TRANS_TABLES）
• 用 mysqld --verbose --help | grep "Default options" 确认 MySQL 实际读取的配置文件路径，避免改了 /etc/my.cnf 却启用了 /usr/etc/my.cnf

验证用户权限与网络访问控制

开发环境常直接用 root@localhost，但线上必须按最小权限原则建专用用户，且权限范围要精确到库+IP段。

• 执行 SELECT user, host FROM mysql.user;，确认无 '%'@'%' 这类宽泛 host（尤其禁止 root 允许远程登录）
• 用 SHOW GRANTS FOR 'app_user'@'10.20.%.%'; 检查权限是否仅含 SELECT, INSERT, UPDATE, DELETE，不含 DROP、CREATE 或 FILE
• 在应用服务器上手动测试连接：mysql -h 线上IP -u app_user -p -P 3306 -D app_db，别只信 ping 通——MySQL 层防火墙（skip-networking 或 bind-address 配置）可能拦住 TCP 连接

确认慢查询与错误日志已启用并落盘

线上出问题时，没有日志等于盲操作。但日志开关只是第一步，更关键的是路径可写、轮转正常、内容可读。

• 检查 slow_query_log = ON 且 long_query_time = 1.0（根据业务调整，但别设成 0 或空）
• 确认 log_error 指向的路径存在、MySQL 用户有写权限，且磁盘未满（df -h /var/log）
• 用 tail -f /var/log/mysql/error.log 启动后观察是否有 ready for connections，若只有启动信息无后续记录，可能是日志路径被 SELinux 或 systemd 的 ProtectSystem 拦截

SELECT @@slow_query_log, @@long_query_time, @@log_error;

所有这些检查项，漏掉任意一个都可能导致上线后出现“能连上但查不出数据”“批量任务卡死”“凌晨三点连接全挂”这类看似随机、实则可预防的问题。真正麻烦的不是配置本身，而是配置和运行时状态之间的 gap。