MySQL 隐形列怎么兼容 SELECT *：INVISIBLE COLUMN 的灰度加字段方法

给老系统的 orders 表加字段时，最容易被忽略的不是 DDL 能不能执行，而是遗留代码里的 SELECT * 会不会突然多出一列。MySQL 的隐形列可以把“字段先落库”和“旧结果集保持不变”拆成两个动作：列已经存在，旧查询看不见；需要升级的代码再显式读取它。

先把兼容边界说清楚

本例的旧调用方只关心 id、customer_name 和 amount。新增的 risk_level 先设为隐形，数据照常写入，列定义也会出现在表元数据里。它不是权限控制，也不是加密；知道列名的查询仍可显式访问。

最小配方：先隐形加列，再显式读取

把下面的 risk_level 换成业务字段即可。默认值要和历史行兼容，否则加列时就要同时处理旧数据的空值策略。

ALTER TABLE orders
  ADD COLUMN risk_level VARCHAR(16)
  NOT NULL DEFAULT 'normal' INVISIBLE;

-- 新版本代码显式读取
SELECT id, customer_name, amount, risk_level
FROM orders
ORDER BY id;

这里的关键不是把 SELECT * 改成另一种星号写法，而是让新代码明确声明自己依赖哪些列。这样字段从隐形切换为可见时，老调用方仍然不会因为列顺序变化而悄悄收到新数据。

真实运行结果：旧查询和新查询各自看到什么

本例使用同一份 runtime/invisible-column.sql，先插入两条订单，再把 1002 号订单的风险级别改为 review。运行结果要看两件事：星号查询的列数是否保持为 3，以及显式查询能否读出 review。

mysql --table --show-warnings 

如果前一组结果只有 id、customer_name、amount，后一组结果带出 risk_level，说明“旧代码兼容”和“新代码取值”两个目标同时成立。不要只看 DDL 返回成功，数据读取才是这个方案的验收点。

什么时候切换为 VISIBLE

当所有关键调用方都不再依赖结果集位置，并且监控、导出、ORM 映射已经显式列出字段时，才考虑切换：

ALTER TABLE orders
  MODIFY COLUMN risk_level VARCHAR(16)
  NOT NULL DEFAULT 'normal' VISIBLE;

切换后立刻用一条受控查询检查结果集。若旧接口把列数当成固定协议，先不要切换；隐形列可以延长兼容窗口，但不能替代接口契约改造。

几个容易误判的坑

• 隐形不等于不可访问：只要知道列名，SELECT risk_level 仍然有效。
• 隐形不等于安全隔离：敏感字段还需要权限、脱敏和审计。
• ORM 的自动映射可能依赖 SELECT *；切换可见前要在测试环境核对字段顺序和反序列化。
• 回滚不是删除字段：本例的回滚检查是改回 VISIBLE 或保持隐形，是否删除要另行评估数据迁移和代码依赖。

常见问题

INVISIBLE 列会不会丢数据？

不会。它仍是表中的真实列，插入、更新和显式查询都可以处理；变化只在未点名列的列清单展开行为。

为什么 SELECT * 看不到新字段？

MySQL 会排除隐形列。需要读取时把列名写进查询，例如 SELECT id, risk_level FROM orders。

可以把主键设成 INVISIBLE 吗？

不要按普通业务列理解这个问题。主键和表至少一个可见列的约束需要单独核对目标 MySQL 版本文档，生产变更前应在同版本实例验证。

这个方案适合替代接口版本管理吗？

不适合。它解决的是表结构和旧星号查询的过渡，接口仍应显式定义字段、版本和兼容策略。

收尾检查

灰度加列的验收顺序可以固定为：先看旧 SELECT * 的字段形状，再显式读新列，最后执行 SHOW CREATE TABLE 核对 INVISIBLE。三项都符合预期，再决定是否让列对星号查询可见。