MySQL视图不支持全文索引，因视图是虚拟表且解析时被判定为不支持FULLTEXT的表类型；MATCH() AGAINST()在视图中失效，主因无法下推、字段别名失配及丢失分词上下文；应直查底层表或换用Elasticsearch等专业搜索引擎。
MySQL视图本身不能建全文索引
视图是虚拟表，不存储数据，也不支持直接创建 FULLTEXT 索引。执行 CREATE FULLTEXT INDEX ON view_name(...) 会报错：ERROR 1166: Incorrect column name 或更常见的是 ERROR 1214: The used table type doesn't support FULLTEXT indexes——因为 MySQL 在解析时把视图当成“不支持 FULLTEXT 的表类型”处理，连语法校验都过不去。
为什么 MATCH() AGAINST() 在视图里返回空结果
即使底层表有全文索引，视图查询中写 MATCH(col) AGAINST('xxx') 也大概率返回空，原因有三：
- 视图定义若含
JOIN、GROUP BY、子查询或计算字段，MySQL 无法将MATCH()下推到底层表，只能退化为全表扫描 + 字符串匹配（等价于LIKE），而全文索引根本没被触发 -
MATCH()要求字段必须严格对应索引定义的列名、顺序、类型；视图字段是别名或表达式结果，无法对齐 - InnoDB 视图不支持全文解析器（如
ngram），哪怕底层用了WITH PARSER ngram，视图层也丢失分词上下文
替代方案：绕过视图，直查或换引擎
真要全文检索，只有两条路可走：
-
查底层表：把原视图 SQL 拆开，定位到实际带
FULLTEXT索引的那张基础表（比如articles），直接在它上面跑MATCH(title, content) AGAINST('搜索词' IN NATURAL LANGUAGE MODE) -
换搜索引擎：MySQL 全文索引对中文支持弱（依赖
ngram_token_size、停用词、词长限制），且无法做高亮、相关性调权；业务量稍大就该切 Elasticsearch 或 Meilisearch，用它们同步 MySQL 数据，再由应用层路由查询
硬要在视图上“模拟”全文效果？只能用 WHERE col LIKE '%关键词%'，但性能随数据量指数恶化，且不支持布尔逻辑、权重、词干提取——这不是妥协，是自缚手脚。
