必须先执行show variables like 'slow_query_log'、'long_query_time'和'slow_query_log_file'三条命令确认实际值，因默认slow_query_log=off、long_query_time=10.0对线上无效，且整型阈值如10会被忽略，仅浮点数如1.0才生效；路径权限、selinux/apparmor拦截及主从部署策略也需同步核查。
确认当前 slow_query_log 和 long_query_time 实际值
别猜，直接查。默认多数 MySQL（包括 Percona、官方二进制包）是 slow_query_log = OFF 且 long_query_time = 10.0，这对线上毫无意义。
执行以下三条命令验证真实状态：
-
SHOW VARIABLES LIKE 'slow_query_log';—— 若返回OFF，日志根本不会写，调阈值也没用 -
SHOW VARIABLES LIKE 'long_query_time';—— 注意看类型：若显示10（整型），说明你之前设过整数，它被忽略；必须是1.0这种浮点数才生效 -
SHOW VARIABLES LIKE 'slow_query_log_file';—— 确保路径存在、MySQL 用户可写，SELinux 或 AppArmor 可能拦截写入
my.cnf 中必须配置并重启，SET GLOBAL 不可靠
SET GLOBAL 是临时的，MySQL 重启即失效。生产环境必须落盘，否则监控断档就是事故。
编辑 /etc/my.cnf（或 /etc/mysql/my.cnf），在 [mysqld] 段落下添加：
-
slow_query_log = ON（不是1或TRUE，部分旧版本只认ON） -
slow_query_log_file = /var/log/mysql/mysql-slow.log（显式指定，避免默认路径权限问题） -
long_query_time = 1.0（必须带小数点，1会被当整型丢弃） - 可选但推荐：
log_queries_not_using_indexes = ON（方便发现缺失索引的查询，但日志量激增，先观察再开）
保存后执行 systemctl restart mysqld——注意：仅 reload 不生效，必须完整重启。
PyCharm 2026.2.0.1 Linux版
下载
PyCharm 2026.2.0.1 Linux版提供 JetBrains 官方 2026.2.0.1 版本安装包，适合需要指定 PyCharm 版本进行 Python 项目开发、运行和调试的用户。
为什么设置了 long_query_time 却没记录慢查询
常见错误现象：配置写了、也重启了，但日志始终为空。
原因往往不是参数错，而是：
-
slow_query_log_file路径父目录不存在，或 MySQL 进程用户（通常是mysql）无写权限；执行sudo mkdir -p /var/log/mysql && sudo chown mysql:mysql /var/log/mysql - 路径用了相对路径（如
./slow.log），MySQL 会解析为datadir下，容易误判 - SELinux 或 AppArmor 拦截写入，临时关闭测试：
setenforce 0或检查 audit 日志 - 主从架构中主库开了日志，但高写入压力下 IO 拖慢提交——强烈建议只在从库开慢日志，主库关掉
long_query_time 的统计逻辑和业务对齐要点
long_query_time 统计的是语句“执行完成耗时”，不含锁等待、网络传输、FLUSH TABLES 等阻塞时间。所以看到某条 SELECT 耗时 2.4s，未必是 SQL 本身慢，得结合 performance_schema.events_statements_summary_by_digest 查 avg_timer_wait 和 sum_lock_time 对比。
它不是越小越好，而是要对齐业务 RT 基线：
- 新上线服务建议从
1.0起步，跑一周看日志量和 DB CPU/IO 压力 - 若核心接口 P95 RT 是 300ms，就该调到
0.3 - MySQL 5.7+ 支持微秒精度（如
0.15），但旧版本会向下取整到秒，别设了白设
真正容易被忽略的是：日志是纯文本追加写，没有结构化时间戳，刷盘有延迟、可能截断；别指望 tail + awk 做实时峰值告警，那不是监控，是碰运气。
