REGEXP_LIKE默认不指定逻辑关系，匹配效果取决于正则写法：如'apple|banana'表示任一满足，'^(?=.apple)(?=.banana)'表示全部满足（MySQL 8.0+支持），而MySQL 5.7不支持后者。
REGEXP_LIKE 能否同时匹配多个关键词
可以，但要注意逻辑关系。默认是“全部满足”还是“任一满足”，取决于正则表达式写法。REGEXP_LIKE 本身只做一次模式匹配，想查“包含 A 且包含 B”，不能写成 REGEXP_LIKE(col, 'A') AND REGEXP_LIKE(col, 'B')——这虽然可行，但失去了正则的组合优势；更高效的是用正则的“正向先行断言”，比如 REGEXP_LIKE(col, '^(?=.*A)(?=.*B)')（Oracle/MySQL 8.0+ 支持）。不过注意：MySQL 5.7 不支持 ? 语法，会报错 Got error 'repetition-operator operand invalid'。
常见错误现象：REGEXP_LIKE(col, 'apple|banana') 看似在查“apple 或 banana”，但实际匹配的是子串连续出现（比如 “applebanana” 也会中），而不是字段里“出现 apple 且出现 banana”或“出现其中任意一个”。真正想表达“任意一个”，应确保字段值本身不含干扰字符，或加词边界：REGEXP_LIKE(col, '(^|\s)apple(\s|$)') OR REGEXP_LIKE(col, '(^|\s)banana(\s|$)')——但这已退化为多个 LIKE 的等价写法。
多个 LIKE 连写是否比 REGEXP_LIKE 快
多数情况下是的，尤其当字段有索引且关键字靠前时。LIKE 'abc%' 可走 B-tree 索引，而 REGEXP_LIKE(col, 'abc') 几乎总是全表扫描。但若写成 LIKE '%abc%'，索引就失效了，此时两者性能差距不大，都慢。
使用场景建议：
- 查前缀（如“张%”）→ 用
LIKE，能用索引 - 查固定多个独立关键词（如“必须含‘发票’且含‘电子’”）→ 用多个
LIKE连AND，语义清晰、兼容性好、优化器容易推导 - 查复杂模式（如“数字+字母+下划线组合”“邮箱格式”）→ 才值得上
REGEXP_LIKE，别为多关键词硬套正则
Oracle 和 MySQL 的 REGEXP_LIKE 行为差异
Oracle 的 REGEXP_LIKE 默认不区分大小写，MySQL 8.0+ 默认区分（除非加 'i' 标志）。同样，MySQL 中 ^ 和 $ 默认匹配整行开头结尾，Oracle 中默认匹配字符串开头结尾——但如果你查的是 VARCHAR2 字段，没换行符，影响不大；一旦字段含 CHAR 或带空格填充，$ 在 Oracle 中可能匹配到空格后的位置，导致意外命中。
参数差异要点：
- Oracle：支持
match_param第三个参数，如'i'（忽略大小写）、'm'（多行模式） - MySQL：第三个参数是
match_type，仅支持'c'（区分）、'i'（不区分）、'n'（.匹配换行符） - PostgreSQL 用
~*（不区分）或~（区分），没有内置REGEXP_LIKE函数
模糊匹配多个关键词的实用写法推荐
别迷信正则。对“标题中同时出现‘数据库’和‘优化’”这类需求，最稳写法仍是：
WHERE title LIKE '%数据库%' AND title LIKE '%优化%'
它在所有主流 SQL 引擎都可用，执行计划清晰，DBA 容易调优。如果关键词很多（比如 5 个），再考虑用全文索引（MATCH ... AGAINST in MySQL，TO_TSVECTOR in PostgreSQL）或应用层分词预处理。
容易被忽略的一点：LIKE 的通配符 % 是按字节匹配的，遇到多字节字符（如中文、emoji），只要字段编码一致（UTF8MB4），就没问题；但若前端传入关键词时有多余空格或不可见字符（比如 u200b 零宽空格），LIKE 就会查不到——调试时先 SELECT DUMP(keyword) 或 HEX(keyword) 看真实字节。
