下划线在SQL中的三重语义：从通配符到标识符的完整指南
在SQL的世界里，下划线这个小符号可真是个“多面手”。它能在不同场景下切换身份，稍不留神就会让查询结果跑偏。今天咱们就来彻底理清它的三种角色，以及如何精准驾驭它们。
LIKE 中的下划线 _ 是通配符，不是字面意思
直接写 WHERE name LIKE 'a_b' 会匹配 aab、acb，但不会匹配 a_b——因为 _ 默认代表“任意单个字符”。想查真实含下划线的字段，必须转义。
常见做法是显式指定转义字符：
- PostgreSQL / MySQL 8.0+ / SQL Server：用
ESCAPE子句，例如WHERE name LIKE 'a\_b' ESCAPE '\' - SQLite：默认不支持
ESCAPE，得用LIKE 'a[b]b'这类字符类绕过（前提是确认下划线不在方括号内） - 注意：不同数据库对反斜杠处理不一致，MySQL 5.7 默认把
\_当普通字符，但开启NO_BACKSLASH_ESCAPES模式后行为会变
正则表达式比 LIKE 更准，但语法和函数名因数据库而异
LIKE 只能做简单模式匹配，真要查 user_name 里带下划线且前后都是字母的项（如 first_name），就得上正则。但别直接套用 PCRE 写法——各数据库函数名和元字符支持差异很大：
- PostgreSQL：用
~操作符或REGEXP_MATCHES()，下划线就是字面量，写name ~ '^[a-z]+_[a-z]+$'即可 - MySQL 8.0+：用
REGEXP_LIKE(name, '^[a-z]+_[a-z]+$')；旧版 MySQL 5.7 只支持REGEXP，且不支持?、+等扩展语法 - SQL Server：没有原生正则，得靠
LIKE '[a-z]_[a-z]'拼凑，或启用 CLR 自定义函数 - Oracle：用
REGEXP_LIKE(name, '^[a-z]+_[a-z]+$')，但注意它默认大小写敏感，加'i'标志才忽略
性能陷阱：LIKE 前导通配符和正则都可能全表扫描
这才是关键所在。LIKE '%_abc' 或 REGEXP_LIKE(col, '_abc$') 这类模式无法利用 B-tree 索引——因为匹配逻辑从右往左或需遍历全部内容。实际执行时容易拖慢查询。
- 如果必须查结尾含下划线的值，优先考虑生成计算列 + 索引，例如 PostgreSQL：
ALTER TABLE t ADD COLUMN name_suffix TEXT GENERATED ALWAYS AS (RIGHT(name, 4)) STORED，再在name_suffix上建索引 - 避免在大表
WHERE中直接用REGEXP_LIKE做复杂校验；可先用LIKE '_%'快速过滤出含下划线的候选行，再用正则精筛 - SQLite 的
REGEXP是纯函数，无索引支持，数据量超万行就明显卡顿
特殊场景：下划线在列名或标识符里要反引号/双引号
这不是匹配问题，但常被混淆：当你要查的字段名本身带下划线（如 user_id），而你又用了不规范的 SQL 写法，就会报错。
- MySQL：用反引号包裹，
SELECT `user_id` FROM t；漏掉会当成user id（空格分隔）解析失败 - PostgreSQL / SQL Server：用双引号，
SELECT "user_id" FROM t；不加引号时它会自动转小写并忽略下划线语义，但若建表时用了双引号定义，就必须严格匹配大小写和下划线 - 别在正则里误写
"user_id"当作字符串字面量——那是语法错误，应写成'user_id'
说到底，下划线在 SQL 里横跨三类语义：通配符、字面字符、标识符组成部分。混用时出错往往不是语法写错，而是没意识到当前上下文到底归哪一类。理解这个底层逻辑，才能写出既准确又高效的查询。
