优先选LOCATE()，因其支持从指定位置搜索的第三个参数；INSTR()参数顺序相反且不支持偏移量，但旧版本兼容性更好。
MySQL里找子串位置，用 LOCATE() 还是 INSTR()？
两个函数都能返回子串在字符串中的起始位置（从1开始计数），功能几乎等价，但行为细节有差异。实际选哪个，主要看是否需要指定搜索起点、是否在意大小写、以及是否要兼容老版本。
-
LOCATE(substring, str)支持第三个参数：LOCATE(substring, str, pos)，表示从第pos个字符开始搜——这是INSTR()不具备的 -
INSTR(str, substring)参数顺序相反，且不支持偏移量；但它在某些旧版本 MySQL（如 5.5 之前）更稳定 - 两者都区分大小写，依赖字段的 collation；若想忽略大小写，得先统一转成小写，比如
LOCATE(LOWER('ABC'), LOWER(col)) - 没找到时都返回
0，不是NULL—— 这点常被误判为“空值”，导致条件写成IS NULL而漏匹配
常见错误：为什么 LOCATE() 总是返回 0？
多数情况不是函数写错了，而是数据或比较方式不匹配。最典型的三个原因：
- 字段值含不可见字符（比如开头有空格、
\n或 BOM），用HEX(col)或TRIM()检查一下 - 子串本身带前后空格，比如写成了
LOCATE(' abc ', col)，而实际数据是'abc' - 字段是
TEXT类型且启用了严格模式，对超长内容截断后导致匹配失败；可临时用SUBSTRING(col, 1, 1000)缩小范围测试
在 WHERE 条件里用 LOCATE() 判断包含关系，要注意性能
直接写 WHERE LOCATE('keyword', col) > 0 看似简洁，但无法走索引——哪怕 col 上建了普通索引也没用。本质是全表扫描。
- 如果只是判断“是否包含”，优先用
col LIKE '%keyword%'，语义相同，部分 MySQL 版本还能触发前缀索引优化（需字段左端固定） - 若必须用位置做计算（比如取关键词后5个字符），再用
LOCATE()，但记得加EXPLAIN看执行计划 - 高频模糊查询场景，考虑生成冗余字段（如
has_keyword TINYINT）或上全文索引（FULLTEXT），别硬扛LOCATE()+ 大表
替换字符串时顺便获取位置？别嵌套调用 LOCATE()
有人想“先找到位置，再用 SUBSTRING() 截出来”，结果写出类似 SUBSTRING(col, LOCATE('x', col), 5) 的表达式。这本身没问题，但容易忽略边界问题：
- 如果
LOCATE()返回0，SUBSTRING(col, 0, 5)会从开头取（MySQL 中位置 0 视为 1），逻辑就歪了 - 更安全的做法是加
CASE：CASE WHEN LOCATE('x', col) > 0 THEN SUBSTRING(col, LOCATE('x', col), 5) ELSE NULL END - 如果目标是“把第一次出现的子串替换成别的”，直接用
REPLACE(col, 'old', 'new')更简单；它不关心位置，也不怕0
LOCATE() 更灵活，INSTR() 更直白。真正麻烦的从来不是函数选哪个，而是原始数据里那些看不见的空格、编码差异、还有你以为“肯定存在”结果根本没存进去的脏数据。 
