MySQL中LOCATE函数参数顺序为子串在前、源字符串在后，返回从1开始的位置；Oracle/PostgreSQL用INSTR（源串在前），SQL Server用CHARINDEX；跨库无统一函数，需按数据库选型并注释说明。
MySQL里用LOCATE找字符位置，但注意参数顺序
LOCATE是MySQL最常用的子串定位函数，但它和多数语言的“indexOf”习惯相反：**被查找的子串在前，源字符串在后**。写成 LOCATE('a', 'banana') 返回 1，而 LOCATE('na', 'banana') 返回 3（第一次出现的起始位置，从1开始计数）。
容易踩的坑：
- 误写成
LOCATE('banana', 'a')—— 这会返回0，因为字符串“banana”不在字符“a”里 - 忽略大小写：默认不区分大小写，
LOCATE('A', 'apple')也会返回1；如需严格匹配，改用LOCATE(BINARY 'A', 'apple') - 搜索空字符串
''时，MySQL返回1（不是报错也不是0），这和语义直觉不符
Oracle和PostgreSQL不能用LOCATE，得换INSTR
INSTR在Oracle、PostgreSQL（从12起支持）、以及部分兼容模式的MySQL中可用，参数顺序更符合直觉：源字符串在前，子串在后，即 INSTR('banana', 'a') → 1。
但要注意差异点：
- Oracle的
INSTR支持第3、4个参数：起始位置和第几次出现，比如INSTR('banana', 'a', 1, 2)返回3（第2次出现的位置） - PostgreSQL的
INSTR只接受2个参数，不支持指定第几次；若需类似功能，得用regexp_match配合generate_series，或者先用string_to_array拆分 - MySQL虽也支持
INSTR，但它只是LOCATE的别名，参数顺序仍为子串在前——这点极易混淆
SQL Server没有INSTR或LOCATE，必须用CHARINDEX
SQL Server用CHARINDEX，语法接近INSTR：目标子串在前，源字符串在后，即 CHARINDEX('a', 'banana') → 1。它也支持第三个参数（起始位置），但**不支持直接指定“第几次出现”**。
常见错误场景：
- 忘记
CHARINDEX返回的是从1开始的位置，不是0；查不到时返回0，不是NULL，所以判断逻辑别写成IS NULL - 在
WHERE子句里用CHARINDEX('x', col) > 0是安全的，但若想取位置做计算（比如截取后续内容），要先用CASE WHEN过滤掉返回0的情况，否则SUBSTRING(col, 0, ...)会出错 - 区分大小写取决于数据库排序规则（collation），不是函数本身控制；如需强制区分，可显式加
COLLATE Latin1_General_CS_AS
跨数据库可移植写法几乎不存在，别硬套一个函数名
想写一次SQL跑多个数据库？基本行不通。LOCATE在MySQL/SQLite有效，INSTR在Oracle/PostgreSQL（部分版本）有效，CHARINDEX仅SQL Server，而PostgreSQL原生推荐用POSITION('a' IN 'banana')（标准SQL），但MySQL不认这个。
实际建议：
- 应用层处理字符串定位（比如Python用
str.find()）往往比拼SQL函数更可控、更易测 - 如果必须在SQL里做，优先按目标数据库选函数，并在注释里明确标注适用环境，例如：
-- PostgreSQL: POSITION('x' IN col), MySQL: LOCATE('x', col) - 避免嵌套多层位置计算（比如“找第二个逗号的位置”），这种逻辑一旦涉及空值或边界情况，各数据库行为差异会放大，不如拆成CTE或临时字段逐步处理
位置计算看着简单，但越靠近索引边界、空值、多字节字符（如emoji），各数据库的实现细节就越容易暴露出来。动手前先确认你的字段编码和数据库版本。
