LIKE查不出下划线因_是单字符通配符，需转义如LIKE 'a\_b' ESCAPE ''；REGEXP可替代但性能差，尤其无索引时易全表扫描；中文搜索应优先用全文索引而非LIKE或REGEXP。
LIKE 通配符为什么查不出带下划线的字段
因为 _ 在 LIKE 中是单字符通配符，不是字面意义的下划线。比如 WHERE name LIKE 'a_b' 会匹配 acb、a2b，但不会匹配 a_b 本身。
要匹配真实下划线，必须转义：LIKE 'a_b' ESCAPE ''；或者换用更安全的字符（如 |）：LIKE 'a|_b' ESCAPE '|'。
- MySQL 默认不启用
ESCAPE，必须显式声明 - PostgreSQL 不支持
ESCAPE语法，得用ESCAPE ''或改用~正则操作符 - SQLite 的
ESCAPE只在编译时开启ENABLE_ESCAPE才生效，多数预编译版本不支持
REGEXP 能替代 LIKE 吗？性能差多少
能替代，但别无脑替换。正则表达式功能强，代价是执行开销大——尤其没索引支撑时，REGEXP 基本强制全表扫描。
LIKE 'abc%' 可走前缀索引，REGEXP '^abc' 在 MySQL 8.0+ 也能用函数索引优化，但老版本或复杂模式（如 .*xyz）就彻底失效。
- MySQL 用
REGEXP或RLIKE，区分大小写取决于列排序规则 - PostgreSQL 用
~（区分大小写）或~*（不区分），不支持REGEXP关键字 - SQLite 默认不带正则支持，需加载扩展或用
GLOB（仅支持*和?）
中文模糊搜索用 LIKE 还是 REGEXP 更靠谱
都一样不靠谱——标准 LIKE 和 REGEXP 都按字节/字符逐个比对，不理解中文语义，也没分词能力。
比如搜“数据库”，LIKE '%数据%' 能命中，但 LIKE '%库%' 可能漏掉“数据库系统”这种跨词边界的情况；正则也解决不了歧义切分问题。
- 真要搜中文，优先考虑全文索引：
MATCH ... AGAINST（MySQL）、to_tsvector（PostgreSQL） - 若只能用模糊匹配，确保字段用 UTF8MB4 排序规则（如
utf8mb4_unicode_ci），避免乱码导致匹配失败 - 避免用
REGEXP '[u4e00-u9fa5]+'匹配中文——部分数据库不支持 Unicode 属性类，且性能极差
WHERE col LIKE '%x%' OR col REGEXP 'y|z' 这种混合写法有隐患吗
有，而且很隐蔽：MySQL 会把整条 OR 条件判为不可下推，即使左边 LIKE 能用索引，右边 REGEXP 也会拖垮整个查询计划。
EXPLAIN 看到 type: ALL 就基本确认被降级成全表扫描了。这不是语法错，是优化器放弃索引合并的常见表现。
- 拆成两个独立查询，用
UNION ALL合并结果（注意去重成本） - 把
REGEXP条件提到应用层过滤，只让 SQL 走索引路径 - 检查是否真需要
OR：有时用IN或覆盖索引字段能绕过这个问题
模糊匹配最麻烦的从来不是写法，而是你以为它在走索引，其实早就全扫了。
