应避免在SQL Server存储过程中用动态SQL拼接含跨字段OR的@WhereStr，因其易致索引失效、全表扫描；推荐改用结构化参数+UNION ALL拆分，并确保各子查询独立走索引、参数化传值、加OPTION(RECOMPILE)。
SQL Server 存储过程中直接拼 @WhereStr 会导致 OR 性能崩盘
用动态 SQL 拼接 @WhereStr 看似省事，但一旦传入多个 OR 条件（比如 name='a' OR name='b' OR status=1 OR type='x'），SQL Server 很可能放弃所有索引，走全表扫描。这不是你代码写得不够“通用”，而是优化器面对复杂 OR 时的天然局限——它很难为每个分支选对索引，更难估算行数。
常见错误现象：sp_executesql 执行慢、CPU 持续飙高、STATISTICS IO 显示逻辑读暴增几万页；执行计划里出现 Parallelism 或 Table Scan 节点，且 Estimated Rows 和 Actual Rows 差距巨大。
- 别把
OR当成语法糖，它是查询性能的隐形断点 - 同一字段多值（如
status IN (1,2,3)）可保留，但跨字段OR必须拆 - 拼接字符串前务必
TRIM并校验非空，否则生成WHERE空条件引发语法错误
用 UNION ALL 拆分 OR 的核心规则
拆不是乱拆，关键在保证每个子查询能独立命中索引。例如 WHERE a=1 OR b=2 OR c=3，必须拆成三个独立 SELECT，且每条都只含一个等值条件。
实操要点：
- 每个子查询的
SELECT列表、数据类型、顺序必须完全一致，否则UNION ALL报错 - 优先用
UNION ALL，除非业务明确要求去重；UNION会触发排序+去重，开销翻倍 - 若某分支条件可能为空（如用户没输姓名），该子查询应整体跳过，避免返回全表
- 拆分后记得加
OPTION (RECOMPILE)，防止参数嗅探导致计划复用失效
示例片段：
SELECT * FROM orders WHERE status = 'shipped' UNION ALL SELECT * FROM orders WHERE customer_id = @cid UNION ALL SELECT * FROM orders WHERE amount > @min_amount
存储过程里怎么安全地生成 UNION ALL 动态 SQL
不能靠字符串 REPLACE 或正则硬切 OR，容易切错括号、引号或注释里的 OR。正确做法是：让调用方传结构化参数，或由函数预解析 @WhereStr。
推荐路径：
- 前端/应用层改用数组传参，如
filters = [{field:'status',value:'shipped'}, {field:'customer_id',value:101}]，后端按字段分别构建子查询 - 若必须传原始
@WhereStr，用自定义函数[F_OptimizeOr]解析（如知识库中所示），它需识别字段名、操作符、字面值，并过滤掉无效分支 - 生成的最终 SQL 字符串长度别超
NVARCHAR(MAX)实际限制（约 2GB，但实际建议控制在 10MB 内），否则sp_executesql失败 - 所有变量值必须通过参数化传入，严禁字符串拼接用户输入，否则注入风险拉满
MySQL 下 UNION ALL 替代 OR 的特殊注意事项
MySQL 的索引合并（index_merge）有时能救场，但不可依赖：统计信息不准、小表还行、大表极易失效。用 UNION ALL 更可控，但要注意引擎差异。
关键区别：
- MySQL 8.0+ 对
UNION ALL子查询支持物化（materialization），但旧版本可能重复执行；用EXPLAIN FORMAT=JSON查看union_result节点确认 - 若子查询含
LIMIT，MySQL 不允许直接UNION ALL，需包一层派生表：(SELECT * FROM t WHERE a=1 LIMIT 10) - 注意
NULL值行为：SQL Server 中WHERE col = NULL永假，必须写col IS NULL；MySQL 同理，拆分时别漏掉这个转换 - MySQL 的
UNION ALL结果默认不排序，若需全局顺序，必须在外层加ORDER BY，且所有子查询不能有自己的ORDER BY
最容易被忽略的是：拆分后每个子查询的执行计划必须单独验证。你以为都走了索引，但可能某个分支因数据倾斜实际走了全表——EXPLAIN 每个 SELECT 都要跑一遍。
