INVISIBLE索引对触发器完全无影响，触发器不感知索引可见性；仅当触发器内部显式含SELECT语句时，其执行计划才受INVISIBLE索引限制，默认不使用，需USE INDEX或调整optimizer_switch方可强制使用。
INVISIBLE 索引对 MySQL 8.0 的触发器**完全无影响**——触发器不感知索引可见性，也不会因索引设为 INVISIBLE 而改变行为。
触发器执行时只依赖表结构、字段值、SQL 语句逻辑和事务上下文，它不参与查询优化、不调用优化器、不生成执行计划。所以无论索引是 VISIBLE 还是 INVISIBLE，只要 DML（INSERT/UPDATE/DELETE）能正常执行，触发器就照常触发。
触发器会不会走 INVISIBLE 索引？
不会，也不需要“走”。触发器本身不执行 SELECT，不选索引；它只是响应 DML 事件后执行预定义逻辑。但要注意：如果触发器体内部写了 SELECT 语句（比如在 BEFORE INSERT 中查老数据做校验），那这些内部查询会受 INVISIBLE 索引影响——和普通查询一样，默认不使用，除非加 USE INDEX 或改 optimizer_switch。
为什么 ALTER TABLE ... ALTER INDEX INVISIBLE 不会影响触发器？
-
ALTER TABLE ... ALTER INDEX idx_name INVISIBLE只修改INFORMATION_SCHEMA.STATISTICS中的IS_VISIBLE字段，是纯元数据变更，不重建表、不锁表、不触发表扫描 - 触发器定义存储在
INFORMATION_SCHEMA.TRIGGERS，与索引元数据物理隔离 - MySQL 在触发器执行阶段不检查索引可见性，也不缓存“哪些索引可用”这类信息
常见误判场景：触发器变慢，怀疑是 INVISIBLE 索引导致
这种归因基本是错的。真正可能相关的点只有：
- 触发器里显式用了
SELECT ... FROM t USE INDEX(idx_name)，而该索引已被设为INVISIBLE→ 此时会报错：ERROR 1176 (42000): Key 'idx_name' doesn't exist in table 't' - 触发器内查询原本依赖某个索引加速，你把它设为
INVISIBLE后没加提示，导致该查询全表扫描 → 表现为触发器延迟升高，但根源是查询本身，不是触发器机制 - 你误把写入变慢归给触发器：其实
INVISIBLE索引仍会随 INSERT/UPDATE/DELETE 实时更新，写性能损耗照旧 —— 触发器只是背锅了
测试时最容易忽略的一点
想验证触发器内某查询是否真走了某个 INVISIBLE 索引，不能只看外部 EXPLAIN；必须在触发器 SQL 体内加 EXPLAIN FORMAT=JSON 或用 SELECT ... INTO @var + SHOW PROFILE 捕获其内部执行计划——因为触发器上下文里的优化器行为，和客户端直连执行并不完全等价，尤其涉及临时表或事务隔离级别时。
