应禁用log_queries_not_using_indexes=on，改设min_examined_row_limit=1000并配合long_query_time=1，优先使用log_output=file避免i/o竞争，永久配置写入/etc/my.cnf的[mysqld]段。
怎么开慢查询日志才不拖垮磁盘和性能
直接开 log_queries_not_using_indexes = ON 是最常见也最危险的操作——它会让每条没走索引的 SQL（哪怕只查 1 行、耗时 0.1ms）都写进日志，几小时内就能填满磁盘。生产环境必须配合 min_examined_row_limit 使用。
临时启用（排查期间）建议这样配：
SET GLOBAL slow_query_log = 'ON'-
SET GLOBAL long_query_time = 1（核心业务可设为0.5） -
SET GLOBAL min_examined_row_limit = 1000（只记扫描超 1000 行的语句） -
SET GLOBAL log_queries_not_using_indexes = 'OFF'（别开）
永久配置写进 /etc/my.cnf 的 [mysqld] 段，重启生效。注意：修改后用 SHOW VARIABLES LIKE '%slow%' 确认值已加载，MySQL 8.0+ 的变量名可能带下划线，比如 slow_query_log 而非 slow-query-log。
EXPLAIN 看懂这三列就抓住慢因关键
光看 Query_time 和 Rows_examined 只知道“慢”，但不知道“为什么慢”。EXPLAIN 输出里真正要盯紧的是：
-
type：值为ALL就是全表扫描，基本等于没索引；range或ref才算合理 -
key：显示实际使用的索引名，如果是NULL，说明索引根本没被选中（可能是类型不匹配、函数包裹字段、或最左前缀没对上） -
rows：优化器预估扫描行数，如果远大于实际返回行数（比如SELECT COUNT(*)返回 1 行但rows=500000），大概率索引失效或统计信息过期
执行 EXPLAIN FORMAT=JSON 还能看到 filtered 字段，它表示条件过滤后剩余比例，低于 10% 就值得警惕——说明索引区分度太低或 WHERE 条件选择性差。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
联合索引怎么建才不白建
不是字段越多越好，也不是按表里出现顺序随便排。建错顺序，索引就形同虚设。
以查询 WHERE status = 'paid' AND create_time > '2023-01-01' ORDER BY amount DESC 为例：
- 错：
INDEX(create_time, status)→create_time是范围查询，后面字段无法命中，status实际失效 - 对：
INDEX(status, create_time)→ 等值匹配status后，再对create_time做范围扫描，符合最左前缀 - 更优：如果只查
id, status, amount，加INDEX(status, create_time, amount)→ 覆盖索引，避免回表
别碰 LIKE '%xxx' 字段建索引，也别在 WHERE 里对索引字段用函数，比如 WHERE DATE(create_time) = '2023-01-01'，会强制全表扫。
哪些参数调了反而让慢查询更难定位
有些 DBA 一上来就调大 innodb_buffer_pool_size 或调小 long_query_time，但忽略日志本身的干扰项：
-
log_output = TABLE看似方便查，但写入mysql.slow_log表本身有锁和 I/O 开销，高并发下可能拖慢正常查询；文件模式（FILE）更轻量 -
long_query_time = 0在测试环境可用，但上线后若没及时关，日志量爆炸，mysqldumpslow解析都会卡住 -
slow_query_log_file路径若落在系统盘或和datadir同一磁盘，IO 竞争会导致慢查询记录延迟，甚至丢失最后几条
真正容易被忽略的是 log_slow_admin_statements —— 它默认关，但如果你在慢日志里找不到 ALTER TABLE 或 ANALYZE TABLE 记录，就得打开它；这类语句虽不常执行，但一旦慢，影响的是整个表的可用性。
