text字段加前缀索引仅在where content like '固定前缀%'等极窄场景有效，对like '%keyword'、等值查询及模糊匹配均无效，且易因区分度低、i/o开销大而性能更差。
TEXT 字段加前缀索引不是“不能做”，而是做了也大概率白做——它只在极窄的场景下生效，却掩盖了更本质的设计问题。
TEXT 前缀索引对 LIKE '%keyword' 完全无效
MySQL 的前缀索引本质是取字段开头 N 个字符建 B+ 树索引，仅支持最左匹配。
-
WHERE content LIKE 'hello%'→ 可走索引 -
WHERE content LIKE '%world'或WHERE content LIKE '%test%'→ 强制全表扫描 -
WHERE content = 'exact value'→ 即使值完全匹配，因索引只覆盖前缀，也无法保证等值查找准确命中
你看到执行计划里 type: ALL，不是 SQL 写错了，是前缀索引天生不支撑这种查询模式。
前缀长度选不准，区分度和空间两头吃亏
content(255) 看起来很常见，但实际可能：
- 中文内容前 255 字符内大量重复（比如日志开头都是
[INFO] 2026-06-11）→ 区分度低，索引几乎失效 - 字段真实长度中位数只有 80 字符 → 多建 175 字符纯属浪费，还拖慢
INSERT和UPDATE - utf8mb4 下一个汉字占 4 字节，255 字符可能逼近 1020 字节，接近单列索引 3072 字节上限，后续加其他索引容易触顶
实操建议：
- 先跑
SELECT COUNT(DISTINCT LEFT(content, 100)) / COUNT(*) FROM t;看区分度 - 如果结果 0.95 再试 150，观察提升是否显著
- 避免直接拍脑袋设 255 或 1000，尤其当字段含大量模板化前缀时
TEXT 本身存储机制让前缀索引“查得到但读得慢”
TEXT 值不存于主行记录，而放在溢出页（off-page），主记录只存 20 字节指针。
- 查询走前缀索引定位到某几行后，MySQL 还得回表去溢出页把完整
TEXT值捞出来 - 这个过程触发额外磁盘 I/O，尤其当结果集稍大（比如返回 100 行），性能断崖式下降
- 同样逻辑下，
VARCHAR(1000)存在行内，回表就是内存访问，快一个数量级
真正需要快速检索的文本，不该是 TEXT，而应是结构化或可预处理的字段：标题、标签、摘要、关键词冗余列——这些才能建高效索引。
前缀索引不是技术捷径，是设计妥协的临时补丁。它存在的唯一合理场景，是你明确知道所有查询都形如 WHERE content LIKE '固定前缀%'，且该前缀在业务中天然具备高区分度。其余情况，不如早点把字段类型换成 VARCHAR，或者把全文检索交给 FULLTEXT 或外部系统。
