错误日志没写入文件，大概率是log_error_services缺少log_sink_internal、log_error路径不存在或mysql用户无写权限、log_error_verbosity=3淹没关键错误，需依次检查组件链、路径权限及日志级别。
错误日志没写入文件，大概率不是 MySQL 没想写，而是它根本没权限写、没地方写、或者压根没被配置成写文件。
log_error_services 缺少 log_sink_internal
MySQL 8.0 的错误日志不是靠 log_error 单独驱动的，而是由 log_error_services 定义的组件链决定是否落盘。如果里面没有 log_sink_internal，日志就完全不会写进文件——哪怕 log_error 路径再正确也没用。
- 执行
SELECT @@GLOBAL.log_error_services;，正常应返回类似log_filter_internal; log_sink_internal - 若返回空、含
log_sink_null、或只有log_filter_internal，说明输出端被禁用 - 立即修复：
SET PERSIST log_error_services = 'log_filter_internal; log_sink_internal'; - 注意：仅改配置文件不生效；
SET PERSIST会写入mysqld-auto.cnf，重启后仍有效 - 若 MySQL 已无法启动，必须手动编辑
/etc/my.cnf（Linux）或my.ini（Windows），在[mysqld]段中加入该行
log_error 路径不可写或不存在
MySQL 启动失败时，log_error 路径若指向一个不存在的目录、或 mysql 用户无写权限，服务会静默退出——连“写日志失败”都不会记。
-
log_error必须是绝对路径，例如log_error = /var/log/mysql/error.log；相对路径如log_error = error.log会被拼到datadir下，极易误判 - 手动创建目录并授权：
sudo mkdir -p /var/log/mysql && sudo chown mysql:mysql /var/log/mysql（Linux） - Windows 下需右键目录 → “安全” → 给 MySQL80 服务账户添加“写入”和“修改”权限
- 验证路径是否真正生效：
mysqld --defaults-file=/etc/my.cnf --verbose --help | grep "log_error"，确认输出是你设的路径 - SELinux 启用时（如 CentOS/RHEL），还需运行
sudo setsebool -P mysqld_disable_trans on或调整上下文
log_error_verbosity = 3 掩盖了真实错误
默认值 log_error_verbosity = 3 会塞入大量 [Note] 级别日志（如插件弃用、SSL 加载成功），把真正的 ERROR 和 WARNING 挤到几百行之后，甚至翻不到。
- 生产环境建议设为
2：SET GLOBAL log_error_verbosity = 2;（动态生效，重启失效） - 永久生效需在配置文件中加：
log_error_verbosity = 2 - 该设置不影响日志是否写入，但影响你能否一眼看到崩溃线索——比如
mysqld: Can't open error log file这类关键提示常被淹没在一堆[Note]里
systemd 或 journald 接管了日志输出
在现代 Linux 发行版（如 Ubuntu 20.04+、CentOS 8+）中，MySQL 常由 systemd 管理，而 log_error 可能被设为 NULL，此时日志实际走 journald，而不是文件。
- 运行
SELECT @@log_error;，若返回NULL，说明未启用传统文件日志 - 检查是否被重定向：
journalctl -u mysqld -n 50 -f，看是否有启动报错 - 要强制写入文件，必须在配置文件中显式设置
log_error并确保路径可写，然后systemctl restart mysql - 注意：
log_error不可动态修改，改完必须重启，reload无效
最常被忽略的是：MySQL 在崩溃前写的最后一行日志，可能就卡在权限校验失败、目录未创建、或组件链断裂的瞬间——它不会告诉你“我失败了”，只会沉默退出。所以排查不能只盯日志内容，得先确认日志本身有没有机会被写出来。
