应优先为执行频率高且rows_examined远大于rows_sent的sql加索引；通过explain判断索引缺失或覆盖不全，按where和order by字段顺序创建联合索引，并验证统计信息更新及实际执行效果。
怎么看慢查询日志里真正该加索引的SQL？
慢查询日志里一堆 SELECT，但不是每条都值得加索引。关键看两点：执行频率高 + 扫描行数远大于返回行数。比如 Rows_examined: 124800 但 Rows_sent: 12，这种大概率缺索引；而 Rows_examined: 45、Rows_sent: 42 的，加索引收益极小，还可能拖慢写入。
实操建议：
- 用
mysqldumpslow -s t -t 10 /var/lib/mysql/slow.log先抓最耗时的前10条 - 对每条结果，用
EXPLAIN FORMAT=TRADITIONAL看执行计划，重点盯type是否为ALL或index，以及key是否为NULL - 跳过带
ORDER BY RAND()、LIMIT很大但业务上实际只取前几条的语句——这类优化靠索引效果有限
怎么用EXPLAIN判断该建什么索引？
EXPLAIN 输出里的 possible_keys 为空、key 为 NULL，说明没走任何索引；如果 key 有值但 Extra 出现 Using filesort 或 Using temporary，说明现有索引覆盖不全。
实操建议：
- WHERE 条件字段顺序决定索引最左前缀匹配逻辑，比如
WHERE status = 'active' AND created_at > '2023-01-01'，优先建(status, created_at)而非反过来 - 如果还有
ORDER BY created_at，且created_at在 WHERE 中是范围条件（如>），那(status, created_at)仍能避免Using filesort；但如果是ORDER BY user_id，就得把user_id加到最后，变成(status, created_at, user_id) - 别盲目加
SELECT *里所有字段的联合索引——覆盖索引虽快，但索引体积膨胀快，优先保障 WHERE + ORDER BY 字段
建完索引后怎么验证是不是真生效了？
执行 ALTER TABLE ... ADD INDEX 后，不能只看 EXPLAIN 显示用了新索引就认为万事大吉。MySQL 可能因统计信息滞后或代价估算偏差，实际运行时仍走旧路径。
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
实操建议：
- 在业务低峰期执行
ANALYZE TABLE table_name更新统计信息 - 用
SELECT /*+ USE_INDEX(t idx_status_created) */ ... FROM table_name t WHERE ...强制走新索引，对比执行时间与Rows_examined - 查
information_schema.INNODB_METRICS或开启performance_schema，观察该 SQL 的io_read_bytes和exec_count是否下降 - 特别注意：如果表有大量写入，新加的二级索引会拖慢
INSERT/UPDATE，需结合SHOW PROFILE FOR QUERY N看是否Handler_write显著增加
哪些“看起来该加”的索引其实不该加？
低基数字段（如 gender、is_deleted）单独建索引几乎无效；高频更新字段（如计数器、状态流转字段）建索引会放大写锁开销；还有全文检索、JSON 字段解析类查询，B+ 树索引根本不管用。
实操建议：
- 对
ENUM或只有 2–3 个值的字段，除非配合其他高选择性字段构成联合索引，否则别单独立索引 - 写多读少的表（如日志表），优先考虑分区（
PARTITION BY RANGE）而非索引 -
LIKE '%xxx'查询无法使用 B+ 树索引，得换FULLTEXT或外部搜索引擎 - MySQL 8.0+ 的函数索引（如
CREATE INDEX idx_email_lower ON users (LOWER(email))）有用，但要注意应用层是否统一用了对应函数调用，否则索引形同虚设
真正麻烦的不是找缺失索引，而是判断某个字段组合在不同查询模式下要不要拆成多个索引、要不要包含额外字段做覆盖——这得看真实执行计划和业务查询分布，没法靠规则穷举。
