在日常开发中，经常有人问：COALESCE 能否用于全文搜索，在关键词为空时实现“兜底”效果？直接给出答案——这行不通。这个陷阱，许多开发者都踩过，尤其是在刚接触全文索引的阶段。
COALESCE 本质上是一个值替换函数，并非查询条件构造器。它无法让 MATCH ... AGAINST 或 LIKE 在关键词为空时“跳过匹配”，最多只能将空值替换为一个默认字符串。但这个默认值很可能破坏全文索引的语义，甚至直接引发语法错误。
常见的错误写法是 WHERE MATCH(title) AGAINST(COALESCE(@keyword, ''))。MySQL 会直接报错：AGAINST() requires at least one word。因为在全文搜索机制中，空字符串根本不接受作为参数。
深入分析可知：
- 全文搜索要求
AGAINST的参数至少包含一个有效词——不能为空、不能是停用词，长度也必须达标。 - 有人尝试这样修改：
COALESCE(@keyword, 'dummy')。看似绕过了空值，但如果'dummy'不在索引中，或者恰好是停用词，那么结果恒定为0，等于没有过滤。 - 放到
LIKE场景同样不理想：COALESCE(@keyword, '%')会直接导致全表扫描，索引优势荡然无存。
正确做法：利用条件逻辑动态控制
关键词是否为空，直接影响查询结构的改变。这种场景必须依靠 SQL 控制流（例如 CASE 配合布尔表达式）或应用层判断，而不能指望一个 COALESCE 来偷换参数。
MySQL 中推荐的写法如下（关键词变量用 @keyword 表示）：
WHERE (@keyword IS NULL OR @keyword = '') OR MATCH(title, content) AGAINST(@keyword IN NATURAL LANGUAGE MODE)
这个写法有几个关键点需要留意：
@keyword IS NULL OR @keyword = ''作为独立条件，满足时整行保留——相当于“不进行筛选”。- 通过
OR将全文搜索条件连接起来，MySQL 优化器通常能正确识别并处理短路逻辑。 - 最重要的一点：不要在
AGAINST内部调用COALESCE这类函数，否则全文索引将无法使用。 - 如果必须使用布尔模式，记得加上引号：
AGAINST(CONCAT('"', @keyword, '"') IN BOOLEAN MODE)，并确保@keyword已经过滤过特殊字符。
应用层判断，往往是更可靠的选择
在数据库层面进行条件分支虽然可行，但混合逻辑容易出错。大多数生产环境的做法，是在代码中提前判断、分开处理。
- 关键词为空 → 发送不带
MATCH的基础查询（例如SELECT * FROM docs）。 - 关键词非空 → 拼接带
MATCH ... AGAINST的查询，同时进行最小清洗（去掉首尾空格、过滤+、-、>等非法布尔操作符）。 - 安全提醒：这一步不能省略——永远不要用字符串拼接构造 SQL，全部使用预处理参数绑定来防止注入。
- PHP 示例：
$sql = empty($kw) ? "SELECT * FROM docs" : "SELECT * FROM docs WHERE MATCH(title) AGAINST(? IN NATURAL LANGUAGE MODE)";
COALESCE 唯一能用在哪？以及为什么总有人惦记它
COALESCE 在全文搜索流程中的合理位置只有一个：用于处理搜索后返回字段的空值兜底，而不是控制搜索行为本身。
- 例如：查询标题后，希望空标题显示为
'（未命名）'→SELECT COALESCE(title, '(未命名)') AS title FROM docs WHERE ... - 又如：对搜索得分进行空值保护 →
SELECT COALESCE(MATCH(title) AGAINST(@kw), 0) AS score，避免NULL影响排序。 - 但它绝不能出现在
WHERE中试图“修复”空关键词——那只是把问题从应用层推给数据库，而且推错了位置。
还有一个容易被忽视的点：全文索引对停用词、最小词长、字符集都非常敏感。即使关键词不为空，也可能因为配置原因查不到结果。此时的排查方向应该是索引状态和分词规则，而不是反复修改 COALESCE 的默认值。
