CHARINDEX返回匹配字符的起始位置（从1开始），找不到则返回0，需配合SUBSTRING等函数截取内容；常见错误是误将其结果直接当子串用，正确做法是用其值作SUBSTRING的起始参数，并注意+1跳过分隔符、加CASE WHEN防0值报错。
CHARINDEX 返回的是位置，不是子串
很多人误以为 CHARINDEX 能直接截出内容，其实它只返回匹配字符串在源字符串中的起始位置（从 1 开始计数），找不到则返回 0。真正截取得靠 SUBSTRING 或 LEFT/RIGHT 配合使用。
常见错误现象：SELECT CHARINDEX('abc', 'xabcxyz') 返回 2，但如果你直接拿这个结果当子串用，就完全跑偏了。
- 必须用
CHARINDEX的结果作为SUBSTRING的第二个参数（起始位置） - 若要截取“第一次出现某字符之后的内容”，需在位置基础上 +1（跳过该字符本身）
- 注意空格和大小写：SQL Server 默认区分大小写，
'A'和'a'在二进制排序规则下不匹配
截取“某个分隔符之后的第一个字段”最常用写法
比如日志字段 log_data 值为 'ERROR|UserNotFound|/api/login'，想取竖线后第一个部分（'UserNotFound'）。
关键在于嵌套：先用 CHARINDEX 找第一个 |，再找第二个 |，然后用 SUBSTRING 截中间。
SELECT
SUBSTRING(
log_data,
CHARINDEX('|', log_data) + 1,
CHARINDEX('|', log_data, CHARINDEX('|', log_data) + 1) - CHARINDEX('|', log_data) - 1
) AS error_code
FROM logs;- 外层
CHARINDEX('|', log_data, ...)的第三个参数是“从哪开始搜”，这里填第一个|的位置 +1，避免重复匹配自身 - 长度计算容易错：结束位置减起始位置，还要再减 1（因为
SUBSTRING第三个参数是“取多少位”，不是“到哪为止”） - 如果某些行只有一个
|，第二个CHARINDEX返回 0，整个SUBSTRING会报错——必须加CASE WHEN或NULLIF防御
CHARINDEX 模糊定位的边界陷阱
CHARINDEX 不支持通配符（如 % 或 _），所谓“模糊”只是指你用它配合其他逻辑实现近似效果，不是正则匹配。
常见误用场景：想查“以 abc 开头的字段”，却写成 CHARINDEX('abc%', col) = 1 —— 这会字面匹配 'abc%' 这个字符串，不是通配。
- 真正等价于
col LIKE 'abc%'的写法是：CHARINDEX('abc', col) = 1 - 想查“包含 abc 且后面紧跟数字”，不能单靠
CHARINDEX，得结合SUBSTRING+ISNUMERIC（或更稳的TRY_CAST）判断下一位 - 性能影响：在 WHERE 中对字段用
CHARINDEX(col, 'xxx')（即反向参数顺序）无法走索引；应尽量写成CHARINDEX('xxx', col) > 0，并确认列上有合适索引
替代方案：什么时候别硬扛 CHARINDEX
当需求变复杂——比如多级分隔、不定长字段、需要提取全部匹配项——CHARINDEX 嵌套很快变得不可维护。
SQL Server 2016+ 推荐改用 STRING_SPLIT（注意它返回表，需 CROSS APPLY），而 SQL Server 2022+ 可直接用 STRING_SPLIT 的 enable_ordinal 参数获取顺序。
- 简单拆分固定分隔符（如逗号）：
SELECT value FROM STRING_SPLIT('a,b,c', ',') - 想取第 2 个元素？用
WITH ORDINALITY后加WHERE ordinal = 2 - 旧版本只能靠递归 CTE 或自定义函数，但维护成本远高于调试一长串
CHARINDEX嵌套
真正难处理的是“非对称结构”，比如 HTML 片段里截 <div class="...> 到下一个 </div>——这种必须上 CLR 或导出到外部工具，SQL 不适合干这事。
