对长字符串字段做等值查询时，应使用SHA2()哈希索引而非前缀索引：因前缀索引受长度限制且等值查询易失效，而SHA2生成固定长度高区分度哈希值并建B+树索引，更稳定高效。
直接结论：对长字符串字段（如 TEXT、超长 VARCHAR）做等值查询时，用前缀索引或全文索引效果有限，而基于 MD5() 或 SHA2() 计算固定长度哈希值并为其建普通索引，是更稳定、更可控的加速手段。
为什么不能直接给长字符串字段建索引
MySQL 对单列索引有长度限制：VARCHAR 字段超过 767 字节（InnoDB 默认页大小下）就无法全字段索引；即使启用 innodb_large_prefix，也受限于 3072 字节上限。更关键的是，即便能建前缀索引（如 INDEX idx_name (name(100))），只要查询条件不是严格匹配该前缀（比如 WHERE name = 'xxx'），索引就大概率失效——因为前缀索引只保证开头 N 字符有序，不保证整值唯一或可精确定位。
常见错误现象：EXPLAIN 显示 type: ALL 或 key: NULL，rows 高达百万级，哪怕字段上有前缀索引。
- 字符串越长，前缀区分度越低（例如大量邮箱都以
user_开头） -
LIKE 'xxx%'可走前缀索引，但= 'full_value'不一定命中（尤其字符集/排序规则不一致时） - 前缀索引无法用于
ORDER BY或GROUP BY整字段操作
用 MD5() 或 SHA2() 建哈希索引的实操步骤
核心思路：把不可索引的长字符串，映射为固定长度、高区分度的二进制或十六进制串，再对这个结果建普通 B+ 树索引。
推荐使用 SHA2(col, 256)（返回 64 字符十六进制串），比 MD5() 抗碰撞能力更强；若存储空间敏感，可用 UNHEX(SHA2(col, 256)) 转为 32 字节二进制存入 BINARY(32) 字段。
- 新增哈希列（
STORED虚拟列即可，不占额外空间）：ALTER TABLE users ADD COLUMN name_hash CHAR(64) STORED GENERATED ALWAYS AS (SHA2(name, 256));
- 在哈希列上建索引：
CREATE INDEX idx_name_hash ON users (name_hash);
- 查询时改写为哈希匹配：
SELECT * FROM users WHERE name_hash = SHA2('john@example.com', 256);
注意：必须确保查询中哈希函数参数与建表时完全一致（包括大小写、空格、字符集），否则索引无法命中。
哈希索引的局限与绕过方式
哈希索引只支持等值查询（=），不支持范围（>、BETWEEN）、前缀（LIKE 'abc%'）、模糊（LIKE '%abc%'）或排序。这是 B+ 树索引天然具备、而哈希结构不具备的能力。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
如果业务同时需要等值 + 范围查询，不要放弃原字段索引，而是组合使用：
- 保留原字段前缀索引（如
INDEX idx_name_prefix (name(191))）处理LIKE 'xxx%' - 用哈希索引加速
=查询 - 必要时加
CHECKSUM()辅助去重（但注意CHECKSUM()碰撞率远高于SHA2）
性能影响方面：每次 INSERT/UPDATE name 字段，都会触发哈希值重新计算，但开销极小（SHA2 是硬件加速指令）；索引体积从可能几 MB 压缩到稳定 KB 级，缓存友好性显著提升。
容易被忽略的三个细节
第一，字符集必须显式统一。如果表用 utf8mb4_unicode_ci，但应用传入的字符串是 utf8mb4_bin 比较语义，SHA2() 结果会不同——务必在生成哈希前用 CONVERT(col USING utf8mb4) 强制归一化。
第二，NULL 值的哈希结果是 NULL，且所有 NULL 的哈希值相同，会导致等值查询意外命中多行。建议在生成列定义中加 COALESCE：
GENERATED ALWAYS AS (SHA2(COALESCE(name, ''), 256))
第三，不要用哈希索引替代主键或唯一约束。哈希碰撞虽概率极低，但非零；如需强唯一性，仍应在原字段或组合字段上加 UNIQUE 约束。
