MySQL中字典锁是什么？

面试记录 2026-10-13

题目：MySQL中字典锁是什么？

难度：low

标签：db/mysql/innodb, mysql/innodb, difficulty/low

评分：⭐⭐☆☆☆（2/5）

我的回答

字典锁主要是用来保证数据字典的一个线程安全，在访问数据字典的时候会进行加锁操作。

保证数据字典的一个安全，就是数据字典。数据字典是在内存里面，然后每次的访问的时候，都要加锁，就避免一个并发的一个访问导致的一些错误。

所以数据字典在表上操作的时候，要加锁。因为数据字典在表锁的时候，所以就是表上，所以加锁。

点评

优点：

• 抓到了核心用途：保证数据字典的线程安全
• 提到"在内存中"、"访问时加锁"，方向对

不足：

• 概念混淆：字典锁 ≠ 表锁。字典锁是 InnoDB 内部保护 data dictionary 结构的互斥锁，跟 SQL 层的 LOCK TABLES / 表级行锁无关。回答后半段"数据字典在表锁的时候"表述混乱
• 粒度没讲清楚：字典锁是 InnoDB 内部实现细节，是 mutex / rw_lock（C++ 层的轻量级锁），不是业务可见的锁。业务层根本感知不到，也控制不了
• 混淆 MDL（Metadata Lock）：很多人会把"字典锁"和 MySQL 8.0 的 MDL 搞混。MDL 是 Server 层保护表元信息的锁（SHOW OPEN TABLES 里能看到），DDL 与 DML 冲突时会拿 MDL 死锁等待；字典锁是 InnoDB 存储引擎内部的东西，两者完全不是一回事
• 未讲数据字典本身：MySQL 5.7 前数据字典存 .frm 文件，8.0 起存到数据字典表（mysql.* 系统表）里，并缓存在内存 data_dictionary 缓存中
• 未讲字典锁的作用对象：表元数据、索引元数据、页描述符、事务系统等关键 InnoDB 内存结构
• 未讲 8.0 的优化：字典锁做了大量 latching-free 改造，8.0 拆分了全局字典锁为更细粒度

补充：

• 数据字典锁（data dictionary lock）：InnoDB 内部 mutex，保护内存中 data dictionary 缓存的并发访问
• MDL（Metadata Lock）：Server 层锁，SELECT 拿共享 MDL，DDL 拿排他 MDL；长事务持 MDL 会阻塞后续 DDL（生产事故高发点）
• 两者层级完全不同：字典锁在存储引擎层（不可见、不可控），MDL 在 Server 层（可见，performance_schema.metadata_locks）
• 面试回答策略：如果面试官问"字典锁"，先明确是问 InnoDB 内部的还是 Server 层的 MDL，避免答偏

完整讲解

第一部分：知识重点剖析

核心考点定位：考察是否清楚 InnoDB 内部锁 vs MySQL Server 层锁的层级差异，避免混淆。

知识点拆解：

1. 数据字典（Data Dictionary）本身

• 内容：所有 schema / table / index / column / constraint 的元信息
• 存储位置演进：
• MySQL 5.6 及以前：.frm 文件 + .ibd + 部分在系统表
• MySQL 5.7：.frm 文件为主
• MySQL 8.0：全部迁到 mysql. 数据字典表（dd_），并加 data_dictionary 内存缓存
• 启动时 InnoDB 会把 dd 表读入内存的 data dictionary 缓存，运行时通过字典锁保护这个缓存

1. InnoDB 字典锁（data dictionary latch）

• 本质：InnoDB 内部的 mutex / rw-lock，C++ 实现，业务不可见
• 保护对象：表对象、索引对象、页描述符、事务系统、redo 相关的元数据结构
• 粒度演进：
• MySQL 5.7：粗粒度（一把大字典锁保护整个 dd cache）
• MySQL 8.0：细粒度拆分（表级、索引级、页级各一把），大幅降低争用
• 面试重点：这不是业务层需要关心的锁，也不会写进 SQL 语义

1. MDL（Metadata Lock）—— 常被混淆

• Server 层的元数据锁，performance_schema.metadata_locks 可见
• 规则：DML（SELECT/INSERT/UPDATE/DELETE）拿共享 MDL，DDL（ALTER/CREATE/DROP）拿排他 MDL
• 常见事故：长事务持共享 MDL 阻塞 DDL（ALTER TABLE 一直等）
• 排查：performance_schema.metadata_locks、information_schema.innodb_trx 找长事务
• 解决：metadata_locks_timeout 参数（8.0）、kill 长事务、DDL 用 ALGORITHM=INPLACE LOCK=NONE

1. 其他可能混淆的锁

• 表锁（Table Lock）：SQL 层的 LOCK TABLES，DML 显式锁，业务可见
• 意向锁（IS / IX）：InnoDB 的意向锁，表级，用于快速判断"这张表是否有行锁"
• Auto-inc Lock：InnoDB 自增锁，控制自增值分配，表级
• Adaptive Hash Index Lock：自适应哈希索引的锁，内部实现

1. 面试应对策略

• 先反问："您问的是 InnoDB 内部的 data dictionary lock，还是 Server 层的 MDL？"
• 如果指内部字典锁：讲保护对象、粒度、不可见
• 如果指 MDL：讲 Server 层规则、长事务阻塞 DDL 场景、参数调优

第二部分：考察方向与延伸递进

考察方向：

• 深度：能否说清字典锁是 InnoDB 内部实现细节，粒度演进如何
• 广度：能否区分字典锁 vs MDL vs 表锁 vs 意向锁
• 应用：能否说清 MDL 导致的长事务阻塞 DDL 事故如何排查

延伸递进面试题：

1. 长事务阻塞 DDL 怎么排查和解决？

• 解答要点：SELECT * FROM performance_schema.metadata_locks 看锁等待；innodb_trx 找长事务；metadata_locks_timeout 加超时；kill 长事务

1. InnoDB 8.0 数据字典做了哪些优化？

• 解答要点：从 .frm 迁到数据字典表，内存缓存 + 细粒度锁拆分，DDL 并发能力大幅提升

1. 意向锁和 MDL 的关系？

• 解答要点：意向锁是 InnoDB 行锁到表锁的"传递"标记（表上有行锁前先在表上打 IX），MDL 是元数据保护；两者层级不同

第三部分：面试者参考回答（口语化）

面试官您好，字典锁这个词其实要分两种理解，我先说清楚差异。

第一种是 InnoDB 内部的 data dictionary lock。这是存储引擎内部实现细节，本质是 C++ 层的 mutex 或 rw-lock，业务层完全感知不到，也控制不了。它保护的是内存中的 data dictionary 缓存——里面存着表元信息、索引元信息、页描述符、事务系统这些结构。MySQL 8.0 之前粒度比较粗，基本是一把大字典锁保护整个 dd cache；8.0 之后拆成了更细粒度的锁，比如表级、索引级、页级各自一把，并发争用大幅下降。这个字典锁面试里主要是讲清"它是内部实现，不是 SQL 语义"就够了。

第二种是常被混淆的 MDL（Metadata Lock）。这个是 MySQL Server 层的元数据锁，performance_schema.metadata_locks 里可见。规则是 DML 拿共享 MDL、DDL 拿排他 MDL。生产上最容易出的事故是——有个长事务持共享 MDL 没提交，后续想 ALTER TABLE 就会一直等，把整个库的连接池占满。排查就三步：先跑 SELECT FROM performance_schema.metadata_locks 看锁等待链，再跑 SELECT FROM information_schema.innodb_trx 找长事务，最后 kill 掉那个长事务。8.0 之后可以调 metadata_locks_timeout 加超时兜底，避免永久阻塞。

所以面试官如果问"字典锁"，我会先反问清一下具体指哪个。如果指 InnoDB 内部的，就讲保护对象和粒度演进；如果指 MDL，就重点讲长事务阻塞 DDL 的排查套路——这是我实际线上踩过最多次的坑。

---

面试记录 2026-10-13（第 2 次）

题目：MySQL中字典锁是什么？

难度：low

标签：db/mysql/innodb, mysql/innodb, difficulty/low

评分：⭐⭐⭐☆☆（3/5）

练习次数：2

我的回答

字典锁指的应该是 MySQL 数据库更新数据字典，比如它的索引、它的表结构、增减字段之类的操作。

当发生字典锁的时候，应该会锁整张表。如果是类似于结构的重建，应该会锁整张表。比如当我们加索引的时候，大表加索引会导致整张表无法进行正常的查询、插入等操作，这就是字典锁的一个体现。

所以线上尽量不可能，不要对大表进行 MDL 操作，不要更新它的表结构，不要加在峰值的时候加索引。要加的话，尽量选择平缓时段，业务量没那么大的时段，以及选择可以先建新表，再进行修改表名。然后进行更新的操作。

点评

优点：

• 抓到了真实业务场景：大表加索引锁表、DDL 影响线上——这是字典锁/MDL 类问题的最痛点
• 提出了正确的规避方案：错峰执行、新建表 + 改表名切换（ghost table 思路）
• 意识到风险：不要在峰值做结构变更
• 提到了 MDL 这个词，说明概念层面对"元数据锁"是有感知的

不足：

• 概念混淆严重：字典锁 ≠ MDL。用户把两者混为一谈——字典锁是 InnoDB 内部 mutex 保护 dd cache，MDL 才是 Server 层锁元信息（DDL 锁表的元凶）
• 对字典锁本身理解偏了：字典锁不是"变更表结构时锁整表"的锁，它是 InnoDB 内部实现细节，业务不可见。用户描述的"加索引锁整张表"实际是 MDL 排他锁 + ALTER 执行期间的表级排他，跟字典锁概念无关
• 未讲数据字典本身是什么：.frm / dd 表 / 内存缓存三阶段演进未提
• 未讲粒度演进：8.0 拆分字典锁为细粒度
• 规避方案不全面：没说 ALGORITHM=INPLACE LOCK=NONE（MySQL 5.6+ 支持）、pt-online-schema-change / gh-ost（大厂标配）、MySQL 8.0 的 Instant DDL
• 未讲排查工具：performance_schema.metadata_locks、information_schema.innodb_trx

补充：

• 用户描述的"大表加索引锁整张表"是 MDL 排他锁 + 老式 ALTER（COPY 算法） 的组合效果，字典锁本身是内部实现细节
• 大厂规避 DDL 锁表三大武器：
• ALGORITHM=INPLACE, LOCK=NONE（5.6+，多数 ALTER 支持）
• pt-online-schema-change（Percona Toolkit）
• gh-ost（GitHub 开源，Facebook 生产方案）
• MySQL 8.0 的 Instant DDL：加列、改列名、DEFAULT 值修改等操作亚秒级完成，不重建表
• MDL 排查：SELECT * FROM performance_schema.metadata_locks + innodb_trx 找长事务

ℹ️ 完整讲解见上方首次记录（2026-10-13）