INVISIBLE列不提供安全防护，仅减少SELECT*等粗放操作的意外暴露；适用字段需满足可选、非必填、默认值安全三条件，如internal_version、audit_created_by等，禁用于主键、高频查询列及无默认值非空列。
INVISIBLE 列本身不提供加密或权限控制，不能替代行级安全策略或列级权限。它只影响默认查询行为，对有权限的用户毫无防护力——只要知道列名，SELECT internal_token FROM t1 就能直接读出。
真正能借它“提升部分数据安全性”的场景，仅限于**减少意外暴露**：比如开发、测试、监控脚本习惯性用 SELECT *，或 ORM 自动生成的查询未过滤敏感字段时，INVISIBLE 能让这些粗放操作自动跳过该列。
哪些字段适合设为不可见？
不是所有“想藏”的字段都合适，得满足两个硬条件：INVISIBLE 列必须是业务逻辑中可选、非必填、且默认值安全的字段。常见适用类型包括：
-
internal_version：内部版本号，应用层从不读写，只供 DBA 追踪数据变更节奏 -
audit_created_by：记录插入者账号，但前端和 API 层完全不感知，由触发器或应用中间件自动填充 -
mask_flag：标记某条记录是否已脱敏，供后台任务识别，前端永远不该看到
别碰这些：
- 主键或外键列（除非你明确要生成隐藏主键，见下一条）
- 被
WHERE、JOIN、GROUP BY频繁引用的列——设成不可见后，SQL 会报错或逻辑错乱 - 没有
DEFAULT值又不允许NULL的列——INSERT INTO t1 (a,b) VALUES (1,2)会失败
如何安全添加不可见列而不破坏现有 INSERT？
关键在默认值和空约束。错误示范：ALTER TABLE users ADD COLUMN token VARCHAR(64) INVISIBLE; —— 这会导致所有无显式列名的 INSERT 报错 Column 'token' cannot be null。
正确做法必须带安全兜底：
- 有默认值：
ADD COLUMN token VARCHAR(64) DEFAULT '' INVISIBLE - 允许 NULL：
ADD COLUMN token VARCHAR(64) NULL INVISIBLE - 自动生成（如 UUID）：
ADD COLUMN token VARCHAR(36) DEFAULT (UUID()) INVISIBLE
验证方式：执行一条旧式 INSERT INTO users (id, name) VALUES (100, 'alice')，确认成功且 token 自动填充。
为什么 SHOW CREATE TABLE 里能看到 INVISIBLE，但应用还是“看不见”？
因为 SHOW CREATE TABLE 是 DDL 元数据命令，它展示的是表结构定义；而应用“看不见”，指的是运行时 SQL 解析规则：优化器在处理 SELECT * 时主动过滤掉 EXTRA = 'INVISIBLE' 的列，不进结果集，也不参与字段位置计算。
这带来一个隐蔽风险：DESCRIBE t1 或 SHOW COLUMNS FROM t1 仍会显示该列（带 INVISIBLE 标记），但很多旧版 ORM、BI 工具或 Python 的 cursor.description 可能忽略 Extra 字段，误以为它是普通列——结果就是字段数对不上，fetchone() 返回元组长度变短，引发 IndexError。
所以，加 INVISIBLE 列后，务必检查所有接入该表的应用组件是否兼容 MySQL 8.0.23+ 的列可见性语义。
INVISIBLE 远不够用。它只是个“视觉过滤器”，不是访问控制开关。如果你发现团队靠它来“防泄漏”，那说明权限体系或应用层脱敏逻辑已经漏了。 
