mysql如何选择合适的索引类型_mysql索引设计实战

该用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))。 通义听悟 阿里云通义听悟是聚焦音视频内容的工作学习AI助手，依托大模型，帮助用户记录、整理和分析音视频内容，体验用大模型做音视频笔记、整理会议记录。