隐藏字段不影响DML执行逻辑但严格约束语法：INSERT必须显式列出INVISIBLE字段（即使有默认值），否则报错；UPDATE/DELETE可正常使用但SELECT *会遗漏，易致条件错误；CTE和索引需注意表达式确定性；ORM常忽略该字段，须手动验证。
隐藏字段（INVISIBLE column）本身不改变DML的执行逻辑，但会影响语句可读性、元数据兼容性和隐式行为——它不能“加速”DML，但写错会直接导致DML失败或逻辑错位。
INSERT时必须显式列出隐藏字段名
MySQL 8.0对INVISIBLE字段的约束很硬：只要字段设为INVISIBLE，INSERT INTO t VALUES (...)这种无列名的语法就**必然报错**，哪怕该字段有默认值或允许NULL。
-
INSERT INTO t VALUES (1, 'a')→ 报错ERROR 1136 (21S01): Column count doesn't match value count at row 1，因为隐藏字段不参与列计数但实际存在 - 正确写法必须显式指定字段：
INSERT INTO t (id, name, hidden_flag) VALUES (1, 'a', DEFAULT)或INSERT INTO t (id, name) VALUES (1, 'a')（前提是hidden_flag有DEFAULT且非NOT NULL） - 如果隐藏字段是
NOT NULL且无DEFAULT，那它就**必须出现在INSERT字段列表中**，否则语法拒绝
UPDATE/DELETE WHERE里能用隐藏字段，但别依赖SELECT *推导
隐藏字段可正常用于WHERE、SET和JOIN条件，MySQL引擎层完全识别它；问题出在开发习惯上——很多人靠SELECT *查结构再拼DML，而SELECT *会跳过INVISIBLE字段，导致WHERE条件漏写或写错列名。
-
UPDATE t SET status = 'done' WHERE hidden_flag = 1✅ 合法且高效（只要hidden_flag有索引） - 但若你从
SELECT * FROM t LIMIT 1结果里复制字段名去写UPDATE，hidden_flag根本不会出现，极易遗漏条件 - 检查隐藏字段是否存在：
SELECT COLUMN_NAME, EXTRA FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME = 't' AND IS_VISIBLE = 'NO'
CTE和功能索引中引用隐藏字段需额外注意确定性
隐藏字段可被CTE或功能索引引用，但MySQL对表达式的要求不变——尤其当字段本身是虚拟列（GENERATED）+ INVISIBLE组合时，容易触发ERROR 3752。
- 例如：
ALTER TABLE t ADD COLUMN calc_val INT AS (id * 2) STORED INVISIBLE→ 这个字段可用于WHERE calc_val > 10，但建功能索引INDEX idx_calc (calc_val)会失败，因MySQL认为calc_val是生成列，需显式声明为DETERMINISTIC（实际已满足，但解析器有时误判） - 安全做法：建索引时绕过字段名，直接写表达式：
INDEX idx_calc ((id * 2))，避免和INVISIBLE属性交互 - CTE中引用没问题：
WITH cte AS (SELECT id, hidden_flag FROM t) UPDATE t2 JOIN cte ON t2.id = cte.id SET t2.flag = cte.hidden_flag
最易被忽略的一点：ORM框架（如Hibernate、SQLAlchemy）通常通过DESCRIBE或INFORMATION_SCHEMA获取表结构，而多数版本默认忽略IS_VISIBLE = 'NO'字段，导致自动生成的INSERT/UPDATE语句直接缺失隐藏字段——上线前务必手动验证DML语句是否包含所有必需的INVISIBLE字段。
