CREATE INDEX后查询未提速的三大主因：未命中索引列、隐式类型转换、数据分布不均；需用EXPLAIN验证type、key及rows是否达标。
为什么 CREATE INDEX 后查询没变快？
常见错觉是“加了索引就一定提速”，实际往往无效，核心原因有三个：
一是查询条件没命中索引列（比如 WHERE status = 'active'，但索引建在 created_at 上）；
二是索引列存在隐式类型转换（如字段是 VARCHAR，但查询用数字 WHERE user_id = 123）；
三是数据分布极不均匀（比如 is_deleted 只有 0.1% 是 1），MySQL 认为走索引比全表扫描还贵。
验证方式很简单：用 EXPLAIN 看 type 是否为 ref 或 range，且 key 显示用了哪个索引；同时检查 rows 是否显著小于表总行数。如果 rows 接近全表，说明索引没被有效利用。
复合索引的列顺序到底怎么排？
顺序不是按“常用程度”或“字段长短”，而是严格遵循最左前缀匹配原则。比如建了 INDEX (a, b, c)，它能加速：WHERE a = ?WHERE a = ? AND b = ?WHERE a = ? AND b = ? AND c = ?
但对 WHERE b = ? 或 WHERE a = ? AND c = ? 无效。
实操建议：
• 等值查询列放最左（如 user_id、tenant_id）
• 范围查询列（>、BETWEEN）放中间，且只能有一个
• 排序或分组列（ORDER BY created_at DESC）可放最后，避免额外排序
一个典型反例：INDEX (status, created_at) 对 WHERE created_at > '2024-01-01' ORDER BY id 几乎无用——因为 created_at 不是最左列，且 id 没进索引。
什么时候加索引反而拖慢写入？
每新增一条记录，MySQL 不仅要写数据页，还要同步更新所有相关索引树。索引越多，INSERT/UPDATE/DELETE 越慢，尤其当索引列本身更新频繁时（如 updated_at 字段上的索引）。
需要权衡的几个信号：
• 单表索引数超过 5–6 个，且写入 QPS > 500/s
• innodb_buffer_pool_wait_free 监控值持续非零（说明 Buffer Pool 压力大，索引页刷盘变慢）
• Handler_write 和 Handler_read_rnd_next 比值严重失衡（写放大明显）
临时缓解办法：
• 把低选择性列（如 gender、is_verified）从单独索引改为覆盖索引的一部分
• 对只读历史分区表，可考虑 DROP INDEX 释放空间和写开销
如何量化一次索引改动的真实收益？
别只看单条 SQL 的 EXPLAIN，要测真实负载下的变化。步骤很直接：
• 在低峰期用 pt-query-digest 抓取 15 分钟慢日志，提取 top 10 查询
• 对目标查询，在测试库执行 SELECT ... FOR UPDATE 或带 SQL_NO_CACHE（MySQL 5.7）强制绕过缓存
• 记录执行时间、Handler_read_next、Innodb_buffer_pool_read_requests 三项指标
• 对比加索引前后：若平均耗时降 30%+ 且 Handler_read_next 减少 50% 以上，才算有效
容易被忽略的一点：
索引对“连接查询”的收益常被高估。比如 JOIN users ON orders.user_id = users.id，即使 orders.user_id 有索引，若 users 表没主键或没走主键查找，整体性能仍可能卡在驱动表选择上——这时候得看 EXPLAIN 的 table 执行顺序，而不是只盯单个索引。
