CHARINDEX在SQL Server中返回子串位置，参数顺序为子串在前、主串在后，未找到返回0而非NULL；INSTR用于MySQL，参数顺序相反；POSITION是跨数据库标准函数，语法为POSITION(substring IN string)。
SQL Server里用CHARINDEX找子串位置，注意参数顺序和NULL行为
CHARINDEX是SQL Server专属函数，语法为CHARINDEX(substring, string, [start_location])。最容易错的是前两个参数顺序——子串在前，主串在后，和多数编程语言相反。比如CHARINDEX('abc', 'xabcx')返回2；如果子串不存在，它返回0，不是NULL。
常见踩坑点：
- 误写成
CHARINDEX('xabcx', 'abc')，结果永远是0（因为'xabcx'不在'abc'里） - 忽略大小写敏感性：默认按数据库排序规则判断，若需忽略大小写，确保排序规则含
_CI（如SQL_Latin1_General_CP1_CI_AS），或显式转换：CHARINDEX(UPPER('abc'), UPPER(col)) -
start_location从1开始计数，不是0；传入0或负数会被当作1处理
MySQL用INSTR，但别和LOCATE混淆
MySQL没有CHARINDEX，对应的是INSTR，语法为INSTR(string, substring)——这里参数顺序和编程语言一致：主串在前，子串在后。INSTR('xabcx', 'abc')返回2，没找到时返回0。
注意：LOCATE功能类似但支持第三个参数（起始位置），且参数顺序是LOCATE(substring, string, [pos])，和INSTR相反。混用会导致逻辑错误。
实操建议：
- 简单查找优先用
INSTR，语义清晰、参数顺序自然 - 需要从指定位置开始搜索时改用
LOCATE，例如LOCATE('a', 'banana', 3)返回4（跳过前两个字符） -
INSTR区分大小写取决于字段的排序规则；若需强制不区分，可用LOWER()包裹两边
跨数据库写法？别硬套，用POSITION更通用
PostgreSQL、Standard SQL（如BigQuery、Snowflake）用POSITION函数，语法统一为POSITION(substring IN string)，返回从1开始的位置，找不到返回0。它不接受起始偏移量，但兼容性最好。
如果你写的是需要多库运行的SQL（比如ORM底层或数据迁移脚本），直接避免CHARINDEX和INSTR，改用POSITION加字符串函数组合。例如模拟“从第n位开始查找”：
POSITION('abc' IN SUBSTRING(col FROM 5)) + 4
这比硬写条件分支判断数据库类型更轻量。不过要注意：SUBSTRING在各库中起始位置约定不同（PostgreSQL/Standard SQL从1开始，MySQL从1，SQL Server的SUBSTRING也是从1），所以仍需确认目标环境。
查不到就返回0，不是NULL——这个细节影响WHERE和CASE逻辑
所有这三个函数（CHARINDEX、INSTR、POSITION）在未匹配时都返回0，不是NULL。这意味着WHERE CHARINDEX('x', col) > 0是对的，但WHERE CHARINDEX('x', col) IS NOT NULL会漏掉所有不包含'x'的行——因为0不是NULL，该条件恒真或恒假取决于是否有0值参与比较。
典型误用场景：
- 在
CASE中写WHEN CHARINDEX(...) IS NULL THEN ...，永远不会进入该分支 - 用
ISNULL(CHARINDEX(...), 0)多余，因为本来就不返回NULL - 想表达“存在且位置大于5”，必须写
CHARINDEX(...) > 5，不能写CHARINDEX(...) >= 5（因为位置从1开始）
真正容易被忽略的是：这些函数对空字符串''的行为不一致——SQL Server中CHARINDEX('', 'abc')返回1，MySQL中INSTR('abc', '')返回0，PostgreSQL中POSITION('' IN 'abc')返回0。如果业务逻辑涉及空字符串判定，必须单独处理。
