POSITION在不同数据库语法不同：PostgreSQL用POSITION('s' IN str)，MySQL用LOCATE/INSTR，SQL Server用CHARINDEX；均从1开始计数，未找到返回0而非NULL。
POSITION函数在不同数据库中的语法差异
MySQL、PostgreSQL 和 SQL Server 都支持 POSITION，但行为不一致。PostgreSQL 和标准 SQL 用 POSITION('substr' IN str)，返回从 1 开始的下标；MySQL 实际上不支持该语法，它用的是 LOCATE('substr', str) 或 INSTR(str, 'substr')，且下标从 1 开始；SQL Server 完全不支持 POSITION，得用 CHARINDEX('substr', str)，也是从 1 起算。
所以别直接照抄文档——先确认你连的是哪个数据库。执行 SELECT VERSION() 或查 @@VERSION 看清环境再写。
POSITION返回0意味着什么
POSITION 找不到子串时统一返回 0（不是 -1，也不是 NULL），这点容易误判为“找到了第0位”。比如 POSITION('z' IN 'hello') 返回 0，不是空值，不能用 IS NULL 判断是否存在。
- 正确判断方式：
POSITION('x' IN col) > 0 - 错误写法：
POSITION('x' IN col) IS NOT NULL（永远为真） - 如果需要区分“未找到”和“在开头”，注意
POSITION('h' IN 'hello') = 1，不是 0
嵌套使用POSITION提取中间字段
想从类似 'user@domain.com' 中取 'domain.com'？单靠 POSITION 不够，必须配合 SUBSTRING 或 SUBSTR。关键是算准起始位置和长度。
以 PostgreSQL 为例：
SELECT SUBSTRING(email FROM POSITION('@' IN email) + 1);这会从 @ 后一位开始截到末尾。若还要去掉后缀，就得二次定位：
SELECT SUBSTRING(
email
FROM POSITION('@' IN email) + 1
FOR POSITION('.' IN SUBSTRING(email FROM POSITION('@' IN email) + 1)) - 1
);注意：嵌套多层 POSITION 会让可读性骤降，且每次调用都触发一次扫描，性能敏感场景建议用正则（如 PostgreSQL 的 REGEXP_REPLACE）或应用层处理。
替代方案比POSITION更实用的几种情况
真正需要“快速定位”的时候，POSITION 往往不是最优解。比如：
- 判断字段是否包含某字符？用
col LIKE '%@%'更快，避免函数导致索引失效 - 要找最后一个点的位置？
POSITION只能从前向后，得用STRPOS(REVERSE(str), '.')再换算，不如直接用REGEXP_MATCH或字符串倒序函数 - 做分隔符拆分？多数数据库已有
STRING_TO_ARRAY（PG）、JSON_SPLIT（SQL Server 2016+）或窗口函数配合CHARINDEX+ 递归 CTE，比手动算下标稳定得多
下标计算本身脆弱——一个空格、一个不可见字符、编码差异（比如 UTF-8 中的 emoji 占多个字节但 POSITION 仍按字符计数），都会让结果偏移。真要依赖位置，务必先 TRIM、REPLACE 规范输入。
