like适用于简单前缀/后缀匹配且性能高，regexp支持复杂正则模式但开销大、跨库兼容性差；like用%和_匹配，regexp用^、$、[]等元字符，且mysql中regexp默认不区分大小写、不支持部分高级特性。
LIKE 是最常用、兼容性最好的模糊匹配方式，但通配符位置直接影响性能；REGEXP 功能强但开销大，且 MySQL 8.0+ 和 SQLite/PostgreSQL 的语法不一致。
LIKE 中的 % 和 _ 用法与性能陷阱
百分号 % 匹配任意长度字符串（包括空），下划线 _ 只匹配单个字符。关键在位置：WHERE name LIKE '%abc' 无法走索引（后缀匹配），而 WHERE name LIKE 'abc%' 可用前缀索引加速。
- 避免写成
WHERE name LIKE '%abc%'—— 全表扫描几乎不可避免 -
WHERE name LIKE 'a_c'能命中索引（三个字符固定长度 + 单字符通配），适合结构化字段如编号 - MySQL 中大小写敏感性取决于列的 collation，
utf8mb4_0900_as_cs区分大小写，utf8mb4_0900_ai_ci不区分
MySQL 中 REGEXP 的实际写法与常见错误
MySQL 8.0+ 默认支持 REGEXP（旧版用 RLIKE），但正则引擎不支持反向引用、惰性匹配等高级特性。写错会静默失败或返回空结果。
- 匹配邮箱基本格式：
WHERE email REGEXP '^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}$'（注意双反斜杠转义） - 想查“以 apple 或 orange 开头”：
WHERE fruit REGEXP '^apple|^orange'，不能写成'^(apple|orange)'—— MySQL 不支持括号分组（8.0.17+ 才部分支持） - 空值不会被匹配，
NULL字段在REGEXP判断中恒为NULL，需显式加IS NOT NULL
PostgreSQL 和 SQLite 的正则替代方案
PostgreSQL 用 ~ 操作符（区分大小写）或 ~*（不区分），支持完整 PCRE 子集；SQLite 默认不带正则，需加载扩展或改用 GLOB（类 shell 通配，仅支持 * 和 ?）。
- PostgreSQL 示例：
WHERE title ~ '^(The|A) [A-Z]'匹配“The Great…”或“A Tale…” - SQLite 若未启用
REGEXP函数，可用GLOB 'The*' OR GLOB 'A*'，但无法做复杂逻辑 - 跨数据库项目慎用正则——
REGEXP在 MySQL、PostgreSQL、Oracle 中行为差异大，连转义规则都不同
真正难的不是写出能跑的语句，而是预判执行计划是否走索引、NULL 值怎么处理、以及换数据库时正则表达式要不要重写。
