SELECT user_id,email,CONVERT(VARCHAR(10),birthday,120) AS birthday FROM users WHERE email LIKE '%/_%' ESCAPE '/';
这段 SQL 非常经典，完美演示了 ESCAPE 在实际业务中的价值。我们逐层拆解一下。
🎯 这段 SQL 在做什么？
目标：从 users 表中找出那些 email 地址中包含下划线 _ 的用户。
输出：用户ID、邮箱，以及一个格式化为 YYYY-MM-DD 的生日（只取前10个字符）。
📝 逐句解析
1. SELECT 子句
sql
SELECT user_id, email, CONVERT(VARCHAR(10), birthday, 120) AS birthday
user_id,email：直接返回原始值CONVERT(VARCHAR(10), birthday, 120)：将日期类型的birthday转换为字符串格式120是 SQL Server 的样式代码，代表yyyy-mm-dd hh:mi:ss（ODBC 规范）VARCHAR(10)只取前10个字符，恰好得到yyyy-mm-dd别名
birthday覆盖了原字段名
2. WHERE 子句（核心）
sql
WHERE email LIKE '%/_%' ESCAPE '/'
这个条件到底在匹配什么？
| 字符 | 在模式中的角色 | 实际含义 |
|---|---|---|
% | 通配符 | 匹配任意数量的任意字符（0个或多个） |
/ | 转义字符（由 ESCAPE '/' 定义） | 告诉 SQL：下一个字符我要当作字面量 |
_ | 被转义的通配符 | 现在它只代表真实的下划线字符 _ |
% | 通配符 | 匹配任意数量的任意字符 |
翻译成人话：邮箱地址中至少包含一个下划线（_），下划线前后可以有任意内容。
🔍 实际匹配示例
假设有以下邮箱数据：
是否匹配 | 原因 | |
john_doe@example.com | ✅ 匹配 | 包含下划线 _ |
jane.smith@example.com | ❌ 不匹配 | 没有下划线 |
_admin@example.com | ✅ 匹配 | 以下划线开头 |
user@_domain.com | ✅ 匹配 | 以下划线开头（域名部分） |
user@example_com | ✅ 匹配 | 包含下划线 |
user100@example.com | ❌ 不匹配 | 只有数字和字母，没有下划线 |
🎨 如果不用 ESCAPE 会怎样？
sql
-- 错误写法WHERE email LIKE '%_%'
这会出大问题！%_% 在 SQL 中的含义是：
%：匹配任意字符（0个或多个）_：匹配恰好一个任意字符%：匹配任意字符（0个或多个）
结果：%_% 实际上匹配任何至少有一个字符的字符串。因为中间的 _ 确保至少有一个字符，两边的 % 允许前后任意。这会匹配几乎所有的邮箱地址（除非是空字符串），完全背离了你的意图。
🔧 为什么选 / 作为转义符？
可能的原因：
邮箱地址中极少出现
/：RFC 标准邮箱格式不允许/（虽然某些系统扩展允许），所以/几乎不会和真实数据冲突可读性好：
'%/_%'比'%\\_%'在视觉上更清晰（反斜杠在字符串中还需要再转义一次）避免转义地狱：如果用
\，在 C#/Java 等语言中构建 SQL 字符串会变成"LIKE '%\\_%'"，非常丑陋
💡 知识点总结
| 概念 | 说明 |
|---|---|
LIKE 通配符 | %（任意多字符）、_（单字符） |
| 转义必要性 | 当你想搜索通配符本身时，必须转义 |
ESCAPE 子句 | 声明哪个字符是转义符 |
| 转义符选择原则 | 选一个绝不会出现在真实数据中的字符 |
CONVERT(..., 120) | SQL Server 特有的日期格式转换 |
🐛 潜在陷阱
数据库兼容性：
CONVERT和样式码120是 SQL Server / Sybase 特有语法。MySQL 应使用DATE_FORMAT()，PostgreSQL 使用TO_CHAR()或直接birthday::date。转义符本身：如果你搜索的内容本身包含
/（虽然邮箱中极少见），需要写成'%//_%' ESCAPE '/'（两个斜杠，第一个转义第二个）。性能问题：
LIKE '%...%'以通配符开头，无法使用索引，会全表扫描。如果数据量大，建议考虑全文索引或改用CHARINDEX(email, '_') > 0（SQL Server）或INSTR()（MySQL）等函数。
这段代码是一个教科书级别的案例，完美展示了 ESCAPE 的实际应用场景：当通配符本身成为搜索目标时，如何优雅地解决冲突