MySQL中LOCATE判断子串需先写子串后写主串，即LOCATE('error', content)>0；PostgreSQL须用POSITION('error' IN content)>0或STRPOS(content,'error')>0；FIND_IN_SET仅适用于SET类型字段。
MySQL里用LOCATE判断是否包含子串，别写反参数顺序
LOCATE是MySQL中判断子串存在的首选函数，但新手常把两个参数颠倒：第一个必须是待查的substring，第二个才是被搜索的string。写成LOCATE(content, 'error')会永远返回0——因为MySQL把它理解成“在'error'里找content”，逻辑完全错位。
正确写法是：LOCATE('error', content) > 0。这个表达式返回位置（从1开始）或0，所以直接和0比较即可判断存在性。
-
LOCATE('a', 'banana')→ 返回1 -
LOCATE('x', 'banana')→ 返回0 - 任一参数为
NULL，结果就是NULL，不是0，WHERE条件里会过滤掉整行（注意空值场景） - 支持第三个参数指定起始位置：
LOCATE('a', 'banana', 3)→ 从第3位开始搜，返回4
PostgreSQL要用POSITION或STRPOS，不能用LOCATE
PostgreSQL不识别LOCATE或INSTR，直接执行会报错：ERROR: function locate(unknown, unknown) does not exist。必须改用标准SQL的POSITION或兼容Oracle风格的STRPOS。
POSITION语法固定，IN关键字不可省略：POSITION('error' IN content) > 0；STRPOS参数顺序和MySQL的INSTR一致：STRPOS(content, 'error') > 0。
- 两者都不支持起始偏移量，如需跳过前N个字符，得先用
SUBSTRING(content FROM N+1)截取再查 -
POSITION对大小写敏感，取决于字段的collation；若需忽略大小写，统一转小写：POSITION(LOWER('Error') IN LOWER(content)) > 0 - 返回值同样是1-based位置或0，语义清晰，和MySQL的
LOCATE行为一致
FIND_IN_SET不是万能的“包含”函数，仅限逗号分隔SET字段
看到函数名带“FIND”和“SET”，容易误以为它能查任意字符串里的子串。实际它只适用于严格格式的枚举型字段：整个字段值必须是'a,b,c'这种无空格、纯逗号分隔的字符串。拿它查普通文本字段content，比如FIND_IN_SET('error', content)，结果永远是0或NULL，且无法走索引。
- 正确使用场景：字段定义为
status SET('active','pending','error')，值为'active,error'，此时FIND_IN_SET('error', status) > 0才有效 - 常见错误：把日志内容字段
message TEXT当成SET用，查询失效却无报错，极难排查 - 性能上，它本质是字符串遍历，比
LOCATE或LIKE '%%'还慢，且完全无法利用索引
LIKE '%xxx%'和LOCATE('xxx', str)性能几乎一样，但语义和大小写处理不同
很多人纠结该用LIKE还是LOCATE。其实二者在“是否包含”这个需求上，执行计划和性能差异极小（都是全表扫描），关键区别在语义明确性和大小写控制。
LIKE '%error%'是模式匹配，受collation影响大：默认可能忽略大小写，也可能区分，取决于字段定义；而LOCATE('error', content)默认做二进制比较，更稳定。
- 要强制忽略大小写，
LOCATE写法更直白：LOCATE(LOWER('Error'), LOWER(content)) > 0 -
LIKE无法表达“从第5位后开始找”，LOCATE可以加第三个参数实现 - 如果只是查“以xxx开头”，优先用
LIKE 'xxx%'——这时可能走前缀索引，LOCATE做不到
复杂点在于跨数据库适配：同一个SQL不能在MySQL和PostgreSQL里通用，LOCATE和POSITION语法不互通，而且空值、大小写、偏移支持各不相同。别指望一个函数写遍所有库。
