patindex在sql server中用于基础邮箱校验，可快速筛除明显非法格式（如无@、无点），但无法实现rfc 5322级完整验证；其返回非0仅表示匹配模式“@+任意字符+.”，不保证邮箱真实有效，且需确保输入已trim且非空。
SQL Server 中用 PATINDEX 做基础邮箱格式校验
纯 SQL 无法做 RFC 5322 级别的完整邮箱验证，但可用 PATINDEX 快速筛掉明显非法的输入（如无 @、无点、@ 后无域名等）。它比 LIKE 更灵活，支持通配符位置定位。
常见错误现象：PATINDEX('%@%.%', @email) 返回 0 —— 这说明没匹配到“@ + 任意字符 + .”，但不等于邮箱一定错，比如 user@localhost 就合法（虽不常见）；反过来，返回非 0 也不代表邮箱真能发信。
- 必须确保
@email非空且已TRIM，否则前后空格会导致PATINDEX失效 - 推荐组合判断：
PATINDEX('%[A-Za-z0-9._%+-]%@%[A-Za-z0-9.-]%.[A-Za-z]%', @email) > 0，但注意 SQL Server 不支持+在字符类中，得写成[A-Za-z0-9._%-] - 性能上，
PATINDEX是标量函数，若在大表 WHERE 中大量调用会拖慢查询，仅建议用于入参校验或小批量数据
PostgreSQL 里用 ~ 正则直接匹配
PostgreSQL 原生支持 POSIX 正则，~ 操作符比 SQL Server 的字符串函数更贴近真实邮箱结构。不过仍要警惕过度复杂化：一个看似严谨的正则（如匹配所有 RFC 规则）反而容易漏掉新顶级域（如 .app、.dev）或导致回溯爆炸。
使用场景：存储过程入参检查、触发器拦截非法插入。
- 基础安全写法：
@email ~ '^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+.[A-Za-z]{2,}$'—— 注意开头^和结尾$防止部分匹配 - 避免用
.*匹配本地部分（@前），它可能吞掉换行或控制字符；改用[A-Za-z0-9._%+-]+更可控 - 兼容性影响：该正则在 pg 9.6+ 稳定，但若字段含 Unicode（如中文邮箱别名），需升级到 10+ 并启用
ICU排序规则，否则[A-Za-z]会漏掉
MySQL 存储过程中调用 REGEXP_LIKE 的坑
MySQL 8.0+ 才有 REGEXP_LIKE，5.7 及之前只能靠 RLIKE（功能相同但语法略旧）。直接在存储过程里写正则没问题，但要注意默认是**大小写不敏感**匹配 —— 这对邮箱本地部分其实合理（RFC 允许大小写混合），但对域名部分，实际 DNS 解析是大小写无关的，所以不必强求区分。
容易踩的坑：
-
REGEXP_LIKE(@email, '^[a-z0-9._%+-]+@[a-z0-9.-]+.[a-z]{2,}$')在开启lower_case_table_names=1的服务器上可能误判大写字母，应去掉a-z的限制或加i标志（MySQL 8.0.22+ 支持REGEXP_LIKE(expr, pat, 'i')） - MySQL 对反斜杠处理特殊：写
.时，存储过程体里需双写为\.，否则会被当作转义失败 - 如果存储过程被频繁调用（如每秒上百次注册），正则编译开销明显，可考虑把常用正则预编译为用户变量（MySQL 不支持，此路不通），不如前置到应用层
为什么不该只依赖数据库层做邮箱验证
数据库校验只能保证格式“看起来像”，无法确认邮箱是否真实存在、能否收信、是否被弃用。例如 test@xxx.xxx 可能通过所有正则，但域名 xxx.xxx 根本不存在 MX 记录。
真正关键的遗漏点：
- 没有检查域名是否有有效 MX 记录 —— 这必须由应用层用 DNS 查询完成，SQL 无法发起网络请求
- 忽略国际化域名（IDN）：像
用户@例子.中国经 Punycode 编码后是xn--fsq092b@xn--fiqs8s，数据库正则若没适配 UTF8MB4 和 Unicode 属性，会直接拒绝 - 某些邮箱服务（如 Gmail）允许
+后缀（user+tag@gmail.com），但企业邮箱可能禁用，规则得按业务定，不能全靠通用正则
最常被跳过的动作：在存储过程里只做格式检查后，就直接 INSERT 用户记录 —— 正确做法是标记为 “待验证”，发确认邮件，等用户点击链接才激活账户。
