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 才可能生效。

MySQL8 CRM Schema Design Expert

面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。

下载

• 先确认内容确实是文本：用 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 一样快，本质上是在对抗存储引擎的设计边界。