slow_query_log=ON后long_query_time不生效，因该参数有全局与会话作用域之分：SET GLOBAL仅影响新连接，旧连接需单独SET SESSION；MySQL 5.6及更早版本不支持小数，设0.5等同于0。
slow_query_log=ON 之后，long_query_time 不生效？
MySQL 启用慢查询日志后，long_query_time 设为 0.5 却发现 0.3 秒的查询也被记录——大概率是没设对作用域。这个参数在会话级和全局级都能设，但只有全局值影响新连接的默认行为；而旧连接沿用自己创建时的会话值，不会自动刷新。
-
SET GLOBAL long_query_time = 0.5;生效于后续新连接，当前连接需额外执行SET SESSION long_query_time = 0.5; - 若用命令行临时设置，重启 MySQL 后失效；必须写进配置文件（如
/etc/my.cnf或/etc/mysql/mysql.conf.d/mysqld.cnf）的[mysqld]段落才持久 - 注意：MySQL 5.7+ 默认启用微秒精度，
long_query_time可设小数；但 5.6 及更早版本只支持整数秒，设 0.5 实际按 0 处理（即记录所有查询）
my.cnf 里 slow_query_log_file 路径权限不对，日志写不进去
配置了 slow_query_log_file = /var/log/mysql/mysql-slow.log 却发现日志文件始终为空，检查 slow_query_log 已 ON、long_query_time 也合理——八成是 MySQL 进程用户（通常是 mysql）没权限在目标目录创建或写入文件。
Pandas 配置文件报告生成器
下载
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
- 先确认 MySQL 运行用户：
ps aux | grep mysqld | grep -v grep看 USER 列 - 确保路径父目录存在且可写：
sudo mkdir -p /var/log/mysql && sudo chown mysql:mysql /var/log/mysql - 避免写到根分区或 /tmp 下：某些系统会挂载 noexec/nosuid，或日志轮转策略误删
- 不要用相对路径（如
./slow.log），MySQL 会解析为 datadir 下，容易误判
为什么设置了 log_queries_not_using_indexes，慢日志突然暴增？
开启 log_queries_not_using_indexes = ON 后，慢日志体积猛涨、磁盘告警，甚至拖慢实例——这不是误配，而是该参数本身不看 long_query_time，只要没走索引就记，哪怕执行时间只有几毫秒。
- 它和慢查询日志是两个开关：一个控制“是否记录”，一个控制“记录哪些”，二者叠加会导致大量低开销但无索引的查询涌入日志
- 仅建议在诊断阶段临时开启，上线前务必关掉；日常监控靠
long_query_time+ 索引优化更可控 - 如果必须长期开启，至少配合
min_examined_row_limit（例如设为 1000），跳过扫描行数极少的无索引查询
MySQL 8.0+ 的 slow_query_log_file 自动带时间戳？
升级到 MySQL 8.0.14+ 后，发现 slow_query_log_file 配置项即使写死路径，实际生成的日志文件名却带日期后缀（如 mysql-slow.log.2024-05-20）——这是新增的滚动行为，不是 bug。
- MySQL 8.0.14 引入了自动慢日志轮转，由
slow_query_log_timestamp控制，默认 ON；设为 OFF 可禁用该行为 - 轮转触发条件是 MySQL 重启或执行
FLUSH SLOW LOGS，不是按时间或大小自动切割 - 如果用外部工具（如 logrotate）管理日志，建议显式关闭
slow_query_log_timestamp = OFF，避免双重轮转冲突
