上线前须验证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 <code>线上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。
