索引是基于B+树的有序数据结构，适合等值、范围查询和排序，但对LIKE '%abc'、函数操作等无效；需通过EXPLAIN验证是否生效，遵循最左前缀、覆盖索引等原则设计，并注意线上加索引的风险。
索引是什么：B+树结构决定它不是“加速所有查询”的万能钥匙
MySQL 默认使用 B+ 树实现索引，这意味着索引本质上是一棵有序的多路搜索树，叶子节点存数据（聚簇索引）或主键值（二级索引），且叶子节点之间有双向链表。它天然适合范围查询、排序和等值查找，但对 LIKE '%abc'、JSON_CONTAINS() 或函数包裹字段（如 WHERE UPPER(name) = 'ABC'）基本无效——因为这些操作破坏了索引字段的有序性。
常见错误现象：EXPLAIN 显示 type=ALL（全表扫描），即使字段加了索引；或者 key 列为 NULL，说明优化器根本没用上索引。
- 索引不是越多越好：每增一个索引，写操作（
INSERT/UPDATE/DELETE）都要同步更新索引树，同时占用更多磁盘与内存 - 联合索引有最左前缀原则：
INDEX (a, b, c)能命中WHERE a=1、WHERE a=1 AND b=2、WHERE a=1 AND b=2 AND c=3，但无法命中WHERE b=2或WHERE c=3 - 字符串字段建索引要谨慎：默认会索引全部长度，大字段（如
TEXT）必须指定前缀长度，比如INDEX (title(100))
怎么判断索引是否生效：别只看“有没有建”，要看 EXPLAIN 的实际输出
执行 EXPLAIN SELECT ... 后重点看这几列：
-
type：越靠前越好，const≈eq_ref≈ref是理想状态；range可接受；index（全索引扫描）和ALL（全表扫描）要警惕 -
key：显示实际使用的索引名；若为NULL，说明没走索引 -
rows：预估扫描行数；数值越大，效率越低；若远超结果集大小，说明索引选择不当或条件未覆盖索引最左列 -
Extra：出现Using filesort或Using temporary是性能红灯，通常意味着排序/分组没利用上索引顺序
注意：EXPLAIN 不执行语句，仅模拟优化器决策；真实执行计划可能因统计信息过期而不同，必要时可运行 ANALYZE TABLE t_name 更新。
联合索引设计的关键细节：顺序、覆盖、冗余三者必须权衡
联合索引字段顺序不是随意排的，它直接决定哪些查询能命中。核心原则是：高频过滤字段优先、区分度高的字段靠前、排序/分组字段尽量后置并保持顺序一致。
CREATE INDEX idx_user_status_city ON users (status, city, created_at);
这个索引能高效支撑：
WHERE status = 1 AND city = 'Beijing'-
WHERE status = 1 ORDER BY created_at DESC（索引已排序） -
SELECT id, status, city FROM users WHERE status = 1（覆盖索引，无需回表）
但它无法支持：
-
WHERE city = 'Beijing'（跳过最左列status） -
WHERE status = 1 ORDER BY city DESC（city在created_at前，但排序方向不一致） -
SELECT * FROM users WHERE status = 1（非覆盖，需回主键聚簇索引取其余字段）
如果已有 INDEX (a) 和 INDEX (a, b)，前者大概率是冗余的——后者能完全替代前者，且额外支持 b 过滤。可通过 sys.schema_unused_indexes 视图辅助识别（需开启 performance_schema）。
线上加索引的风险与安全操作：DDL 不再是“秒级”操作
MySQL 5.6+ 支持 ALGORITHM=INPLACE，但并非所有情况都真正无锁。例如在大表上对高并发写入的字段加索引，仍可能触发表级元数据锁（MDL），阻塞后续 DML，甚至拖垮业务。
- 避免在业务高峰执行
ALTER TABLE ADD INDEX - 使用
pt-online-schema-change（Percona Toolkit）或gh-ost实现真正的在线 DDL，它们通过影子表+触发器/二进制日志重放完成，对业务影响可控 - 加索引前先用
SELECT COUNT(*)和SHOW TABLE STATUS确认表大小；千万级以上行数务必走灰度方案 - 注意字符集影响：utf8mb4 下索引长度限制更紧（767 字节），
VARCHAR(255)字段若用 utf8mb4 + 某些排序规则，可能超出限制，需显式指定前缀长度
最易被忽略的一点：很多团队只关注“查得快”，却忘了 UPDATE ... WHERE 和 DELETE ... WHERE 同样依赖索引定位记录。没有合适索引的删除/更新，在大表上可能执行几分钟甚至锁死整张表。
