MySQL触发器中慎用正则：低版本不支持^$等语法，需先确认版本；校验必须用SIGNAL中断，不可用SELECT；身份证/邮箱等需多步拆解验证；高频写入应移至应用层或用CHECK约束。
MySQL 触发器里直接塞复杂正则表达式，大概率校验失效、性能崩盘、版本不兼容——不是写法不对，是它根本不是干这活的。
MySQL 8.0.4+ 才真正支持 ^ $ d 等完整正则语法
低版本（如 5.7 或 8.0.3 及以前）的 REGEXP 仅支持 POSIX 扩展语法，^[a-z]+$ 这类写法会静默返回 0 或匹配异常，而不是你预期的“不匹配”。
- 先运行
SELECT VERSION();确认真实版本，别信文档或开发环境配置 - 低于 8.0.4 就别用
^和$锚点，改用SUBSTR(NEW.field, 1, 1) REGEXP '[a-z]'+CHAR_LENGTH(NEW.field)组合兜底 -
d在 5.7 不被识别，必须写成[0-9]；大小写敏感要显式加BINARY，否则'ABC' REGEXP '^[a-z]+$'可能返回 1
触发器里抛错必须用 SIGNAL，不能靠 SELECT 或 IF + 注释
常见错误是写 IF NOT NEW.phone REGEXP '^1[3-9]\d{9}$' THEN SELECT '手机号格式错误'; END IF; —— 这条 SELECT 完全不阻断插入，数据照进不误。
- 必须用
SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = '手机号格式错误';，MySQL 遇到它才会中断语句并回滚 -
MESSAGE_TEXT超过 128 字符会被截断，关键信息（如字段名、规则示例）务必前置 - 一个触发器里不要写多个
SIGNAL，MySQL 执行第一个就退出，后续校验不会跑 -
NEW.field IS NULL必须单独判断，因为NULL REGEXP 'xxx'返回NULL（非0），直接用于IF判断会跳过
身份证/邮箱等“伪校验”必须拆解为多步，不能只靠 REGEXP
仅用 REGEXP 匹配身份证格式（如 ^[1-9]\d{5}(19|20)\d{2}(0[1-9]|1[0-2])...）只能筛掉明显非法字符串，但无法验证日期逻辑或第 18 位校验码。
- 先做长度拦截：
IF CHAR_LENGTH(NEW.id_card) != 18 THEN SIGNAL ... END IF; - 再用
SUBSTRING(NEW.id_card, 7, 8)提取出生日期，传给STR_TO_DATE(..., '%Y%m%d')，显式判断是否为NULL（如20231301返回NULL） - 第 18 位校验码必须手算：按权重数组
(7,9,10,5,8,4,2,1,6,3,7,9,10,5,8,4,2)对前 17 位逐位乘加，MOD(sum, 11)后查表比对'1','0','X','9','8','7','6','5','4','3','2' - 所有字符串操作（
SUBSTRING、CONVERT、MOD）在高频写入时开销显著，10 万行可能多耗 2–3 秒
高频写入场景下，正则校验必须移出触发器
每行 INSERT 都执行一次 REGEXP，本质是全行字符扫描，无法走索引，批量导入时延迟陡增，且容易拖垮主从同步。
- 日志表、消息落库、用户注册等高频写入场景，禁用触发器正则校验，改由应用层统一处理
- 若必须保留在数据库侧，优先用
CHECK约束（MySQL 8.0.16+ 支持），虽然它不支持REGEXP，但能高效拦截LENGTH、IN、数值范围等轻量逻辑 - 真要保留触发器，至少加前置快速过滤：比如手机号先
CHAR_LENGTH(NEW.phone) = 11，再REGEXP；身份证先LENGTH = 18，再切片校验 - 跨库联动（如 A 库插入后更新 B 库状态）不能靠触发器实现，MySQL 层面禁止跨库
UPDATE，这是硬限制，不是权限问题
最常被忽略的一点：正则校验本身不解决业务一致性。比如“同一手机号不能重复注册”，靠触发器查 EXISTS 是可行的，但若同时有并发插入，仍可能漏掉竞态——这时候真正该上的是唯一索引，不是正则。
