mysql中instr(str, substr)返回substr在str中首次出现的位置（从1开始），substr为空字符串时恒返回0；需校验非空并注意大小写，跨数据库应优先使用like。
MySQL里用INSTR查子串位置，但别传空字符串
INSTR是MySQL专属函数，语法为INSTR(str, substr)，返回substr在str中首次出现的**从1开始的位置**（不是0）。如果没找到，返回0；如果substr为空字符串''，结果恒为0——这不是bug，是MySQL文档明确定义的行为，但常被误认为“没查到”，实际是提前短路了。
常见错误场景：动态拼接搜索词时没校验是否为空，导致INSTR(col, @search_term) > 0永远为假。
- 正确写法：
INSTR(name, 'admin') > 0判断是否包含“admin” - 安全写法（防空）：
@search_term != '' AND INSTR(name, @search_term) > 0 - 注意大小写：默认区分大小写，如需忽略，用
LOWER(name)或改列排序规则
PostgreSQL必须用POSITION，且语法和MySQL相反
PostgreSQL不支持INSTR，只提供POSITION，但它的参数顺序是POSITION(substr IN str)，和MySQL完全颠倒。返回值同样是**从1开始的位置**，未找到返回0。
容易踩的坑是直接把MySQL语句照搬过去，比如写成POSITION('abc', col)——这会报错syntax error at or near ","，因为PostgreSQL要求用IN关键字分隔。
- 正确写法：
POSITION('http' IN url) > 0 - 等价但更通用的写法：
url LIKE '%http%'（适合简单存在性判断） - 想获取位置后截取？直接用
SUBSTRING(url FROM POSITION('?' IN url))，注意FROM后跟的是起始位置
跨数据库可移植方案：优先用LIKE，复杂逻辑再考虑函数
如果你写的SQL要兼容MySQL、PostgreSQL甚至SQL Server，INSTR和POSITION都不可靠。最稳的方式是用标准SQL的LIKE做存在性判断：
- 查是否包含：
col LIKE '%value%' - 查是否以某串开头：
col LIKE 'prefix%' - 查是否以某串结尾：
col LIKE '%suffix'
性能上，LIKE前导通配符（如'%abc'）无法走B-Tree索引，而INSTR/POSITION本身就不走索引——所以别指望它们能加速模糊查询。真有性能要求，该建全文索引就建全文索引，别在函数上找补。
SQLite里没有INSTR或POSITION，得用INSTR()（小写函数名）
SQLite是个特例：它提供INSTR函数，但函数名是**小写instr**，且参数顺序和MySQL一致：instr(str, substr)。大小写写错（比如INSTR大写）在某些配置下会报no such function。
另外，SQLite的instr返回位置从1开始，未找到返回0，行为和MySQL一致——这点容易让人放松警惕，但一旦换到PostgreSQL就立刻崩。
- 正确写法：
instr(description, 'error') > 0 - 错误写法：
INSTR(description, 'error')（大写函数名，多数SQLite环境不认） - 注意：SQLite没有
POSITION，别试
真正麻烦的不是函数怎么写，而是团队里有人写MySQL风格，有人写PostgreSQL风格，SQL混着用还加缓存——最后连WHERE条件是不是生效都得逐条EXPLAIN看。函数差异只是表象，数据一致性才是藏在后面的硬骨头。
