如何开启 MySQL 的错误日志并指定路径
MySQL 安装后默认可能不启用错误日志，或日志写入系统临时目录（如
/tmp/mysqld.err），不利于排查启动失败、连接异常等问题。必须显式配置才能稳定捕获关键错误。 编辑配置文件（通常是
/etc/my.cnf或
/etc/mysql/my.cnf），在
[mysqld]段下添加：
log_error = /var/log/mysql/error.log确保目录存在且 MySQL 进程有写权限：
sudo mkdir -p /var/log/mysql && sudo chown mysql:mysql /var/log/mysql若使用 systemd 启动，需确认
ProtectSystem=full等安全策略未阻止写入该路径（常见于 Ubuntu 22.04+ 或 RHEL 9 默认配置） 重启服务后检查是否生效：
mysql -e "SHOW VARIABLES LIKE 'log_error';"，输出应为刚配置的绝对路径
慢查询日志开启与阈值调优的关键参数
仅开启
slow_query_log = ON不够，没设
long_query_time或忽略
log_queries_not_using_indexes，会导致日志爆炸或漏掉真实慢操作。 基础启用（推荐写入配置文件）：
slow_query_log = ON<br>slow_query_log_file = /var/log/mysql/slow.log<br>long_query_time = 1.0<br>log_queries_not_using_indexes = OFF
long_query_time是浮点数，单位秒；设为
0会记录所有查询（仅调试用，切勿上生产） 若业务大量使用
SELECT *或小表 JOIN，
log_queries_not_using_indexes = ON会产生海量日志，建议先关闭，等索引优化后再开启验证 动态生效需执行：
SET GLOBAL slow_query_log = ON;，但该设置在重启后丢失，必须写入配置文件才持久
二进制日志（binlog）启用后必须注意的三件事
开启 binlog 不只为复制，也关系到恢复能力与磁盘爆满风险。很多用户开了就忘管，结果某天
/var/lib/mysql被占满。 启用 binlog 至少要配三项：
log_bin = /var/lib/mysql/mysql-bin<br>binlog_format = ROW<br>expire_logs_days = 7
log_bin值是路径前缀，不是完整文件名；MySQL 会自动生成
mysql-bin.000001等序列文件
binlog_format = ROW是当前主流选择，避免语句级复制的不确定性；但会比
STATEMENT占更多空间
expire_logs_days在 MySQL 8.0.23+ 已被弃用，应改用
binlog_expire_logs_seconds = 604800（7 天），否则配置无效且无提示
查看当前日志状态和手动刷新日志文件
配置完不验证等于没配。尤其
FLUSH LOGS这个操作，很多人以为只是“清空”，其实是轮转（rotate）——生成新文件，旧文件保留，这才是运维常态。 查当前所有日志开关状态：
mysql -e "SHOW VARIABLES LIKE '%log%';" | grep -E 'log_|binlog_'查看错误日志最后 20 行：
sudo tail -20 /var/log/mysql/error.log（注意权限） 手动轮转日志（触发新文件生成）：
mysql -e "FLUSH LOGS;"，适用于错误日志、慢日志、binlog 同时轮转 若只想轮转 binlog，用
FLUSH BINARY LOGS;；想清理过期 binlog，用
PURGE BINARY LOGS BEFORE '2024-05-01 00:00:00';配置日志不是一次性动作，
log_error路径权限、
binlog_expire_logs_seconds是否生效、
FLUSH LOGS后文件是否真正轮转——这些细节不验证，出问题时根本找不到线索。
