MySQL中INSTR()函数语法为INSTR(str, substr)，先主串后子串，返回首次出现位置（从1开始），未找到返回0；参数顺序易与SQL Server的CHARINDEX混淆，颠倒即错。
MySQL 用 INSTR()，SQL Server 用 CHARINDEX()，两者行为相似但参数顺序相反，混用会直接返回错误结果或 0。
INSTR() 在 MySQL 中怎么用？参数顺序别搞反
INSTR() 是 MySQL 的字符串位置函数，语法是 INSTR(haystack, needle) —— 先写被搜索的字符串，再写要找的子串。这点和多数语言的 indexOf() 一致，但和 SQL Server 完全相反。
- 返回值从 1 开始计数，没找到返回 0（不是 -1）
-
INSTR('hello world', 'o')返回5（第一个o在第 5 位） - 区分大小写，
INSTR('Hello', 'h')返回0 - 不支持正则，只做字面匹配；想模糊定位得配合
LOCATE()或SUBSTRING_INDEX()
CHARINDEX() 在 SQL Server 中为什么总返回 0？
CHARINDEX() 参数顺序是 CHARINDEX(needle, haystack[, start_location]) —— 子串在前，主串在后。很多人从 MySQL 切过来，把参数写反，比如 CHARINDEX('abc', column_name) 看似合理，实际是把整列当子串去搜，几乎必然返回 0。
- 返回值也是从 1 开始，没找到返回 0
- 默认不区分大小写（取决于数据库排序规则），
COLLATE Latin1_General_CS_AS可强制区分 - 第三个可选参数指定起始位置，比如
CHARINDEX('a', 'banana', 3)返回4（从第 3 位开始找，第二个a） - 不能直接用于
WHERE条件判断“是否包含”，因为 0 和非 0 都是合法值，得写成CHARINDEX('x', col) > 0
跨数据库写法怎么避免出错？
没有标准 SQL 的字符串位置函数，POSITION()（PostgreSQL/Standard SQL）用的是 POSITION('x' IN str)，参数顺序又不同。如果必须兼容多库，别硬套一个函数，优先考虑业务逻辑层处理，或用 CASE WHEN + 各自函数封装。
- MySQL：用
INSTR(str, substr) > 0 - SQL Server：用
CHARINDEX(substr, str) > 0 - PostgreSQL：用
POSITION(substr IN str) > 0 - 千万别在 SQL Server 里写
INSTR()—— 会报错Invalid object name 'INSTR'
最常踩的坑不是记不住函数名，而是参数顺序——尤其在迁移脚本或写通用工具时，一眼扫过去觉得“都是找位置”，一粘贴就失效。查文档前先确认当前数据库类型，比背函数更可靠。
