INVISIBLE列不是权限控制机制，仅对SELECT *等默认操作做视觉屏蔽，无法防止敏感数据泄露；它真正价值在于兼容性缓冲，如平滑添加新字段、为无主键表加隐藏主键、灰度引入审计字段等场景。
INVISIBLE 列不是权限控制机制，它不能真正“保护”敏感数据，只对默认查询行为做视觉屏蔽。如果你指望靠它防泄露，上线当天就可能出事。
不可见列根本挡不住敏感字段暴露
只要用户有 SELECT 权限（哪怕只针对某几列），就能通过以下方式拿到不可见列名和值：
-
DESC table_name或SHOW COLUMNS FROM table_name会明确显示EXTRA列为INVISIBLE -
SELECT TABLE_NAME, COLUMN_NAME, EXTRA FROM INFORMATION_SCHEMA.COLUMNS直接查出所有列定义 -
SHOW CREATE TABLE输出里带/*!80023 INVISIBLE */注释，字段名清清楚楚 - 只要有
INSERT或UPDATE权限，还能用报错信息试探字段是否存在（比如故意传超长字符串触发Data too long）
哪些场景下 INVISIBLE 确实有用
它的价值不在安全，而在兼容性缓冲和灰度演进：
- 老系统里存在大量
SELECT *或不指定列名的INSERT INTO table VALUES (...)，加新字段时用INVISIBLE可避免立刻报错ERROR 1136 (21S01): Column count doesn't match value count - 想给无主键表悄悄加一个自增主键（如
ALTER TABLE logs ADD COLUMN id BIGINT AUTO_INCREMENT PRIMARY KEY INVISIBLE），不影响现有写入逻辑 - 新增审计字段（如
last_modified_by、internal_flag），先设为不可见，等应用层代码逐步适配后再ALTER TABLE ... MODIFY COLUMN ... VISIBLE
真要隐藏敏感元数据，得换思路
别在列可见性上打转，直接绕过它：
- 用视图封装：创建
v_user_public视图只暴露非敏感字段，再授SELECT ON v_user_public给应用账号 - 应用层白名单：所有 SQL 必须走预定义字段列表，数据库账号禁用
SELECT表权限，只允许调用特定存储过程 - 强敏感字段必须加密落库：如身份证号用
AES_ENCRYPT()存，解密逻辑全在应用侧，数据库里连字段名都不该让低权限用户看见 - 撤掉元数据访问权：关掉
information_schema_stats_enabled，并回收用户对INFORMATION_SCHEMA的查询权限（需 DBA 配合）
执行 INVISIBLE 操作前必查三件事
否则容易卡在半路：
- 确认 MySQL 版本 ≥
8.0.23：SELECT VERSION();—— 低于此版本执行INVISIBLE语法直接报错ERROR 1064 - 确保表至少有一个可见列：
CREATE TABLE t (a INT INVISIBLE, b INT INVISIBLE)会失败，MySQL 要求必须留一个“门面” - 主键列不能设为不可见：
ALTER TABLE t MODIFY COLUMN id INT INVISIBLE;会报ERROR 3522 (HY000)，即使它是普通二级索引也不行
INVISIBLE 是个“临时胶带”，贴得住结构变更的裂缝，但封不住权限模型的漏洞。真正需要防护的数据，永远不该依赖“看不见”来实现。 
