MySQL索引优化核心是建得准而非建得多，需遵循最左匹配原则、选择高区分度字段作前导列，并避免函数操作导致索引失效。
MySQL索引优化的核心是让查询尽可能走索引、减少扫描行数、避免回表和失效场景。关键不在于建得多，而在于建得准。
选择高区分度的列作为索引前导列
索引生效依赖最左匹配原则。如果联合索引是 red">(status, create_time, user_id)，那 WHERE status = 1 AND create_time > '2024-01-01' 能用上前两列；但 WHERE create_time > '2024-01-01' 就完全用不上这个索引。
- 优先把查询中 过滤性最强（值分布最散） 的字段放在联合索引最左边，比如 order_no（唯一）比 status（常见 0/1/2）更适合做首列
- 避免在索引列上做函数操作或隐式类型转换，如 WHERE DATE(create_time) = '2024-01-01' 会让索引失效，应改写为 WHERE create_time >= '2024-01-01' AND create_time
覆盖索引减少回表开销
当 SELECT 的字段全部包含在索引中，MySQL 就不用回到主键索引再查数据行，这种叫“覆盖索引”，能显著提升性能。
Yes!SUN企业网站系统 3.5 Build 20100303
下载
Yes!Sun基于PHP+MYSQL技术，体积小巧、应用灵活、功能强大，是一款为企业网站量身打造的WEB系统。其创新的设计理念，为企业网的开发设计及使用带来了全新的体验：支持前沿技术：动态缓存、伪静态、静态生成、友好URL、SEO设置等提升网站性能、用户体验、搜索引擎友好度的技术均为Yes!Sun所支持。易于二次开发：采用独创的平台化理念，按需定制项目中的各种元素，如：产品属性、产品相册、新闻列表
- 例如常查 SELECT user_id, status, update_time FROM orders WHERE status = 1 ORDER BY update_time DESC，可建联合索引 (status, update_time, user_id) —— 三个字段都涵盖，无需回表
- 注意：SELECT * 很难被覆盖，应明确列出需要的字段
精简索引数量，定期清理冗余索引
每个索引都会增加写入成本（INSERT/UPDATE/DELETE 都要维护索引），且可能相互干扰。MySQL 不会自动识别重复或包含关系的索引。
- 用 SELECT * FROM sys.schema_redundant_indexes;（需启用 sys schema）或 pt-duplicate-key-checker 工具识别冗余索引
- 例如已有 (a, b, c)，再建 (a, b) 就是冗余；已有 (a) 和 (a, b)，单独的 (a) 通常可删
- 对低频更新、高频查询的表可适度增加索引；对日志类写多读少的表，索引宜保守
利用执行计划验证索引是否生效
别猜，要看 EXPLAIN 结果。重点关注 type、key、rows、Extra 这几列。
- type 最好是 const、ref、range；ALL 表示全表扫描，危险信号
- key 显示实际使用的索引名；NULL 表示没走索引
- rows 是预估扫描行数，越小越好；若远大于结果集行数，说明索引选择不佳或统计信息过期（可用 ANALYZE TABLE 更新）
- Extra 中出现 Using filesort 或 Using temporary 说明排序/分组未走索引，需检查是否缺失排序字段索引
