MySQL中查子串应优先用LOCATE以兼顾SQL标准兼容性，INSTR为MySQL特有；二者功能相同但参数顺序相反，查不到返回0，查到返回从1开始的位置，NULL输入返回NULL，且均不走索引。
MySQL里查子串用 LOCATE 还是 INSTR？
两个函数功能完全一样，LOCATE 是标准 SQL 风格写法（LOCATE('sub', str)），INSTR 是 MySQL 特有风格（INSTR(str, 'sub')）。选哪个只看团队习惯或 SQL 兼容需求——如果未来可能迁到 PostgreSQL 或 SQL Server，优先用 LOCATE；纯 MySQL 项目，INSTR 更顺手。
常见错误是记反参数顺序：写成 INSTR('sub', str) 会返回 0（找不到），但不报错，容易误判。实际它第一个参数是被搜索的字符串，第二个才是子串。
查不到时返回什么？怎么安全判断存在性
两个函数查不到都返回 0，查到则返回**起始位置（从 1 开始计数）**。所以不能用 IF(LOCATE(...), ...) 直接当布尔值用——因为位置可能是 1，而 1 在 MySQL 里是 true，没问题；但万一子串在开头，LOCATE 返回 1，逻辑成立；可如果写成 LOCATE(...) > 0 才是真正稳妥的写法。
-
LOCATE('abc', 'xabcx') > 0→ true（推荐） -
LOCATE('abc', 'xabcx')单独用于条件 → 虽然也生效，但语义模糊，易被后续维护者误解 -
INSTR('xabcx', 'abc') = 0→ 错误！这是判断“不存在”，但漏掉了空字符串或 NULL 输入的边界情况
遇到 NULL 或空字符串会怎样
只要任意一个参数为 NULL，LOCATE 和 INSTR 都直接返回 NULL，而不是 0。这意味着如果你没做预处理，WHERE LOCATE(sub, col) > 0 会把含 NULL 的整行过滤掉——不是因为你没找到，而是表达式结果为 NULL，而 NULL > 0 是 unknown，在 WHERE 中等价于 false。
安全写法是显式处理：WHERE LOCATE('x', col) > 0 AND col IS NOT NULL，或者更彻底地用 COALESCE：WHERE LOCATE('x', COALESCE(col, '')) > 0。
另外注意：LOCATE('', 'abc') 返回 1（空字符串被认为在任何字符串开头存在），这和多数人直觉不符，但符合 SQL 标准定义。
性能差异大吗？要不要加索引
两者底层实现一致，性能无差别。但关键点在于：**它们都不走索引**。哪怕你在 name 字段建了 B+Tree 索引，WHERE LOCATE('john', name) > 0 依然全表扫描。
真要查子串且数据量大，得换思路：
- 前缀匹配用
name LIKE 'john%'→ 可走索引 - 后缀匹配用
name LIKE '%john'→ 多数引擎无法走索引（除非倒排或函数索引） - 全文检索场景考虑
MATCH ... AGAINST或外部方案（Elasticsearch） - 如果只是固定关键词枚举，提前拆解为字段（如
has_tag_json+ JSON_CONTAINS）更可控
别指望 LOCATE 或 INSTR 优化查询速度——它们是兜底工具，不是加速器。
