慢查询指执行时间超过long_query_time阈值的SQL语句，包含锁等待、IO等全部耗时；其日志是实时性能探针，需配合工具分析模式而非单条语句，且应按需开启避免性能损耗。
慢查询就是执行时间超阈值的SQL语句
在MySQL里，“慢查询”不是主观判断，而是有明确数字标准的：只要一条SQL的执行时间超过long_query_time设定的秒数，它就算慢查询。默认值是10秒，但生产环境普遍设为1秒甚至0.5秒——因为用户等不到10秒，电商页面加载超2秒，转化率就开始掉。
注意，这个“执行时间”包含锁等待、磁盘IO、排序、临时表创建等全部环节，不只是CPU计算时间。所以一条看似简单的SELECT * FROM orders WHERE user_id = ?，如果user_id没索引、表有千万行，就很可能卡住几秒，被记入慢日志。
慢查询日志不是“备查档案”，而是实时性能探针
它的核心作用不是事后追责，而是暴露系统真实负载压力点：
-
slow_query_log开启后，每条超时SQL会记录完整语句（含实际参数）、耗时、扫描行数Rows_examined、线程ID、客户端IP——这些信息直接对应EXPLAIN里的关键指标 - 配合
log_queries_not_using_indexes = ON，还能揪出“语法正确但没走索引”的隐形杀手，比如WHERE status + 0 = 1这种隐式类型转换 - 日志本身可输出到文件（
log_output = FILE）或系统表mysql.slow_log，后者方便用SQL聚合分析，但写表有额外开销，高并发下慎用
临时开启和永久配置的关键区别
开发调试时常用动态命令快速验证：
SET GLOBAL slow_query_log = ON; SET GLOBAL long_query_time = 1; SET GLOBAL log_output = 'FILE';
但这些设置在MySQL重启后失效，且仅对新连接生效——已存在的连接不会突然开始记慢日志。真正上线必须改配置文件/etc/my.cnf，在[mysqld]段加上：
