多字段联合模糊搜索能否用索引取决于like模式、最左前缀及b+树限制；or型%kw%必全表扫描；仅like 'kw%'配合联合索引与最左前缀可生效；反向索引、全文检索、union分拆是可行替代方案。
在存储过程中做多字段联合模糊搜索，索引能不能用、怎么建、为什么失效——和是不是存储过程无关，只取决于 LIKE 模式写法、字段是否参与最左前缀、以及有没有绕过 B+ 树物理限制的替代路径。
多字段 OR 模糊查询（如 name LIKE '%kw%' OR email LIKE '%kw%'）为何一定全表扫描
SQL Server 和 MySQL 都一样：只要出现 LIKE '%kw%' 或 LIKE '%kw'，对应字段上的普通索引就完全失效。优化器无法从 B+ 树任意位置“跳”到末尾匹配项，只能扫全表或全索引叶子节点。加上 OR，更没法同时走两个字段的索引——即使两个字段各自有单列索引，执行计划也大概率显示 type=ALL 或 key=NULL。
常见错误现象：
- 存储过程里写了
WHERE name LIKE CONCAT('%', @kw, '%') OR email LIKE CONCAT('%', @kw, '%')，EXPLAIN显示rows等于总行数 - 加了
FORCE INDEX也没用，MySQL 直接忽略；SQL Server 强制指定索引后报错或退化为扫描 - 前端传空字符串或纯空格，导致条件变成
LIKE '%%'，查询直接返回全表
能走索引的唯一合法写法：前缀匹配 + 联合索引 + 最左前缀对齐
只有 LIKE 'kw%' 这种前缀模式能天然利用 B+ 树索引。但要让它在多字段场景下生效，必须满足三个硬性条件：
- 所有模糊字段都得是前缀匹配，不能混用
%kw或%kw% - 这些字段必须按顺序组成联合索引，且查询条件严格遵循最左前缀原则
- 联合索引的顺序得和查询中高选择性条件对齐——比如
status区分度远高于name，那就该建(status, name, email)，而不是(name, email)
示例（MySQL）：
CREATE INDEX idx_status_name_email ON users (status, name, email);
对应存储过程内写法必须是：
WHERE status = 'active' AND name LIKE CONCAT(@kw, '%') AND email LIKE CONCAT(@kw, '%')
注意：CONCAT(@kw, '%') 是安全的；CONCAT('%', @kw) 或 CONCAT('%', @kw, '%') 会直接让整个索引失效。
真正可行的三类绕过方案（不是“优化”，是换路）
当业务强制要求中间或后缀模糊（如搜“张三”要命中“王张三丰”或“李四张”），别在存储过程里硬拼 OR，选下面一种落地路径：
-
反向虚拟列 + 索引：MySQL ≥ 5.7 支持
name_rev VARCHAR(255) AS (REVERSE(name)) STORED，再建索引；查询时用name_rev LIKE CONCAT(REVERSE(@kw), '%')。注意：SQL Server 不支持生成列，需用计算列 + PERSISTED -
FULLTEXT + ngram（中文必备）：MySQL 开启
ft_ngram_token_size = 2，建FULLTEXT(name, email)；存储过程里必须用MATCH(name, email) AGAINST(@kw IN NATURAL LANGUAGE MODE)，@kw不能带%，也不能混用LIKE -
UNION 分拆 + 双索引覆盖：把一个
OR拆成两个可走索引的查询：SELECT ... WHERE name LIKE CONCAT(@kw, '%') UNION SELECT ... WHERE REVERSE(name) LIKE CONCAT(REVERSE(@kw), '%')。代价是去重开销，且需确保两个分支都建了对应索引（正向 + 反向）
存储过程里最容易被忽略的隐性失效点
哪怕你写了正确的 LIKE 'kw%'，这几个细节照样让索引归零：
- 字段用了函数包裹：如
UPPER(name) LIKE UPPER(@kw)→ 改成统一小写存储，直接name LIKE @kw - 参数含字面量通配符：用户搜
report_2024，_会被当通配符 → 先SET @safe_kw = REPLACE(REPLACE(@kw, '_', '\_'), '%', '\%')，再加ESCAPE '\' - 字符集/校对规则不一致：字段是
utf8mb4_0900_as_cs，但传入参数是utf8mb4_general_ci→ 隐式转换导致索引失效 - 没
TRIM()：前端传' 张 '，' 张%'就匹配不到'张三'，还拉低选择性
最麻烦的是 ngram 全文索引——它对单字检索基本无效，搜“我”“你”“数”“据”根本不出结果，这点上线前必须用真实语料压测，不能只靠“搜得到关键词”就认为 OK。
