直接看 SHOW ERRORS
，但别只信它返回的第一行
执行 SQL 报错后，
SHOW ERRORS是最快速拿到错误码和消息的方式，但它只显示“当前会话中尚未读取的错误”，且不保留历史——上一条语句的错误一旦被读过，再执行一次
SHOW ERRORS就可能为空。更关键的是，它不显示上下文（比如触发错误的完整 SQL、绑定参数、存储过程调用栈），所以容易误判。 立即执行：
SHOW ERRORS LIMIT 1查最近一条；
SHOW WARNINGS更全面，包含警告（如隐式类型转换、数据截断） 注意会话隔离：不同连接之间的错误互不影响，应用层报错后，需在**同一连接内**立刻查，否则丢失 错误码比文字描述更可靠：例如
1064永远是语法错误，而 “You have an error…” 这段提示在不同版本里措辞可能变化
从错误日志里找真实现场，重点盯 [ERROR]
上下 5 行
SHOW ERRORS只管客户端 SQL 层，而服务崩溃、启动失败、InnoDB 崩溃、权限校验失败等底层问题，全靠错误日志。很多人只搜
[ERROR]行，结果漏掉真正线索——比如
[ERROR] InnoDB: Database page corruption前面一行可能是
[Warning] InnoDB: Retry attempts for writing partial data failed，再往前是
[ERROR] Could not open /var/lib/mysql/ibdata1，这三行串起来才指向磁盘只读或文件系统损坏。 先确认路径：
SHOW VARIABLES LIKE 'log_error'，别信配置文件里的
log-error（MySQL 8.0+ 只认
log_error） 实时观察重启过程：
tail -f /var/log/mysql/error.log，看到
[Note] mysqld: ready for connections才算真正启好 过滤关键信号：
grep -B 3 -A 2 "signal 11\|crash\|corruption" /var/log/mysql/error.log，
signal 11往往意味着 core dump，单看日志不够，得结合
gdb
应用报错时，必须交叉比对时间戳和连接 ID
应用层报错如 “Access denied for user 'app'@'10.0.1.5'” 或 “Too many connections”，看着明确，但日志里可能有多个同名用户、多条相似错误，光靠文字匹配容易张冠李戴。真正可靠的锚点是时间 + 连接 ID。
应用报错时记下精确时间（毫秒级），然后在错误日志里用grep "2026-01-28T16:12:03"定位（日志默认带 ISO 时间戳） 在应用代码里打印
connection_id()，再查
SHOW PROCESSLIST对应 ID 的
Host和
Command，确认是不是它触发了锁等待或超时 如果错误日志里没找到对应记录，检查是否
log_error_verbosity=1（只记 ERROR），需设为 2 或 3 并重启才能捕获 WARNING 级线索
用 perror
和官方文档查错误码，别靠搜索引擎猜
错误码是 MySQL 内部唯一稳定的标识，
1045在所有版本里都代表认证失败，但网上搜到的“解决方法”可能早过时（比如教你在
my.cnf里加
skip-grant-tables，却忽略 8.0+ 的密码插件变更）。本地查最准。 Linux 下直接运行：
perror 1045→ 输出
MySQL error code 1045 (ER_ACCESS_DENIED_ERROR): Access denied for user '%s'@'%s' (using password: %s)Windows 没
perror？用 MySQL 官方文档页搜索 “ER_ACCESS_DENIED_ERROR”，选你正在用的版本（如 8.0.33），看“SQL Statement That Causes Error”和“Resolution”两栏 程序中捕获时，优先记录
e.args[0]（错误码）而非
e.args[1]（消息），后者可能被自定义 SQL_MODE 修改 错误日志不是“报错记录本”，它是 MySQL 运行状态的快照切片。真正难的不是找到那行
[ERROR]，而是把这一行和前几行的 Warning、同一秒的 OS 日志（
dmesg | tail -20）、以及应用侧的请求链路（比如某次事务提交耗时突增）拼成完整事件链——缺任何一块，都可能把磁盘故障当成 SQL 写错了。
