MySQL 8.0.4+才默认支持完整正则语法（如^、$、d），低版本仅支持POSIX扩展，^[a-z]+$等写法会静默失效；触发器中必须用SIGNAL抛错，且需处理NULL和大小写（加BINARY）；正则校验性能差，高频场景应移至应用层。
MySQL 触发器里用 REGEXP 拦不住非法数据？先看它是否支持
MySQL 8.0.4+ 才在 REGEXP 中默认启用完整正则语法（如 ^、$、d），低版本只支持基本 POSIX 扩展正则，^[a-z]+$ 这类写法会静默失效或匹配异常。
实操建议：
- 运行
SELECT VERSION();确认版本；低于 8.0.4 就别依赖^/$锚点，改用RLIKE '^[a-z]+$'也无效，得靠SUBSTR()+LENGTH()组合兜底 - 测试正则时务必用
SELECT 'abc123' REGEXP '^[a-z]+$';单独验证，别直接塞进触发器里调试 - 注意大小写：MySQL 默认不区分大小写匹配，
'ABC' REGEXP '^[a-z]+$'在默认 collation 下居然返回 1 —— 要严格校验得显式加BINARY：BINARY 'ABC' REGEXP '^[a-z]+$'
BEFORE INSERT/UPDATE 触发器中抛错必须用 SIGNAL，不能靠 SELECT 或注释
常见错误是写 IF NOT NEW.phone REGEXP '^1[3-9]\d{9}$' THEN SELECT '手机号格式错误'; END IF; —— 这根本拦不住插入，MySQL 只当它是条无害查询，数据照进不误。
实操建议：
- 必须用
SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = '手机号格式错误';，SQLSTATE'45000'是通用未定义异常，MySQL 会中断当前语句并回滚 -
MESSAGE_TEXT值长度不能超 128 字符，超长会被截断，关键信息（如字段名）要前置 - 不要在同一个触发器里连续写多个
SIGNAL，MySQL 遇到第一个就退出，后续校验不会执行
正则校验放触发器里性能很敏感，尤其批量导入时
每行 INSERT 都执行一次 REGEXP，10 万行数据可能多花 2–3 秒，且无法利用索引加速 —— 正则匹配本质是全表字符扫描。
实操建议：
- 高频写入场景（如日志表、消息队列落库）禁用触发器正则校验，改到应用层做，或用
CHECK约束（MySQL 8.0.16+ 支持，但不支持REGEXP，只能用简单逻辑） - 若必须用触发器，把正则逻辑拆成两步：先用
CHAR_LENGTH(NEW.field) BETWEEN 11 AND 11快速过滤长度不符的，再用REGEXP做精细匹配 - 避免在
NEW.field为NULL时还硬套正则，NULL REGEXP 'xxx'返回NULL（非FALSE），条件判断会失效，得先写IF NEW.field IS NULL OR NOT NEW.field REGEXP '...'
PostgreSQL 的 pg_trigger 不支持正则抛错？其实有更稳的替代路径
PG 触发器函数里不能直接 SIGNAL，但很多人卡在写 RAISE EXCEPTION 时漏掉 USING 子句导致报错信息不明确，或者用 RAISE NOTICE 误以为能拦截数据。
实操建议：
- 必须用
RAISE EXCEPTION '邮箱格式错误' USING ERRCODE = '23514';，ERRCODE推荐用'23514'（check_violation），应用层容易识别 - 别在触发器函数里调
PERFORM查其他表做校验，容易引发锁等待或递归触发；复杂逻辑应提前在应用层完成 - PG 的
~操作符支持正则，但默认区分大小写，NEW.email ~ '^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+.[a-zA-Z]{2,}$'才可靠，漏掉A-Z会放过大写域名
