慢查询日志在sql完全执行完毕、所有锁释放后异步写入，不阻塞执行路径；其开销远低于未优化sql引发的性能问题，真正影响性能的是低效查询本身而非日志功能。
慢查询日志的写入时机决定了它不参与SQL执行路径
MySQL只在一条SQL**完全执行完毕、所有锁已释放之后**，才去判断是否要记入慢查询日志。这意味着日志写入动作和查询执行本身是解耦的，不会阻塞、不会抢占执行线程，也不会影响语句的解析、优化或存储引擎层的数据读取流程。
日志开销远低于业务卡顿本身的代价
慢查询日志本质上是一次异步、低频、小体积的磁盘追加写（或插入到 mysql.slow_log 表）。即使每秒写入几十条记录，其I/O压力也远小于一条未优化的 SELECT * FROM orders WHERE user_id = ? 在无索引时引发的全表扫描——后者可能瞬间扫几百万行、占满Buffer Pool、拖垮并发。
-
slow_query_log开关本身几乎不消耗CPU，只是加了个条件判断 -
long_query_time是浮点比较，成本可忽略 - 真正有开销的是日志落盘动作，但它是批量缓冲后写的，不是每条都
fsync - 若用
log_output = 'TABLE'，写入的是内存表mysql.slow_log，比文件还轻量
容易被误判为“有性能影响”的几个假象
你看到系统变慢，未必是慢日志导致的——更可能是它恰好暴露了原本就存在的问题：
- 把
long_query_time设成0后日志暴增，磁盘被打满 → 本质是磁盘配置不足或没配logrotate，不是日志功能本身重 - 开启
log_queries_not_using_indexes = 1后QPS下降 → 真凶是那些高频低效的全表扫描SQL，日志只是把它们显性化了 - 用
pt-query-digest分析日志时CPU飙升 → 分析工具在应用层跑，和MySQL服务无关
真正该警惕的不是“开不开”，而是“怎么查”
慢查询日志本身很轻量，但如果你只盯着日志里那几条 Query_time: 3.245612，却不看后面的 Rows_examined: 892341 和 Rows_sent: 20，就等于拿着雷达图却不去看敌机高度和航向。日志的价值不在记录动作，而在于提供可追溯的、带上下文的性能快照——这个快照越准，后续用 EXPLAIN 或 performance_schema 定位根因就越快。
