索引是什么：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同样依赖索引定位记录。没有合适索引的删除/更新，在大表上可能执行几分钟甚至锁死整张表。
