区分通配查询与显式列名查询在 INVISIBLE 列上的返回差异

给旧应用的表增加辅助列时，最容易踩到的坑是：表结构明明多了一列，原来的 SELECT * 却看不到它；改成显式列名后，这一列又能正常返回。MySQL 的 INVISIBLE 不是删除列，而是改变列是否参与通配展开。处理这类兼容性问题，关键是把“通配查询”和“显式投影”分开判断。

先用最小表复现两种返回结果

下面的示例把 trace_id 设为不可见列。它仍然属于表结构，也可以保存数据，只是不会被通配符自动加入结果集。

CREATE TABLE orders_demo (
    id BIGINT PRIMARY KEY,
    amount DECIMAL(10, 2) NOT NULL,
    trace_id VARCHAR(64) INVISIBLE
);

-- 显式给不可见列赋值，避免把它误认为没有这个字段
INSERT INTO orders_demo (id, amount, trace_id)
VALUES (101, 39.90, 'req-a7f2');

-- 通配查询只展开可见列
SELECT * FROM orders_demo;

-- 显式列名可以读取不可见列
SELECT id, amount, trace_id FROM orders_demo;

第一条查询返回 id 和 amount，第二条才会带上 trace_id。因此，结果列少一列不代表数据没有写入，也不代表 ALTER TABLE 没有生效。

表别名通配也不会绕过不可见属性

联表查询里常写成 o.*，但它只是带表限定的通配符，规则没有变化。想同时拿到隐藏辅助列，必须把它单独写进选择列表。

-- o.* 仍只返回 orders_demo 的可见列
SELECT o.*
FROM orders_demo AS o
WHERE o.id = 101;

-- 需要追踪字段时显式补出列名
SELECT o.id, o.amount, o.trace_id
FROM orders_demo AS o
WHERE o.id = 101;

-- 生产接口建议固定投影，避免返回列随表结构变化
SELECT o.id, o.amount
FROM orders_demo AS o
WHERE o.id = 101;

固定投影和不可见列可以配合使用：旧接口继续只拿业务字段，新版本的内部链路按需显式读取 trace_id。不要用“把 * 改成 o.*”作为修复，这只解决歧义，不改变可见性。

用元数据确认列存在且确实不可见

当 ORM 映射或导出工具报告“字段不存在”时，先确认数据库元数据，再判断是查询投影问题。MySQL 会在 INFORMATION_SCHEMA.COLUMNS.EXTRA 中标记不可见列。

-- 先查看列是否存在，以及可见性标记
SELECT COLUMN_NAME, ORDINAL_POSITION, EXTRA
FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_SCHEMA = DATABASE()
  AND TABLE_NAME = 'orders_demo'
ORDER BY ORDINAL_POSITION;

-- 查看完整 DDL，确认 INVISIBLE 没有被迁移脚本漏掉
SHOW CREATE TABLE orders_demo;

如果 EXTRA 为 INVISIBLE，说明列存在但不会被 * 展开；若显式查询仍报未知列，再检查当前连接的数据库、表名拼写和迁移是否落在了另一套环境。

把兼容性边界写进查询和迁移约定

新增不可见列前，先确认写入路径是否使用显式列清单。依赖无列名的 INSERT INTO orders_demo VALUES (...) 时，值列表只按可见列计数；要写入不可见列，改用列名清单。对外接口则尽量保持显式投影，避免以后把可见列加入表中时改变响应结构。

常见问题

INVISIBLE 列是不是无法更新？

不是。UPDATE orders_demo SET trace_id = 'req-b8c1' WHERE id = 101 可以显式更新它；限制只发生在通配展开。

把列改成 VISIBLE 会不会改变数据？

不会改变已有值，但会让 * 和 别名.* 在后续查询中把它带入结果，接口响应和导出字段可能因此变化。

为什么 ORM 自动生成的查询看不到这列？

很多 ORM 使用通配查询或根据可见元数据生成投影。先记录实际 SQL，再用显式列名验证；不要直接删除 INVISIBLE 属性。

判断这类问题时可以记住一句话：不可见列仍然存在，通配符看不见它，明确写出列名就能访问它。