在业务系统里，用户经常会在搜索框中输入“手机 红色 128g”这类由多个词组成的查询串，而后端往往只对应一张商品表。如何让这条SQL在一个字段或多字段中同时命中所有关键字，是开发时容易忽略但影响体验的问题。如果处理方式不当，接口响应时间会随数据量增长呈线性恶化。
传统LIKE拼接方案的写法与隐患
最直观的实现方式是将用户输入按空格拆分，然后对每个词生成一条 LIKE '%关键词%' 条件，再用 AND 连接。例如用户传入“苹果 手机”，对应的SQL可能是：WHERE name LIKE '%苹果%' AND name LIKE '%手机%'。这种写法逻辑清晰，不需要额外学习成本，在小表上运行没有问题。
但当数据量达到几十万行以上时，由于模糊查询的通配符在开头，MySQL无法使用B+树索引，只能进行全表扫描，并对每一行做多次字符串匹配。如果关键字有五个，就要在每行上跑五遍匹配，CPU开销成倍增加。同时，这种写法在动态拼接时容易产生SQL注入风险，需要严格使用预处理语句。
下面是一个用PHP实现的简单拼接示例，注意这里使用了占位符来避免注入：
<?php
$keywords = explode(' ', $userInput);
$conds = [];
$params = [];
foreach ($keywords as $kw) {
$conds[] = 'name LIKE ?';
$params[] = '%' . $kw . '%';
}
$sql = 'SELECT * FROM products WHERE ' . implode(' AND ', $conds);
// 使用PDO预处理执行
$stmt = $pdo->prepare($sql);
$stmt->execute($params);
?>
使用CONCAT合并字段配合单条LIKE的优化
如果查询需要跨多个字段，比如商品名、描述和品牌都要匹配，反复写多个 LIKE 会让SQL冗长。此时可以用 CONCAT 把字段拼起来，再统一做模糊匹配：WHERE CONCAT(name, desc, brand) LIKE '%苹果%' AND CONCAT(...) LIKE '%手机%'。这样逻辑上把多列虚拟成一列，便于理解。
不过 CONCAT 本身也是计算函数，同样无法走索引。但它的好处是减少了条件分支，方便在代码层统一生成。对于中文环境，还要注意字符集，如果字段是 utf8mb4，拼接不会产生乱码，但长度超过限制时会返回NULL，需要配合 COALESCE 处理空字段。
以下示例展示如何在MySQL里将三个字段合并后做双关键字过滤：
SELECT id, name FROM products WHERE CONCAT(COALESCE(name,''), COALESCE(description,''), COALESCE(brand,'')) LIKE '%苹果%' AND CONCAT(COALESCE(name,''), COALESCE(description,''), COALESCE(brand,'')) LIKE '%手机%';
这种写法虽然没有解决索引失效，但降低了SQL拼接复杂度，适合后台管理系统中数据量不大、但字段分散的查询需求。如果前端搜索是核心功能，仍需要更彻底的索引方案。
基于ngram全文索引的高效多关键字检索
MySQL从5.7开始对InnoDB支持全文索引，并且通过 ngram 分词器可以很好地处理中文。创建全文索引时指定 WITH PARSER ngram，就能把连续字符按粒度切分。之后使用 MATCH...AGAINST 语法，传入多个词，数据库会自动做与逻辑匹配。
相比LIKE，全文索引底层使用倒排索引，查询复杂度从全表扫描降为索引查找，在百万级数据下延迟通常能保持在毫秒级。同时 AGAINST('苹果 手机' IN BOOLEAN MODE) 默认就是多词AND关系，不需要手动拼条件。需要注意的是，ngram的 token_size 默认是2，过短可能匹配噪音，过长则漏召回，应根据业务调整。
建表与查询的参考代码如下：
ALTER TABLE products ADD FULLTEXT INDEX ft_name_desc (name, description) WITH PARSER ngram;
SELECT id, name
FROM products
WHERE MATCH(name, description) AGAINST('苹果 手机' IN BOOLEAN MODE);
在分库分表架构中，全文索引只能作用于单实例内的表，跨节点搜索需要借助Elasticsearch等外部引擎。但对于单表场景，ngram全文索引是兼顾开发成本与性能的最佳选择。实施前应在测试环境用真实数据验证召回率，避免因为分词粒度导致重要商品无法被搜出。
动态参数与代码层封装建议
不论采用哪种SQL方案，后端都应避免把用户输入直接字符串拼接进语句。推荐在代码层将关键字数组统一交给预处理机制。比如在Java里用 NamedParameterJdbcTemplate，或在Go里用 sqlx 的 Rebind，既安全又方便单元测试。
另外，可以对用户输入做归一化，例如转小写、去重、剔除停用词。这样不仅缩小了查询范围，也减少了无意义的条件。如果系统对搜索延时极度敏感，还可以在Redis里缓存热门关键字组合的结果集，将数据库压力进一步卸载。
一个基础的Python清洗与参数构建例子如下：
def build_params(user_input):
words = list(set(user_input.lower().split()))
words = [w for w in words if len(w) > 1]
conds = ' AND '.join(['content LIKE %s'] * len(words))
params = ['%' + w + '%' for w in words]
return conds, params
通过上述分层处理，单表多关键字查询从紧急补丁变成可维护模块。团队在选型时，应基于当前数据规模与增长预期来决定是否引入全文索引，而不是盲目追求复杂架构。