BLOB字段根本不能建FULLTEXT索引，因无字符集和排序规则，不支持分词等文本语义操作；必须先转为TEXT并指定utf8mb4字符集，否则报错ERROR 1214。
MySQL 的 BLOB 字段根本不能直接建 FULLTEXT 索引——这是语法硬限制，不是配置或版本问题。
为什么 FULLTEXT 索引在 BLOB 上会报错
MySQL 明确要求 FULLTEXT 索引只能建在 CHAR、VARCHAR 或 TEXT 类型字段上。对 BLOB 执行 ALTER TABLE t ADD FULLTEXT INDEX ft_idx (content) 会直接报错：ERROR 1214 (HY000): The used table type doesn't support FULLTEXT indexes（即使引擎是 InnoDB）。
原因很底层：BLOB 没有字符集和排序规则（collation），而全文索引依赖字符切分、停用词过滤、词干处理等文本语义操作，这些在二进制数据上无意义。
- 常见错误现象：建索引语句执行失败；ORM 自动迁移脚本卡住并抛出 SQL 异常
- 别试图绕过：改表名、换存储引擎、调
sql_mode都无效 - 哪怕你用
CONVERT(content USING utf8mb4)包裹字段，索引定义里仍不接受表达式
想用全文检索，必须先把 BLOB 换成 TEXT
这不是“建议”，而是强制前提。只有完成类型转换，FULLTEXT 才可能生效。
- 先确认内容确实是文本：用
SELECT HEX(SUBSTRING(content, 1, 10)) FROM t LIMIT 1看前几个字节是否符合 UTF-8 编码规律（如48656C6C6F是 "Hello"） - 安全转换命令：
ALTER TABLE t MODIFY content MEDIUMTEXT CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci; - 如果字段含非法字节（比如混了图片头），必须先在应用层清洗，MySQL 不会自动跳过坏字节
- 转换后验证：
SHOW CREATE TABLE t确认字段类型已变，且字符集非binary
FULLTEXT 在 TEXT 字段上仍可能失效的三个坑
就算类型对了，FULLTEXT 也不是开箱即用。以下情况会让它静默退化为全表扫描：
-
WHERE MATCH(content) AGAINST('关键词' IN NATURAL LANGUAGE MODE)返回空，但EXPLAIN显示type=ALL：说明该词在全文索引中被判定为“停用词”或低于ft_min_word_len（默认 4 字符），查SHOW VARIABLES LIKE 'ft_%'确认 - 用布尔模式但写错语法：
AGAINST('+php -mysql' IN BOOLEAN MODE)中的+和-必须紧贴词，空格或引号会导致整个条件被忽略 - 字段值全是重复短词（如每行都是 "log log log..."），MySQL 全文索引会因“词频过高”自动剔除，导致
MATCH()永远返回 0
比 FULLTEXT 更靠谱的替代方案
当你的场景是“查日志、查文档、查用户评论”，且数据量超过 10 万行，FULLTEXT 的维护成本和功能局限（不支持模糊匹配、近义词、拼音）很快会暴露。这时候该果断切出去：
- 同步到 Elasticsearch：用 Logstash 或应用层双写，
text字段映射为text类型并启用ngram分词器，支持LIKE '%xxx%'级别的搜索 - 用
MD5(content)建哈希索引做精确匹配：加虚拟列content_hash CHAR(32) AS (MD5(content)) STORED，再建普通索引，适合查“这段内容是否出现过” - 抽关键字段：把标题、作者、时间戳、标签等元信息拆成独立
VARCHAR字段，加复合索引，90% 的后台查询其实不需要扫全文
真正难的不是建索引，而是承认：MySQL 不是搜索引擎。把 BLOB 当文本用，又指望它像 Elasticsearch 一样快，本质上是在对抗存储引擎的设计边界。
