SQL Server存储过程中应避免循环内用+拼接字符串，因其引发O(n²)复杂度和CPU飙升；必须改用STUFF+FOR XML PATH('')配合TYPE与.value()实现高效集合拼接。
SQL Server 存储过程中过度使用 + 拼接字符串是 CPU 占用飙升的常见原因，尤其在循环或大数据集上。根本问题不是“慢”，而是每次 + 都触发隐式类型转换和内存重分配，导致 O(n²) 复杂度。
避免在循环中用 + 累加字符串
这是最典型的 CPU 杀手。比如用游标或 WHILE 逐行拼接 HTML 或 CSV，每轮都重新构造整个字符串。
- 改用
FOR XML PATH('')做集合拼接：它底层用流式处理，复杂度接近 O(n) - 不要在循环里写类似
@result = @result + 'xxx'，哪怕只拼 100 行，CPU 耗时可能翻倍 - 如果必须循环（如动态 SQL 构建），先存到临时表或表变量，最后统一
FOR XML拼接
慎用 CONCAT 替代 +，但别迷信它能解决所有问题
CONCAT 确实自动处理 NULL，避免了 ISNULL() 包裹，但它仍是逐值连接，不改变线性拼接的本质开销。
- 对固定几项拼接（如
CONCAT(@a, '-', @b, '@', @c)）安全且可读 - 对动态行集合拼接（如把 10k 行 name 拼成逗号串），
CONCAT和+性能几乎一样差，必须换FOR XML PATH('') - 注意
CONCAT参数超过 255 个会报错，而+无此限制（但也不该拼那么多）
用 STUFF + FOR XML PATH('') 清理多余分隔符
直接 FOR XML 会多出前导或尾随分隔符，硬切字符串效率低；STUFF 是唯一高效清理方式。
- 典型模式：
STUFF((SELECT ',' + name FROM t FOR XML PATH(''), TYPE).value('.', 'NVARCHAR(MAX)'), 1, 1, '') - 必须加
TYPE和.value()，否则 XML 实体（如&）会被转义，破坏原始内容 - 不要用
LEFT(..., LEN(...) - 1)或SUBSTRING去掉首逗号——它们要计算长度、截取，比STUFF多一次扫描
字符串操作前先评估是否真需要拼接
很多场景本质是应用层职责，强行在存储过程中拼接反而增加数据库负担。
- 生成 HTML 报表？考虑只返回结果集，由应用层渲染——SQL Server 不是模板引擎
- 构造 IN 列表传给另一查询？优先改用临时表 + JOIN，或用
STRING_SPLIT（SQL Server 2016+）反向解析 - 日志拼接字段？用
FORMATMESSAGE替代手工拼接，它内部做了优化
真正耗 CPU 的从来不是单条 CONCAT，而是没意识到拼接发生在“行集合”还是“单值”层面。一旦涉及百行以上动态聚合，FOR XML PATH('') 就不是“可选技巧”，而是唯一合理路径。漏掉 TYPE 和 .value() 会导致 XML 转义污染数据，这个细节在测试环境常被忽略，上线后才暴露。
