会，开启 general_log 会明显拖慢 mysql——因其同步刷盘每条语句，高并发下极易压垮磁盘 i/o；生产环境应禁用，排查时可临时设 log_output='table' 并速开速关。
开启 general_log 会让 MySQL 变慢吗？
会，而且可能非常明显——但不是因为日志本身“慢”，而是它把所有语句无差别刷盘，直接压垮磁盘 I/O。通用查询日志（general_log）默认关闭，就是因为它在高并发下极易成为瓶颈。
-
general_log记录的是客户端发来的每一条命令（包括SELECT、USE、PING），不管是否执行成功 - 日志写入模式默认是同步的（
log_output = 'FILE'+ 系统级 fsync），每条语句都触发一次磁盘写 - 在 1000 QPS 的 OLTP 场景下，可能额外增加 20%～40% 的平均延迟，
iotop能明显看到mysqld进程持续刷盘
不建议在生产环境打开；临时排查连接/协议问题时，可改用 log_output = 'TABLE'（写入 mysql.general_log 表），再配合 SET GLOBAL general_log = 1 短期开启，用完立刻关掉。
binlog 开启反而提升 TPS？这合理吗？
合理，而且有实测支撑。在某些高并发锁竞争场景下，开 binlog 反而让整体吞吐更高——这不是玄学，是 InnoDB 提交路径被“拉长”后，意外缓解了热点锁争抢。
- 关闭
binlog时，事务提交更快，导致更多线程挤在trx_sys->mutex或lock_sys->mutex上排队 - 开启
binlog（尤其sync_binlog = 1）后，提交流程变长，线程天然错峰，锁冲突下降 - 实测中，
sysbench oltp_update_index场景下，开binlog的 TPS 比关闭时高 15%～30%，CPU 峰值反而更低
注意：这个现象只在特定负载（如中高并发、索引更新密集）下显著；低并发或纯读场景下，开 binlog 仍是净开销。别把它当成性能调优手段，而是理解“日志不是单纯累加成本”。
innodb_redo_log_capacity 太小会卡住写入？
会，而且卡得毫无征兆。InnoDB 重做日志（redo log）不是“越大越好”，但太小会导致频繁 checkpoint 和写入阻塞，尤其在批量导入或大事务场景。
-
innodb_redo_log_capacity（MySQL 8.0.30+）替代了旧版的innodb_log_file_size+innodb_log_files_in_group组合 - 如果设得太小（比如仅 64MB），当 redo log 空间快满时，InnoDB 会强制触发 sharp checkpoint，暂停用户线程等待刷脏页
- 表现为：
SHOW ENGINE INNODB STATUS中LOG部分显示Log sequence number接近Log flushed up to，同时Queries_sec断崖下跌
建议值：
- OLTP 小事务为主 → 256MB～1GB
- 批量写入/ETL 场景 → ≥2GB，并观察
Innodb_redo_log_waits状态变量是否持续非零
slow_query_log 对性能真没影响？那为什么有人一开就卡？
官方说“开销可忽略”，是指单次判断和写入动作本身很轻；但卡住的真实原因是配置不当，尤其是 long_query_time 设得太低，或日志输出目标不可靠。
-
long_query_time = 0会让所有查询都进慢日志，等效于开了general_log，I/O 压力陡增 -
log_output = 'FILE'且日志落在机械盘或 NFS 上，写入延迟会拖慢整个语句执行（哪怕只是记录一行） - 更隐蔽的问题：
slow_query_log_use_global_control = ON（MySQL 8.0.23+）未启用时，每个会话可独立开关慢日志，但若大量会话都设了long_query_time = 0.1，叠加效应就出来了
稳妥做法：
- 生产环境设
long_query_time = 0.2或0.5，避免毛刺干扰 - 用
log_output = 'TABLE'，再定期导出分析，避开实时 I/O - 检查
Slow_queries状态变量增速，异常飙升时立刻查配置
redo log 和 binlog 是数据库可靠性的基石，但它们不是“隐身”的——每一字节落地都有代价。最容易被忽略的，其实是日志路径的存储介质和权限配置：比如把 datadir 和 log_bin 放在同一块 SATA 盘上，或者 general_log_file 被 SELinux 拦截导致写入失败却静默降级，这些细节比参数值更能决定线上表现。
