charindex返回1-based位置，未找到返回0，null输入返回null，不支持通配符，区分大小写由排序规则决定，第三参数需防越界。
CHARINDEX 返回的是从 1 开始的位置，不是 0
SQL Server 的 CHARINDEX 函数返回子字符串首次出现的起始位置，且索引从 1 开始。如果没找到，返回 0 —— 这点和多数编程语言（如 Python 的 str.find()）不同，后者找不到时返回 -1。
常见错误是拿它当 0-based 下标直接做 SUBSTRING 切片，结果偏移错一位：
SELECT SUBSTRING('abcde', CHARINDEX('c', 'abcde'), 1) -- 正确：返回 'c'
如果误以为 CHARINDEX 返回 0-based 值，就可能写成：
SELECT SUBSTRING('abcde', CHARINDEX('c', 'abcde') + 1, 1) -- 错！返回 'd'
- 查不到时返回
0，直接用于SUBSTRING会触发越界警告或空结果 - 需要安全截取时，建议先用
CASE WHEN CHARINDEX(...) > 0 THEN ... ELSE ... END -
CHARINDEX区分大小写与否，取决于数据库排序规则（collation），不是函数本身控制
第三个参数 start_location 是可选的，但影响性能和逻辑
当你传入第三个参数（起始搜索位置），CHARINDEX 会跳过前面字符，从该位置开始向后找。这在实现“找第 N 次出现”时很关键，但容易漏掉边界检查。
例如找第二个 'o' 在 'hello world' 中的位置：
SELECT CHARINDEX('o', 'hello world', CHARINDEX('o', 'hello world') + 1)
这个写法看似合理，但如果第一个 'o' 是最后一个字符，+1 就超出长度，函数仍返回 0 —— 不报错，但结果不可靠。
- start_location 必须 ≥ 1，否则返回 0；若大于源字符串长度，也返回 0
- 多次嵌套
CHARINDEX容易写成无限递归式（比如没判断上层是否为 0 就直接 +1） - 想查第 N 次出现，更稳的方式是用 CTE 或
STRING_SPLIT（SQL Server 2016+）配合ROW_NUMBER()
CHARINDEX 不支持通配符，别和 PATINDEX 混用
CHARINDEX 只做精确子串匹配，哪怕你传入 '%a%' 也会当作字面量去搜 —— 它不识别通配符。有人试过：
SELECT CHARINDEX('%a%', 'banana') -- 返回 0，不是 1
真正支持模式匹配的是 PATINDEX，语法类似但语义不同：
SELECT PATINDEX('%a%', 'banana') -- 返回 1，因为开头就匹配 'a'
-
PATINDEX的 pattern 必须用 % 或 _ 包裹，否则等价于CHARINDEX -
PATINDEX性能通常比CHARINDEX差，尤其 pattern 复杂或数据量大时 - 如果只是固定子串查找，坚持用
CHARINDEX，更清晰、更快
NULL 输入会让整个表达式变 NULL，不是报错
只要任意一个参数是 NULL（包括被搜索字符串、子串、起始位置），CHARINDEX 直接返回 NULL，不会抛异常。这点在 JOIN 或 WHERE 条件中极易引发静默逻辑错误。
比如：
WHERE CHARINDEX(@search_term, t.name) > 0
如果 @search_term 是 NULL，整条条件变成 NULL > 0 → 结果为 UNKNOWN，该行被过滤掉 —— 表面看“没查到”，实际是参数为空导致的。
- 建议在调用前用
ISNULL(@search_term, '')或NULLIF(@search_term, '')显式处理 - 在 WHERE 中判断位置时，最好补一句
AND @search_term IS NOT NULL - 日志或调试时，可以加
SELECT ISNULL(CHARINDEX(...), -1)把 NULL 转成明确值便于排查
字符串位置计算这事，看着简单，但 CHARINDEX 的 1-based、NULL 传播、无通配符这几个特性，只要有一处没对齐预期，结果就偏得离谱。尤其在动态拼接条件或嵌套调用时，多打一行 SELECT 看中间值，比猜半天强。
