CHARINDEX返回子串在主串中首次出现的1-based位置，未找到返回0；参数为NULL时返回NULL，空字符串作为子串恒返1，start_location越界或非法（≤0）则报错或返0。
CHARINDEX 函数的基本用法和返回值含义
CHARINDEX 是 SQL Server（及 Azure SQL）中用于查找子字符串在主字符串中首次出现位置的函数，返回从 1 开始的整数索引；如果未找到，返回 0。它不区分大小写（取决于数据库排序规则），且不支持通配符匹配。
基本语法：CHARINDEX('substring', string_expression [, start_location])
-
substring必须是字符串常量、变量或列，长度不能超过 8000 字节（varchar(max)和nvarchar(max)也支持） -
string_expression是被搜索的源字符串，类型需与substring兼容（如都为nvarchar） -
start_location是可选参数，指定从第几个字符开始搜索（默认为 1）；若为负数或 0，SQL Server 会报错：Argument data type int is invalid for argument 3 of charindex function.
为什么 CHARINDEX 找不到字符却返回 0？常见误判场景
返回 0 并不总意味着“没这个字符”，而代表“未匹配到完整子串”。比如在 CHARINDEX('a', 'Aa') 中，若数据库排序规则为大小写敏感（如 SQL_Latin1_General_CP1_CS_AS），则可能返回 0 —— 因为 'a' ≠ 'A'。
- 检查当前数据库排序规则：
SELECT DATABASEPROPERTYEX(DB_NAME(), 'Collation') - 避免隐式转换导致失败：当
substring是varchar而string_expression是nvarchar时，SQL Server 可能将前者转为 Unicode 后再比较，但若含非 ASCII 字符（如中文），建议统一用N'中文'前缀 - 空字符串
''作为substring时，CHARINDEX('', 'abc')恒返回 1（SQL Server 行为，不是 bug）
用 CHARINDEX 提取分隔符前后的字段（如邮箱用户名）
配合 SUBSTRING 和 LEN，CHARINDEX 常用于解析结构化文本。例如从 email 字段中提取 @ 符号前的部分：
SELECT
SUBSTRING(email, 1, CHARINDEX('@', email) - 1) AS username
FROM users
WHERE CHARINDEX('@', email) > 0;关键点：
- 必须加
WHERE CHARINDEX('@', email) > 0过滤，否则CHARINDEX返回 0 会导致SUBSTRING(email, 1, -1)报错：Invalid length parameter passed to the LEFT or SUBSTRING function. - 若字段可能为 NULL，
CHARINDEX返回 NULL，整个表达式结果也为 NULL；无需额外 ISNULL 包裹，但 WHERE 条件里要写CHARINDEX('@', ISNULL(email, '')) > 0防止 NULL 短路 - 对多层级分隔（如路径
C:\folder\file.txt），可用嵌套CHARINDEX定位最后一个反斜杠：CHARINDEX('\', REVERSE(path))配合LEN计算位置
CHARINDEX 在性能和替代方案上的注意事项
CHARINDEX 是标量函数，在 WHERE 子句中使用可能导致全表扫描，无法利用索引（除非搭配计算列 + 索引）。它也不支持正则，复杂模式应交由应用层或 SQL Server 2022+ 的 STRING_SPLIT + TRY_CAST 组合处理。
- 避免在大表 JOIN 条件中用
CHARINDEX(col1, col2) > 0，改用col2 LIKE '%' + col1 + '%'（仍慢）或前置计算列 - SQL Server 不支持
INSTR（MySQL/Oracle 风格），别名写法无效；PostgreSQL 用户请用POSITION('x' IN col)或STRPOS(col, 'x') - 若只需判断存在性（不要位置），
CHARINDEX('x', col) > 0比col LIKE '%x%'略快，但两者都难优化
真正麻烦的是嵌套调用 + 多条件组合时的可读性——一个 CHARINDEX 很轻量，五个嵌套就容易漏括号或算错偏移。动手前先用简单字符串手算一遍预期位置，比直接跑查询更省时间。
