MySQL大文本字段需用前缀索引（适合左匹配）或全文索引（适合关键词搜索），前者对LIKE '%abc%'无效，后者需MATCH() AGAINST()语法且中文需ngram插件支持。
MySQL 大文本字段不能直接建普通索引
因为 VARCHAR(255) 以上、TEXT、MEDIUMTEXT 这类字段不支持全字段 B+ 树索引（会报错 ERROR 1170 (42000): BLOB/TEXT column 'xxx' used in key specification without a key length）。InnoDB 要求索引列有明确长度上限，而 TEXT 类型本身无固定长度。
常见错误现象：
- 执行
ALTER TABLE t ADD INDEX idx_content(content);直接失败 - 加了长度如
content(255)，但查询WHERE content LIKE '%abc%'依然走不了索引（前缀索引对通配符开头无效）
所以得换思路：要么用前缀索引（适合左匹配），要么用全文索引（适合关键词搜索）。
前缀索引只对 LEFT LIKE 和 ORDER BY 有效
前缀索引本质是取字段前 N 个字符建 B+ 树索引，它能加速 WHERE content LIKE 'hello%' 或 ORDER BY content，但对 LIKE '%world' 或 LIKE '%test%' 完全无效。
实操建议：
- 先统计字段实际常用前缀长度分布：
SELECT LENGTH(content), COUNT(*) FROM t GROUP BY LENGTH(content) ORDER BY COUNT(*) DESC LIMIT 5; - 用
SELECT COUNT(DISTINCT LEFT(content, 100)) / COUNT(*) FROM t;看 100 字符前缀的选择性（越接近 1 越好） - 建索引时显式指定长度：
ALTER TABLE t ADD INDEX idx_content_100 (content(100)); - 别盲目设太长——
content(1000)可能让单页索引节点变少，反而降低查询效率
全文索引（FULLTEXT）才是搜大文本的正解
只有 MATCH() AGAINST() 能真正利用 TEXT 字段内容做关键词检索。它底层用倒排索引，支持自然语言模式和布尔模式，但仅限于 MyISAM 和 InnoDB（5.6+），且对中文需额外处理。
使用限制和注意点：
- 建索引必须用
FULLTEXT关键字：ALTER TABLE t ADD FULLTEXT(content); - 查询必须用
MATCH(content) AGAINST('关键词' IN NATURAL LANGUAGE MODE)，写成WHERE content LIKE '%关键词%'不会走全文索引 - InnoDB 默认最小词长为 3，
'a'、'an'这类停用词或短词搜不到；可通过修改innodb_ft_min_token_size并重建索引调整（需重启或 FLUSH TABLES） - 中文分词需配合插件（如
ngram），否则按字节切分，效果差；启用方式：SET GLOBAL innodb_ft_parser = 'ngram'; ALTER TABLE t ADD FULLTEXT(content) WITH PARSER ngram;
前缀索引 vs 全文索引：选哪个看查询模式
如果业务是「查某段文字是否以某个标题开头」，比如日志表里 message 字段存「[ERROR] connection timeout…」，用前缀索引更轻量、响应更快；如果是「在文章正文里搜‘分布式事务’相关段落」，必须上全文索引。
容易被忽略的点：
- 全文索引不支持
ORDER BY或GROUP BY加速，排序仍要回表 - 前缀索引无法用于
SELECT DISTINCT content去重（长度截断后可能重复） - 两者都不解决「模糊跨字段匹配」问题，比如想搜「用户A在2024年提到过数据库崩溃」，得靠 Elasticsearch 这类专门检索引擎
真要兼顾性能和功能，常见做法是：前缀索引保基本查询，再加一个异步任务把 TEXT 内容同步到 ES 做高级检索。
