MySQL触发器中必须使用BEFORE INSERT/UPDATE才能通过SET NEW.field = UPPER()/LOWER()修改待写入值；AFTER触发器无法更改已入库数据，且UPDATE触发器内再UPDATE同表会引发递归错误。
触发器里用 UPPER() 或 LOWER() 转换大小写，但必须配合 BEFORE INSERT/UPDATE
直接在 AFTER 触发器里改 NEW 字段无效——数据已经入库了。只有 BEFORE INSERT 和 BEFORE UPDATE 才能真正修改即将写入的值。
常见错误是写成 AFTER，结果日志显示执行了，但表里还是原样；或者漏掉 UPDATE 触发器，导致后续修改逃过标准化。
- 对姓名、城市等字段，通常用
UPPER(NEW.name)或INITCAP(NEW.name)（PostgreSQL） - MySQL 没有
INITCAP，得组合CONCAT(UPPER(LEFT(NEW.name, 1)), LOWER(SUBSTRING(NEW.name, 2))) - SQLite 不支持触发器中赋值给
NEW字段，只能靠应用层或视图补救
避免递归触发：UPDATE 触发器里别再 UPDATE 同一张表
如果触发器逻辑里写了 UPDATE users SET name = UPPER(name) WHERE id = NEW.id，会再次激活自身，造成无限循环或报错 ERROR 1442 (HY000): Can't update table 'users' in stored function/trigger（MySQL）。
正确做法是直接赋值给 NEW.name，让 MySQL 在插入/更新前就完成转换。
- ✅ 正确：
SET NEW.name = UPPER(NEW.name); - ❌ 错误：
UPDATE users SET name = UPPER(name) WHERE id = NEW.id; - 注意：某些老版本 MySQL 对空字符串或 NULL 的
UPPER()行为不一致，建议加IF NEW.name IS NOT NULL AND NEW.name != '' THEN ... END IF;
区分业务场景：全大写 vs 首字母大写，别一刀切
不是所有字段都适合转成全大写。比如邮箱地址必须小写（user@DOMAIN.COM ≠ user@domain.com），而国家代码（US）、状态码（ACTIVE）反而需要强制大写。
一个字段是否该标准化，取决于它后续怎么用：做索引？参与 JOIN？对外暴露？
- 邮箱字段：一律
LOWER(NEW.email)，否则可能重复注册或登录失败 - 产品型号、分类编码：常要求固定大写，如
NEW.model = UPPER(TRIM(NEW.model))（顺便去首尾空格） - 中文名、备注字段：一般不转大小写，
UPPER()对 UTF8MB4 中文无影响但没必要，还可能干扰分词
触发器无法覆盖已有脏数据，上线前必须补处理
触发器只管“将来”，不管“过去”。表里已有的混合大小写数据（比如 john、JOHN、John）不会自动修正。
上线触发器前，必须手动跑一次标准化清洗，否则查询时仍要写 WHERE UPPER(name) = UPPER(?)，失去索引优势。
- MySQL 补数据示例：
UPDATE users SET name = UPPER(name) WHERE name != UPPER(name); - 记得先备份，再加 WHERE 条件限制范围，避免误操作整表
- 补完后建函数索引（MySQL 8.0+）或生成列 + 索引，才能让
WHERE name = 'JOHN'走索引
最易被忽略的是字符集和排序规则的影响：如果字段用 utf8mb4_0900_as_cs（大小写敏感），那 'a' 和 'A' 就是两个不同值，触发器转换后才能保证语义一致。但换成 _ci 排序规则，又会让索引失效——这事得从建表时就定好。
