不推荐用 MySQL 原生 REGEXP 做严格邮箱校验，因其正则引擎功能有限、不支持关键特性且无法覆盖 RFC 5322 复杂规则，仅适合粗筛明显非法值，严格校验应交由应用层完成。
MySQL 用 REGEXP 判断邮箱格式是否可靠？
开门见山，先说核心结论：不推荐依赖 MySQL 原生的 REGEXP 进行严格的邮箱格式校验。原因很简单，MySQL 内置的正则表达式引擎，尤其是在 5.7 及更早的版本中，功能上存在不少局限。它既不支持诸如 \b、(?i) 这类高级特性，也对 Unicode 字符集处理乏力。更关键的是，邮箱地址的规范（RFC 5322）极其复杂，想在数据库层用一个正则模式就完美覆盖所有语法细节——比如本地部分（local-part）中引号的使用、点号的连续规则——几乎是“不可能完成的任务”。因此，它的定位很明确：适合在数据入库前做一道快速过滤，筛掉那些明显不合法的值（比如缺少“@”符号或顶级域名）。至于严谨的、生产级别的校验，还是得交给应用层的专业库来处理。
REGEXP 写邮箱基础匹配要注意什么？
如果只是出于性能考虑，需要在数据库层做一次初步的、宽松的筛查，那么编写正则模式时，有几个细节必须留意：
- 版本差异：MySQL 8.0 及以上版本提供了语义更清晰的
REGEXP_LIKE()函数，而 5.7 等旧版本只能使用column REGEXP ‘pattern’这种语法。 - 转义点号：模式中的
.必须转义为\.，否则在正则中，一个单独的点号意味着匹配“任意字符”，这会导致大量误判。 - 结构完整性：确保“@”符号前后都有内容。避免写成过于简单的
.*@.*\..*，这种模式虽然能匹配a@b.c，但也会放过@.com这种明显错误的结构，同时可能误伤像a@b.c.d.e这样完全合法的长域名邮箱。 - 常见模式与陷阱：网络上流传的宽松写法
^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}$在 MySQL 中直接使用可能有问题，因为默认情况下，^和$锚点可能不会按预期工作（除非使用REGEXP_LIKE并指定匹配类型）。 - 实践建议：在
WHERE子句中，一个相对稳妥的宽松模式可以是：email REGEXP ‘^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}’。注意，在 SQL 字符串中，反斜杠需要转义，所以是双反斜杠。
为什么 REGEXP 容易漏掉真实邮箱或误杀？
这正是问题的核心所在。MySQL 的正则引擎面对纷繁复杂的真实邮箱世界，常常力不从心，导致两种尴尬局面：把合法的拒之门外，或者把非法的迎进门来。具体来看：
- 合法但被拒：一些符合 RFC 标准但格式特殊的邮箱，比如带引号的本地部分
“john..doe”@example.com，或者包含加号标签的user+tag@example.co.uk，很容易被过于简单的正则模式错误地拒绝。 - 非法但通过：相反，一些明显错误的字符串，如包含多个“@”的
abc@def@ghi.com、缺少本地部分的@example.com，或者域名不完整的user@.com，却可能溜过检查。 - 国际化支持不足：对于中文域名邮箱（例如
张三@例子.中国），MySQL 默认的正则处理几乎无能为力，因为它对 UTF-8 字符类的识别能力有限。 - 大小写敏感性：邮箱地址本身对大小写不敏感，
AbC@ExAmPlE.CoM是合法的。但如果正则模式只写了[A-Z]，就会漏掉小写字母；若写成[A-Za-z]，又可能无法正确处理带重音符号的国际化邮箱字母。
可以说，试图用一个静态的正则表达式去匹配一个动态、复杂且充满历史包袱的规范，本身就是一场胜算不大的博弈。
真正要落地，该怎么做？
那么，在实际项目中，如何构建一个健壮的邮箱校验体系呢？答案是分层处理，各司其职。
- 数据库层：最低成本拦截：在 MySQL 这一层，目标不是完美校验，而是以极低的性能代价拦截最明显的垃圾数据。可以添加一个非常轻量的检查，例如：
email REGEXP ‘^[^@[:space:]]+@[^@[:space:]]+\.[^@[:space:]]+$’。这个模式的核心是确保有一个“@”和一个“.”，并且排除空格等非法字符。对于 MySQL 8.0.16 及以上版本，甚至可以将其作为CHECK约束直接建在表结构中。 - 应用层：核心校验阵地：这才是应该投入精力的地方。利用编程语言成熟、经过充分测试的验证库，例如 Python 的
email-validator、Node.js 的validator.js中的isEmail()函数，或者 Ja va 的Apache Commons Validator。这些库通常严格遵循 RFC 标准，并能处理各种边界情况。 - 极端情况下的备选：如果业务场景强制要求必须在数据库层实现强校验，可以考虑使用 MySQL 的用户定义函数（UDF），或者评估迁移到对正则支持更强大的数据库，比如 PostgreSQL（其
~操作符支持功能更丰富的 PCRE 引擎）。
最后，分享一个最容易被忽略的要点：前端的简单校验绝不能作为最终防线。浏览器内置的 type=“email” 输入框验证以及一些前端 Ja vaScript 正则，其标准非常宽松，甚至连 a@b 这样的字符串都可能通过。切记，前端的校验是为了提升用户体验，后端的校验才是为了保障数据安全与系统稳定。
