MySQL invisible index 唯一索引设为不可见后约束还生效吗

会生效。MySQL 把唯一索引设为 INVISIBLE，默认只是不让优化器把它纳入执行计划；索引仍会随插入、更新一起维护，重复值仍会触发唯一键错误。真正需要区分的是三件事：查询计划是否看得到、写入约束是否继续检查、这个索引是否承担了隐式主键职责。

本文按 MySQL 8.4 的 InnoDB 语义说明验证方式。官方地址：https://dev.mysql.com/doc/refman/8.4/en/invisible-indexes.html

先把不可见索引和删除索引分开

给已有索引做性能回归时，可以先切换可见性，而不是直接 DROP INDEX。这样保留了索引结构和唯一性检查，查询侧则能观察“没有它参与选计划”时的变化。

-- 创建一张带唯一约束的示例表；email 是业务唯一键
CREATE TABLE account_demo (
    id BIGINT PRIMARY KEY,
    email VARCHAR(200) NOT NULL,
    UNIQUE KEY uk_account_email (email)
) ENGINE=InnoDB;

-- 只改变优化器可见性，不删除唯一索引
ALTER TABLE account_demo
    ALTER INDEX uk_account_email INVISIBLE;

-- 读取索引元数据，NO 表示对默认优化器不可见
SELECT INDEX_NAME, IS_VISIBLE
FROM INFORMATION_SCHEMA.STATISTICS
WHERE TABLE_SCHEMA = DATABASE()
  AND TABLE_NAME = 'account_demo'
  AND INDEX_NAME = 'uk_account_email';

这里的 IS_VISIBLE=NO 只描述索引对优化器的可见性。索引定义还在，写入路径仍需维护它，所以把这一步当成“暂时禁用查询使用”更准确，而不是“关闭约束”。

重复值测试能直接证明约束仍在

不要只看 EXPLAIN 就判断唯一索引失效。用一个已经存在的邮箱再插入一次，观察错误即可验证约束边界。

-- 先写入唯一值，建立后续重复测试的基准
INSERT INTO account_demo (id, email)
VALUES (1, 'alice@example.com');

-- 该写入应因 uk_account_email 拒绝；不要用 IGNORE 吞掉错误
INSERT INTO account_demo (id, email)
VALUES (2, 'alice@example.com');

预期结果是类似“Duplicate entry ... for key 'uk_account_email'”的唯一键冲突。若使用 INSERT IGNORE，MySQL 会改变错误处理方式，测试就不能再用“语句报错”作为观察标准；这不代表唯一约束消失。

需要对比计划时临时打开不可见索引

MySQL 8.4 默认关闭 optimizer_switch 中的 use_invisible_indexes。如果要确认该索引在计划层仍然可用，可以只对一条 EXPLAIN 使用 SET_VAR，不把全局配置改回去。

-- 只为本次计划构造临时纳入不可见索引
EXPLAIN SELECT /*+ SET_VAR(optimizer_switch = 'use_invisible_indexes=on') */
    id, email
FROM account_demo
WHERE email = 'alice@example.com';

-- 恢复可见性时使用同一索引名；这是可逆的 DDL
ALTER TABLE account_demo
    ALTER INDEX uk_account_email VISIBLE;

临时启用后，possible_keys 或 key 可能出现 uk_account_email，但是否真的选用仍由成本模型和数据分布决定。不要把“可以参与计划构造”理解为“每条查询都会使用”。

隐式主键是最容易漏掉的例外

假设表没有显式主键，且存在一个位于 NOT NULL 列上的唯一索引。InnoDB 可能把它当作有效的隐式主键，这时该索引不能直接设为不可见，MySQL 会报“primary key index cannot be invisible”。

-- j 既是 NOT NULL 又是唯一键；它可能承担隐式主键职责
CREATE TABLE implicit_pk_demo (
    i INT NOT NULL,
    j INT NOT NULL,
    UNIQUE KEY uk_j (j)
) ENGINE=InnoDB;

-- 这类场景可能失败，失败本身说明索引有表组织层职责
ALTER TABLE implicit_pk_demo ALTER INDEX uk_j INVISIBLE;

-- 先补显式主键，再重新评估 uk_j 是否只是普通唯一索引
ALTER TABLE implicit_pk_demo ADD PRIMARY KEY (i);

加上显式主键后，uk_j 不再承担隐式主键角色，才有机会作为普通唯一索引切换可见性。生产变更前应先检查表结构和外键关系，不要为了隐藏索引临时添加一个没有业务含义的主键。

上线前按三条线做检查

索引不可见适合做可逆的查询计划实验，但它不会省掉写入维护开销，也不会让约束变成可选项。上线前可以按下表判断：

不可见唯一索引会停止维护吗？

不会。MySQL 文档明确说明索引可见性不影响索引维护，唯一索引仍会检查重复值。

设为不可见后能用 FORCE INDEX 吗？

默认情况下，引用不可见索引的索引提示会报错；若只是临时比较计划，应优先使用 SET_VAR 打开 use_invisible_indexes。

为什么有的唯一索引不能隐藏？

没有显式主键时，NOT NULL 唯一索引可能承担隐式主键职责。先确认表的主键状态，再判断它是否是普通二级唯一索引。

结论可以压缩成一句话：INVISIBLE 改的是“优化器是否默认看见”，不是“唯一约束是否存在”。需要测试查询影响时隐藏，需要恢复计划时设回 VISIBLE；两步都应配合重复写入和表结构检查。