MySQL生成列不能替代应用层数据清洗，但可固化确定性转换逻辑；必须使用确定性表达式（如CONCAT、UPPER、price*(1+tax_rate)），禁用NOW()、RAND()、子查询等非确定性函数；STORED列可索引、写时计算，VIRTUAL列读时计算、不可索引。
MySQL 的 Generated Column 不能替代应用层的数据清洗，但能可靠地固化某些确定性转换逻辑，前提是字段依赖关系稳定、计算开销可控。
Generated Column 必须是确定性表达式
MySQL 拒绝任何含不确定函数的定义，比如 NOW()、RAND()、UUID() 或子查询。哪怕只是想把 created_at 转成日期格式，也得用 DATE(created_at) 而不是 STR_TO_DATE(created_at, '%Y-%m-%d')（后者在某些版本中可能被误判为非确定性）。
- 允许：
CONCAT(first_name, ' ', last_name)、UPPER(email)、price * (1 + tax_rate) - 禁止：
UNIX_TIMESTAMP()、(SELECT COUNT(*) FROM logs WHERE logs.user_id = users.id) - 注意：自定义函数必须显式声明为
DETERMINISTIC，否则建表失败
STORED 和 VIRTUAL 类型的实际差异
STORED 列物理写入磁盘，支持索引、可用于 WHERE 条件且查询时无需重新计算；VIRTUAL 列只在读取时实时计算，不占额外存储，但无法被索引，且每次访问都触发表达式求值。
- 适合
STORED：频繁用于JOIN或ORDER BY的派生字段，如full_name VARCHAR(200) STORED AS (CONCAT(last_name, ', ', first_name)) - 适合
VIRTUAL：仅用于展示、计算轻量（如字符串截取）、或原始字段更新极频繁而派生值极少被查的场景 - 性能提示：对大表加
STORED列会触发全表重建，DDL 时间与数据量正相关
常见错误：NULL 值传播与类型隐式转换
只要参与计算的任一源字段为 NULL，整个生成列结果就是 NULL——这和多数人直觉中的“空字符串拼接”不同。同时，MySQL 不自动提升类型精度，INT 和 DECIMAL(5,2) 相乘可能截断小数位。
- 避免意外 NULL：用
COALESCE(name, '')替代裸name，尤其在CONCAT()中 - 控制精度：显式转类型，例如
CAST(price AS DECIMAL(10,2)) * tax_rate - 验证方式：插入含
NULL的测试行后，执行SELECT generated_col, source_col FROM t LIMIT 1看是否符合预期
真正麻烦的不是语法，而是当业务逻辑变化时，修改 Generated Column 需要 ALTER TABLE ... MODIFY COLUMN，而这个操作在 MySQL 5.7+ 仍可能锁表。如果预处理规则本身还在演进，不如先用视图过渡，等逻辑稳定再落地为生成列。
