如何在AWS RDS MySQL 5.6中查看查询错误与警告

首先明确你之前配置看不到目标日志的核心原因：

MySQL 5.6默认错误日志只记录服务端启动、崩溃、连接异常、主从同步这类系统级事件，log_warnings=1仅控制系统级告警的输出，不会记录单条SQL执行返回的语法错误、字段不存在这类业务语句错误；通用查询日志（general_log）只会记录服务端收到的SQL原文，不会记录SQL执行后的错误码、告警内容，所以你之前的操作看不到目标日志是正常表现，不是配置错误。

以下是按推荐优先级排序的可落地方案：

方法1：用performance_schema采集语句执行结果（优先选，无侵入、冗余最低） #

RDS MySQL 5.6默认开启performance_schema，不需要修改参数组重启实例，直接执行以下SQL开启全量语句事件采集：

UPDATE performance_schema.setup_instruments 
SET ENABLED = 'YES', TIMED = 'YES' 
WHERE NAME LIKE 'statement/%';

UPDATE performance_schema.setup_consumers 
SET ENABLED = 'YES' 
WHERE NAME LIKE 'events_statements_%';

配置完成后，所有执行过的SQL的错误、告警信息会存在两张内存表里：events_statements_history（每个连接线程留存最近1000条记录）、events_statements_history_long（全局留存最近10000条记录）。直接执行以下SQL就能筛选出所有带错误、告警的语句：

SELECT 
  THREAD_ID,
  SQL_TEXT,
  MYSQL_ERRNO,
  RETURNED_SQLSTATE,
  MESSAGE_TEXT,
  ERRORS,
  WARNINGS
FROM performance_schema.events_statements_history_long
WHERE ERRORS > 0 OR WARNINGS > 0;

注意这两张是内存表，实例重启后数据会清空，如果需要长期留存排查结果，可以定期把查询结果写入自己建的普通业务表。如果要调大全局留存的记录条数，可以在RDS参数组修改performance_schema_events_statements_history_long_size参数，最大支持设到100000，修改后需要重启实例生效。

方法2：调整慢查询日志配置捕获错误语句（适合需要持久化日志、从控制台导出的场景） #

不需要开启冗余度极高的通用日志，只要调整慢查询日志配置，就能把所有产生错误、告警的SQL单独记录下来，日志量远小于通用日志：

• 在RDS参数组修改以下参数，无需重启即可生效：
  • slow_query_log：设为1，开启慢查询日志
  • log_slow_admin_statements：设为1，记录DDL等管理语句
  • log_queries_not_using_indexes：设为0，减少无关日志输出
  • long_query_time：设为3600（1小时），先过滤正常的慢SQL
  • log_slow_slave_statements：如果挂载了只读从库，设为1记录从库执行的语句
• 执行以下SQL调整全局日志规则，RDS的MySQL 5.6小版本均支持该配置：

SET GLOBAL log_throttle_queries_not_using_indexes = 0;
SET GLOBAL log_slow_verbosity = 'full';

配置完成后，所有执行报错、带告警的SQL不管执行时长多少，都会写入慢查询日志，你可以直接在RDS控制台的日志板块查看、导出，日志里会明确标注错误码、告警数量、具体错误信息。排查结束后把参数改回原有业务配置即可。

方法3：用RDS自带的升级预检查覆盖已知兼容问题 #

AWS RDS在你发起MySQL 5.7升级操作前，会自动运行兼容预检查：

• 会自动扫描所有已知的不兼容项，包括5.6版本下是告警、升级到5.7会转为错误的场景，比如零值日期、非法时间戳、不兼容的GROUP BY写法、废弃函数调用、隐式类型转换失败等
• 预检查报告会直接列出不兼容项的类型、影响范围，不需要手动抓日志就能覆盖80%以上的固定兼容问题。注意这个检查扫不到应用动态生成的SQL运行时错误，需要配合前两种方法一起排查。

避坑说明 #

• 不要在log_warnings参数上浪费时间，就算把值开到最大2，也不会记录单条SQL的执行错误，它的作用范围仅限服务端系统级日志
• 不建议依赖应用层日志排查：大部分ORM框架会吞掉SQL执行的原始告警，只返回泛化错误，很容易漏掉零值日期插入、字段截断这类5.6下仅告警、5.7直接报错的场景
• 非必要不要开通用日志，不仅冗余度极高，还会额外占用实例IO影响业务，排查兼容问题的性价比极低。

内容的提问来源于stack exchange，提问作者user984003