MySQL 5.7.2+ 已废弃 log_warnings，应改用 log_error_verbosity 控制警告日志级别，并排查 sql_mode 严格模式、慢查询日志配置及错误日志轮转等问题。
MySQL警告日志太多，log_warnings 参数早该停用了
MySQL 5.7.2+ 已废弃 log_warnings，继续配置它不仅无效，还会让启动时抛出警告：[Warning] 'log_warnings' is deprecated and will be removed in a future release.。这个参数原本控制是否记录警告到错误日志，但新版统一由 log_error_verbosity 管理。
实操建议：
- 检查当前值：
SELECT @@global.log_warnings;—— 如果返回非 0，说明配置残留 - 立刻从
my.cnf或my.ini中删掉log_warnings=1这类行 - 改用
log_error_verbosity：值为1（仅 error）、2（error + warning）、3（全量，含 note） - 动态生效需重启 MySQL；若用
SET GLOBAL log_error_verbosity = 2;，仅对新连接生效，且重启后丢失
为什么改了 log_error_verbosity 还在狂打警告？
常见错因是没关掉 sql_mode 里的严格模式相关项，比如 STRICT_TRANS_TABLES 或 STRICT_ALL_TABLES。它们会让本该静默的隐式类型转换、截断、零日期等行为直接触发 warning 级别日志。
实操建议：
- 查当前模式：
SELECT @@sql_mode; - 若含
STRICT_*，且业务能容忍宽松处理（如老系统迁移），可临时去掉：SET GLOBAL sql_mode = 'NO_ENGINE_SUBSTITUTION'; - 更稳妥的做法是定位具体 SQL：在警告日志里找类似
Incorrect integer value: '' for column 'age' at row 1的提示，针对性修复应用层传参或建表默认值 - 注意：
sql_mode是会话级变量，只改GLOBAL不影响已有连接，需同步改应用连接串或初始化语句
slow_query_log 开着也会刷警告日志？
是的。当开启慢查询日志但未设置 long_query_time（或设为 0），MySQL 会把每条语句都当作“慢查询”记录，而部分语句执行失败或被中断时，会连带写 warning 到错误日志，造成干扰。
实操建议：
- 确认慢查是否真需要全量记录：
SELECT @@slow_query_log, @@long_query_time; - 生产环境
long_query_time建议 ≥ 1.0（秒），避免日志爆炸；设为 0 仅限调试，且必须配合log_output = 'TABLE'避免文件 I/O 压力 - 如果只是想监控性能瓶颈，优先用
performance_schema查events_statements_summary_by_digest，比日志更轻量、可聚合
错误日志路径和轮转没配好，警告堆满磁盘
MySQL 默认不自动轮转错误日志，mysqld 进程一直追加写入，一旦警告高频出现（比如批量导入时字段长度超限），单个 hostname.err 文件几天就能涨到几十 GB。
实操建议：
- 确认当前路径：
SELECT @@log_error;，确保目录有足够空间且 MySQL 进程有写权限 - 启用轮转：Linux 下用
mysqladmin flush-logs手动切分；或配 logrotate，注意 postrotate 调用mysqladmin flush-logs否则新日志仍写旧文件 - Windows 下无原生轮转，建议用任务计划调用
mysqladmin -u root -p flush-logs，并删除 7 天前的.err文件 - 别依赖
max_error_count—— 它只控制 SHOW ERRORS 输出条数，和日志文件无关
真正麻烦的是警告背后的真实问题：比如主从延迟触发的 Seconds_Behind_Master 波动警告，或是 InnoDB 缓冲池频繁刷脏页导致的 Buffer pool hit rate 提示。这些不是调个参数就能压下去的，得顺着日志里的上下文去查状态、查锁、查执行计划。
