应优先查看 show errors limit 1 获取最新错误码，但需在同一会话立即执行；错误日志更全面，须结合时间戳、连接id、上下文及 perror/官方文档交叉验证。
直接看 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 修改
[ERROR]，而是把这一行和前几行的 Warning、同一秒的 OS 日志（dmesg | tail -20）、以及应用侧的请求链路（比如某次事务提交耗时突增）拼成完整事件链——缺任何一块，都可能把磁盘故障当成 SQL 写错了。 
