CHARINDEX返回从1开始的位置，找不到返回0；参数为NULL时结果为NULL，非SARGable且不支持第N次匹配。
CHARINDEX 返回的是从 1 开始的位置，不是 0
SQL Server 的 CHARINDEX 函数不遵循编程语言常见的 0 起始索引习惯。如果子字符串存在，它返回第一个匹配字符的**从 1 计数的位置**；找不到则返回 0。这点容易在条件判断中出错——比如写成 WHERE CHARINDEX('abc', col) > 0 是对的，但误写成 >= 1 虽然结果一样，却掩盖了语义：返回值只有 0 或正整数，不存在负数或 NULL（除非任一参数为 NULL）。
常见错误现象：
– 用 IS NULL 判断是否找到（实际返回 0，不是 NULL）
– 在 SUBSTRING 中直接用 CHARINDEX(...) + 1 却没检查是否为 0，导致位置为 1 时截取到开头，位置为 0 时变成 SUBSTRING(..., 1, ...)，逻辑错乱
- 始终用
CHARINDEX(...) > 0做存在性判断 - 若用于
SUBSTRING起始位置，先用CASE WHEN CHARINDEX(...) > 0 THEN ... ELSE ... END处理未找到情况 -
CHARINDEX对大小写是否敏感取决于所在数据库的排序规则（collation），不是函数本身控制
第三个参数 start_location 控制查找起点，但不支持“第 N 次出现”
CHARINDEX 的第三个参数是起始搜索位置（从 1 开始计数），不是“找第几次”。例如 CHARINDEX('o', 'hello world', 5) 会从第 5 个字符（即第一个 o 后的空格）开始往后找，返回第二个 o 的位置（8）。但它**无法直接定位“第二次出现”**——因为如果第一次出现在位置 2，你传入 3，它确实跳过了第一次，但前提是你知道第一次在哪。
- 想查第 N 次出现，需嵌套调用或配合
STUFF/REPLACE配合计数逻辑（较重） - 第三个参数若超出字符串长度，返回
0；若为NULL或小于 1，SQL Server 会报错Argument data type varchar is invalid for argument 3 of charindex function. - 传入负数或非整数（如
1.5）会触发隐式转换，但行为不可靠，应显式转为INT
NULL 参数会导致整个结果为 NULL，不是 0
只要 CHARINDEX 的任意一个参数（待查字符串、源字符串、起始位置）是 NULL，函数立刻返回 NULL，而不是 0。这和「找不到返回 0」的直觉冲突，尤其在列可能为空的场景下极易漏判。
使用场景举例：用户表里 email 列允许 NULL，你想筛选含 @ 的记录：
❌ 错误写法：WHERE CHARINDEX('@', email) > 0 —— 若 email 为 NULL，整条表达式结果为 NULL，该行被过滤掉（看似合理，但逻辑不透明）
✅ 更安全写法：WHERE email IS NOT NULL AND CHARINDEX('@', email) > 0
- 在计算列、CTE 或子查询中使用前，先用
ISNULL或COALESCE处理潜在NULL输入 -
CHARINDEX(NULL, 'abc')和CHARINDEX('a', NULL)都返回NULL，没有例外 - 注意：空字符串
''是合法输入，CHARINDEX('', 'abc')返回1（因为空字符串被认为在每个位置都“存在”）
性能上，CHARINDEX 无法利用常规索引加速模糊查找
CHARINDEX 是运行时逐字符扫描函数，即使你在 WHERE 子句中用它做过滤（如 CHARINDEX('admin', name) > 0），SQL Server 也无法使用 name 列上的普通 B-tree 索引跳过扫描——本质等价于 LIKE '%admin%'，属于非SARGable 表达式。
- 若高频执行此类查找，考虑添加计算列 + 索引（如
ALTER TABLE t ADD has_admin AS CASE WHEN CHARINDEX('admin', name) > 0 THEN 1 ELSE 0 END PERSISTED，再对该列建索引） - 全文索引（Full-Text Index）更适合复杂文本匹配，但配置成本高，且不适用于简单子串定位需求
- 在 WHERE 中混用
CHARINDEX和其它 SARGable 条件时，优化器可能仍选择全表扫描，需看实际执行计划确认
实际用起来最常踩的坑，是把 CHARINDEX 当成“安全的字符串查找工具”而忽略它的 NULL 传播性和非SARGable 特性——尤其在数据质量不可控、查询性能敏感的生产环境里，这两点往往比语法细节更致命。
