MySQL 隐形索引对唯一索引和约束有什么限制

MySQL 隐形索引只改变优化器是否把某个索引列入执行计划，不会暂停索引维护，也不会让唯一性约束失效。真正需要小心的是：主键不能隐形；没有显式主键时，InnoDB 可能把 UNIQUE 且 NOT NULL 的索引当作隐式主键，这类索引也不能直接隐藏。生产排查应按“约束语义 → 隐式主键 → 列顺序与表达式 → 回表成本 → EXPLAIN”推进。

隐形索引隐藏的到底是哪一层

MySQL 8.4 的隐形索引仍然存在于表结构中，只是默认不参与优化器构造查询计划。可以用下面的例子创建一个候选索引，再通过 ALTER INDEX 切换可见性：

CREATE TABLE account_email (
  id BIGINT NOT NULL,
  tenant_id BIGINT NOT NULL,
  email VARCHAR(190) NOT NULL,
  PRIMARY KEY (id),
  UNIQUE KEY uq_tenant_email (tenant_id, email)
);

-- 只让优化器暂时忽略索引，不删除索引本体
ALTER TABLE account_email
  ALTER INDEX uq_tenant_email INVISIBLE;

-- 约束需要继续成立时，直接测试重复组合值
INSERT INTO account_email (id, tenant_id, email)
VALUES (2, 7, 'dev@example.com');

如果表中已经有 (7, 'dev@example.com')，最后一条插入仍会触发唯一键冲突。原因是索引可见性不影响索引维护：行发生变化时，索引仍会更新，唯一索引仍负责拒绝重复键。它影响的是查询侧的选择，而不是写入侧的约束。

唯一索引能隐藏，但主键语义有两道限制

普通二级索引可以隐藏，唯一索引通常也可以隐藏；但显式主键是例外。InnoDB 需要主键作为聚簇索引入口，因此下面的操作不会成功：

-- 这条语句会失败：PRIMARY KEY 不能变成隐形索引
ALTER TABLE account_email
  ALTER INDEX PRIMARY INVISIBLE;

还要检查一种容易漏掉的表结构：没有显式主键，但存在 UNIQUE 且所有索引列都是 NOT NULL。这类索引可能承担与主键相同的行约束，MySQL 会拒绝把它设为隐形索引。可以先补上真正的主键，再重新判断业务唯一索引是否适合隐藏：

CREATE TABLE device_key (
  device_code VARCHAR(64) NOT NULL,
  UNIQUE KEY uq_device_code (device_code)
) ENGINE = InnoDB;

-- uq_device_code 可能是隐式主键，不能直接隐藏
ALTER TABLE device_key
  ALTER INDEX uq_device_code INVISIBLE;

-- 先建立明确的聚簇主键，再评估业务唯一索引
ALTER TABLE device_key
  ADD COLUMN id BIGINT NOT NULL AUTO_INCREMENT PRIMARY KEY;

ALTER TABLE device_key
  ALTER INDEX uq_device_code INVISIBLE;

这里不是“加了主键就可以随便删约束”。uq_device_code 仍然负责业务唯一性，只是从优化器的候选集合里暂时退出。上线前必须确认应用仍依赖这条唯一约束，不能为了减少一个计划候选就删除索引。

复合唯一索引的列顺序不会因为隐藏而改变

UNIQUE (tenant_id, email)约束的是组合值，列顺序仍决定查询能否利用索引的前导部分。隐藏索引不会改变这个规则：如果查询只按 email过滤，优化器默认看不到该索引；即使临时允许使用隐形索引，也不能把后列当作前导列来理解。

函数表达式也要逐字核对。若索引建在 ((LOWER(email)))，查询应保持相同的表达式形状；把它改成另一种转换链，只凭“结果看起来相同”不能保证命中。返回列不全在索引中时，即使索引可用，仍可能根据主键值回到聚簇索引读取整行。

用元数据和 EXPLAIN 做灰度前检查

先确认索引当前状态，再比较隐藏前后的计划。默认情况下，优化器忽略隐形索引；只为单条测试语句打开 use_invisible_indexes，可以观察它是否仍有潜在价值：

-- 先看索引类型、列顺序和可见性
SELECT INDEX_NAME, SEQ_IN_INDEX, COLUMN_NAME, NON_UNIQUE, IS_VISIBLE
FROM INFORMATION_SCHEMA.STATISTICS
WHERE TABLE_SCHEMA = DATABASE()
  AND TABLE_NAME = 'account_email'
ORDER BY INDEX_NAME, SEQ_IN_INDEX;

-- 默认计划：隐藏索引不在候选范围内
EXPLAIN SELECT id
FROM account_email
WHERE tenant_id = 7 AND email = 'dev@example.com';

-- 只为本次计划比较打开隐藏索引
EXPLAIN SELECT /*+ SET_VAR(optimizer_switch='use_invisible_indexes=on') */ id
FROM account_email
WHERE tenant_id = 7 AND email = 'dev@example.com';

重点看实际选择的 key、访问类型、估算行数和是否需要额外读取。先做计划对比，再决定恢复可见、调整列顺序，或保留隐藏状态观察业务负载；不要因为 possible_keys 里出现名字就断言索引一定更快。

相关问题

隐形唯一索引还会阻止重复插入吗？

会。隐形只影响优化器是否选用索引，索引维护和唯一性检查仍然存在。

没有主键的 InnoDB 表为什么不能隐藏某个唯一索引？

如果它由 NOT NULL 唯一列组成，可能被当作隐式主键。先建立明确主键，再重新评估业务唯一索引。

打开 use_invisible_indexes 会让索引恢复可见吗？

不会。它只让优化器在构造当前计划时考虑隐形索引，索引本身仍保持隐形。