slow_query_log未开启时，调整long_query_time无效；必须先设slow_query_log=ON（动态或配置文件），再配合合理阈值、权限、路径及log_output=FILE等配置，才能正常记录慢查询。
slow_query_log 开关没开，调 long_query_time 没用
慢查询日志根本不会写入任何内容，最常见原因就是 slow_query_log 还是 OFF。很多人只改了 long_query_time，却漏掉这一步——MySQL 不会因为阈值变小就自动开启日志引擎。
实操建议：
- 执行
SHOW VARIABLES LIKE 'slow_query_log';，确认返回值是ON（不是1或空字符串） - 动态开启用
SET GLOBAL slow_query_log = ON;，但注意：已存在的连接不生效，必须新建连接才开始记录 - 更稳妥的做法是写进配置文件
my.cnf：slow_query_log = ON，然后重启 MySQL；云数据库如阿里云 RDS 则需走控制台或参数模板修改
long_query_time 设太小却没日志？精度和取整规则在捣鬼
long_query_time 支持微秒级（如 0.15），但实际是否生效取决于 MySQL 版本和判断逻辑：5.7+ 才真正按微秒截断；旧版本会向下取整到整秒。更关键的是，MySQL 对查询耗时不向上取整——差 1 纳秒都不记。
实操建议：
- 测试时别只信
SLEEP(0.1)：系统调度可能导致实际执行0.0999秒，达不到0.1阈值；改用SLEEP(2)更可靠 - 设成
0也不等于“全量捕获”：部分管理语句（如SHOW PROCESSLIST、SELECT 1）MySQL 内部跳过记录，这不是 bug - 线上建议从
1.0起步，观察一周后根据业务 RT（比如核心接口普遍 300ms）再下调到0.3或0.5
日志路径存在但文件始终为空？权限、磁盘、SELinux 全要查
slow_query_log_file 指向的路径可能看着没问题，但 MySQL 是以启动用户（通常是 mysql）身份写入的，不是你登录的账号。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
实操建议：
- 检查目录是否存在且可写：
ls -ld /var/log/mysql/，确保属主是mysql:mysql；若不是，运行chown mysql:mysql /var/log/mysql - 用
df -h看磁盘是否已满——MySQL 遇到No space left on device会静默失败，不报错也不写日志 - SELinux 或 AppArmor 可能拦截写入，临时关闭验证：
setenforce 0（仅测试用，勿长期关闭） - 确认
log_output是FILE（默认值），不是TABLE或混合模式；查命令：SHOW VARIABLES LIKE 'log_output';
明明很慢却没进日志？慢日志只记“完成耗时”，不区分等待和执行
一条 SQL 在慢日志里显示耗时 2.4s，不代表它真花了 2.4s 在执行——可能是锁等待、IO 阻塞、或被 FLUSH TABLES WITH READ LOCK 卡住。慢日志只记录“从开始到返回结果”的总时间，不拆解 CPU 时间 vs 等待时间。
实操建议：
- 不要单靠慢日志定位瓶颈；配合
SHOW PROCESSLIST看State字段（如Waiting for table metadata lock）、INFORMATION_SCHEMA.INNODB_TRX查长事务 - 开启
log_queries_not_using_indexes = ON，把未走索引的查询也捞出来，这类语句常是性能隐患但未必超long_query_time - 从库默认不记录复制线程的慢 SQL，需额外配
log_slow_slave_statements = ON
慢查询日志本身是个简单开关，但真正让它稳定产出有效数据，得一层层验权限、版本、精度、等待类型——最容易被忽略的是：它不告诉你“为什么慢”，只告诉你“看起来慢”。
