该用b-tree索引而非hash索引时：需支持范围查询（>、between）、排序（order by）、前缀匹配（like 'abc%'）或混合条件（如where a=1 and b>10），因hash仅适用于等值查询（=、in），且innodb实际只支持b-tree。
什么时候该用 B-Tree 索引而不是 Hash 索引
MySQL 的 InnoDB 引擎只支持 B-Tree 索引（即使你写 INDEX USING HASH，它也会忽略并建为 B-Tree），而 MEMORY 表才真正支持 Hash 索引。所以绝大多数业务场景下，你面对的其实是 B-Tree 的选型问题，不是“选哪种”，而是“怎么建好 B-Tree”。
Hash 索引只适合等值查询（=、IN），不支持范围查询（>、BETWEEN）、排序（ORDER BY）或前缀匹配（LIKE 'abc%'）。一旦你有 WHERE status = 1 AND created_at > '2024-01-01' 这类混合条件，Hash 就完全失效。
常见误判点：
- 以为
UNIQUE约束自动带来性能优势——其实它只是加了唯一性校验，底层仍是 B-Tree，查询效率和普通索引无异 - 在
TEXT或长VARCHAR字段上直接建全文索引（FULLTEXT）却不评估是否真需要——它仅对自然语言搜索有效，对精确匹配或结构化过滤反而更慢
联合索引字段顺序为什么不能随便调换
联合索引 (a, b, c) 实际生成的是按字典序排列的有序结构：先排 a，a 相同时再排 b，b 也相同时再排 c。这意味着它天然支持：WHERE a = ?、WHERE a = ? AND b = ?、WHERE a = ? AND b = ? AND c = ?，但不支持 WHERE b = ? 或 WHERE b = ? AND c = ? —— 因为 b 和 c 在索引中没有独立的有序性。
判断顺序的核心原则是「区分度高 + 过滤性强 + 出现频率高」，但别迷信区分度数字。例如用户表中 gender 区分度只有 2，但如果 95% 查询都带 WHERE gender = 'female' 且配合时间范围，把它放最左反而能快速定位到子集，再靠后续字段缩小范围。
实操建议：
- 把常用于
=查询的列放前面（如user_id、tenant_id） - 范围查询字段（
>、BETWEEN）必须放在等值字段之后，且只能有一个——因为一旦出现范围，后续字段就无法用于索引查找（但可用于ORDER BY或GROUP BY） - 避免把
SELECT中的非查询字段塞进联合索引末尾“覆盖查询”——除非你确认该查询高频且能显著减少回表，否则徒增索引体积和维护成本
什么时候该考虑前缀索引而不是全字段索引
对长字符串字段（比如 VARCHAR(255) 的邮箱、URL），直接建完整索引会导致索引体积暴增、内存占用升高、写入变慢。这时可以用前缀索引：INDEX idx_email (email(12))。
但前缀长度不是拍脑袋定的。得先查重复率：
SELECT COUNT(DISTINCT LEFT(email, 12)) / COUNT(*) FROM users;如果结果接近 1（比如 > 0.99），说明前 12 位基本能唯一区分；再对比
LEFT(email, 10) 和 LEFT(email, 15)，找那个“体积明显下降 + 重复率没明显恶化”的拐点。
注意两个硬限制：
- 前缀索引不支持
ORDER BY和GROUP BY—— MySQL 无法保证前缀部分的全局有序性 -
LIKE 'xxx%'可以用上前缀索引，但LIKE '%xxx'或LIKE '%xxx%'完全用不上 - 如果字段经常参与
JOIN或WHERE ... IN (subquery)，前缀索引可能导致执行计划退化，务必用EXPLAIN验证
主键设计不当会悄悄拖垮所有二级索引
InnoDB 的二级索引叶子节点存的不是行指针，而是主键值。这意味着：主键越宽，所有二级索引就越大。一个 BIGINT 主键比 INT 多占 4 字节，如果表有 1000 万行、5 个二级索引，光这部分就多占约 200MB 存储，还影响缓存命中率和范围扫描速度。
更隐蔽的问题是主键选择影响插入性能。用 UUID 或 NEWID() 类随机值当主键，会导致新记录频繁插入到索引中间位置，引发大量页分裂和碎片；而自增 INT 或 BIGINT 是顺序追加，写入友好得多。
除非你明确需要分布式 ID 或业务强依赖 UUID 做关联，否则别用字符串或 UUID 当主键。如果必须用，至少加上 STORED 列 + 自增代理主键，把 UUID 放成普通唯一索引。
最后提醒一句：索引不是越多越好。每多一个索引，INSERT/UPDATE/DELETE 就得多维护一份结构。线上表加索引前，先看 information_schema.INNODB_METRICS 里的 dml_inserts、dml_updates 比例——写多读少的表，索引收益往往远低于维护开销。
