MySQL错误日志配置：避开这三个“隐形坑”，让故障排查不再抓瞎
说起MySQL的错误日志，很多人的第一反应是：这还不简单？不就是配个路径的事儿嘛。但实际操作起来，你会发现，从配置生效到真正看到有用的日志，中间隔着好几个“隐形坑”。今天，咱们就来把这几个关键点掰扯清楚。
log_error 参数必须在启动时生效，运行时无法修改
首先得明确一个核心原则：log_error 这个参数，是个“启动时设定”的变量。什么意思呢？它只能在MySQL服务启动之前，通过配置文件或者命令行参数来指定。如果你试图在数据库运行过程中，用 SET GLOBAL log_error = '/new/path/error.log' 这样的命令去动态修改，系统会毫不客气地给你抛出一个错误：Variable 'log_error' is a read only variable。
这就意味着，任何路径的变更，都必须重启MySQL服务才能生效。对于线上环境而言，这可不是个小动作，必须提前评估好停机窗口。
- 标准做法：将配置写入
my.cnf（或my.ini）配置文件的[mysqld]段落里。比如：[mysqld] log_error = /var/log/mysql/error.log
- 权限陷阱：光配好路径还不够，你指定的目录必须真实存在，并且MySQL进程（通常是mysql用户）对这个目录拥有写权限。否则，服务启动会直接失败，并报错
Can't open the error log file。 - 默认行为：如果你没有显式设置
log_error，MySQL会采用默认策略——将错误日志写入数据目录（datadir）下，文件名为主机名.err。具体路径可以通过执行SELECT @@datadir;来查看。
错误日志不记录 SQL 执行异常，只记录服务级事件
这里有个非常普遍的误解：以为错误日志会记录所有在数据库里发生的错误。其实不然。你不会在 log_error 文件里找到像 ERROR 1062 (23000): Duplicate entry（主键冲突）或者 ERROR 1048 (23000): Column cannot be null（空值插入）这类SQL执行层面的报错。
那么，它到底记什么呢？它专注记录的是MySQL服务（mysqld）自身生命周期和运行状态的关键事件。你可以把它理解为MySQL服务器的“健康体检报告”和“重大事件记录仪”。
- 典型内容：服务启动和关闭的完整过程（
mysqld: Shutdown complete）、非正常关闭后的恢复信息（InnoDB: Database was not shut down normally）、插件加载失败（Plugin 'audit_log' init function returned error）、权限校验失败、内存分配错误等。 - SQL错误去哪了：想捕获应用执行SQL时抛出的错误？你得另寻他路。通常，这需要依靠客户端的连接日志、在应用程序代码层进行try-catch捕获，或者在极端调试情况下，开启
general_log（通用查询日志）来记录所有语句。但务必注意，开启通用日志对性能影响巨大，绝不能在生产环境长期开启。 - 关于崩溃堆栈：如果MySQL因为段错误（如 signal 11）而崩溃，错误日志里通常只会留下一个简单的提示。完整的调用堆栈信息，需要你同时启用核心转储（core dump）功能并配置了
core-file参数，才能从生成的core文件中分析得到。
Linux 下要注意 SELinux 或 AppArmor 的路径拦截
这是Linux环境下最容易让人“懵圈”的一个坑。你的配置文件写得明明白白，目录权限也检查了八百遍，全是755和mysql:mysql，可MySQL就是启动不了，或者启动后日志文件死活创建不出来。这时候，凶手很可能就是系统的安全增强模块——SELinux（常见于RHEL/CentOS系列）或AppArmor（常见于Ubuntu/Debian系列）。
这些安全策略会严格限制进程可以访问的文件路径，即使从传统权限角度看一切正常，它们也会拦截mysqld向非标准目录的写入操作。
- 如何排查：服务启动失败后，别光看MySQL的报错。对于SELinux，可以运行
sudo ausearch -m a vc -ts recent | grep mysqld来查看相关的安全审计日志。对于AppArmor，可以运行sudo aa-status | grep mysql来确认MySQL的配置档案是否处于强制模式。 - 临时解决方案（慎用）：在SELinux环境下，可以执行
sudo setsebool -P mysqld_disable_trans 1来临时关闭对MySQL的限制（生产环境不推荐）。更规范的做法是使用semanage fcontext命令为你自定义的日志路径添加上下文标签。在Ubuntu上，也可以通过一系列命令将MySQL的AppArmor配置移入禁用目录并重载策略来临时解决。 - 核心建议：最一劳永逸的方法，是查阅官方文档，按照规范为你计划使用的日志目录配置正确的SELinux上下文或AppArmor规则。
log_error 配置后仍没生成文件？先确认是否启用了 log_error_verbosity
好不容易路径、权限、安全策略都搞定了，日志文件也创建了，可打开一看，里面空空如也，或者只有寥寥几行。别急，很可能你忽略了另一个关键控制阀：log_error_verbosity。
这个从MySQL 5.7.2版本引入的参数，专门控制错误日志的详细程度。它默认值是3，但如果不小心被改动了，就会直接导致日志“沉默”。
- 级别含义：值为1时，系统只记录最严重的错误（ERROR）；值为2时，会增加记录警告（Warning）；只有设置为3，才会记录所有信息，包括通知类（Note）消息。如果这个值被设成了1，那么很多你期望看到的启动信息、状态变更都不会被记录。
- 查看与设置：随时可以通过
SELECT @@global.log_error_verbosity;来查看当前值。如果需要调整，可以执行SET GLOBAL log_error_verbosity = 3;来临时生效，但别忘了在配置文件中也修改，以便重启后持久化。 - 性能平衡：把详细度调到最高（3）固然信息全面，但在高并发、高负载的生产环境下，可能会导致错误日志体积快速增长，增加磁盘I/O压力。一个折中的方案是保持
log_error_verbosity=3，但同时利用log_error_suppression_list参数来过滤掉一些已知的、频繁出现但无关紧要的“噪音”信息，比如某些网络包读取超时的提示。
说到底，配置log_error远不止是写一行路径那么简单。它涉及到配置生效时机、日志内容范畴、系统安全策略、输出详细级别这四个层面的协同。最常见的连环坑就是：改了配置以为万事大吉，却忘了重启服务；或者对着一个空日志文件苦思冥想，压根没想起来去检查一下log_error_verbosity是不是被调到了最低档。把这几个关节打通，你的错误日志才能真正成为故障排查时的“火眼金睛”。
