序章：DDL 与系统表 DML 那点儿不靠谱的事儿

没耳听。 先说个笑话：老板让你查 MySQL 的业务 DDL 对应哪几条系统表 DML， 后来啊你翻遍文档只看到一堆CREATE TABLEALTER TABLE心里暗暗叫苦——这到底是技术活儿还是心理游戏？

欧了！ 别急， 先给自己倒杯咖啡，主要原因是接下来要聊的东西会让你脑子嗡嗡响——“勾子”到底藏在哪儿？

一、 DDL 的本质：不是魔法，是一场“大搬家”

我怀疑... DDL其实就是在告诉 MySQL：“我要把数据库里的房子重新装修”。这套指令包括：

• CREATE DATABASE / TABLE / INDEX …
• ALTER … ADD COLUMN / DROP INDEX …
• DROP DATABASE / TABLE …

恕我直言... 每一次“搬家”，MySQL 都得在内部的系统表里动手。于是就出现了DML勾子——这些 INSERT/UPDATE/DELETE 语句悄悄替代了我们眼睛看不见的元数据更新。

二、系统表到底长啥样？

系统表名	核心字段	常见 DML 勾子
`mysql`.`tables`	`table_id`, `table_name`, `se_private_id`…	`INSERT`、 `UPDATE`、`DELETE`
`mysql`.`columns`	`column_id`, `column_name`, `se_private_data`…	`INSERT`、`UPDATE`、`DELETE`
`mysql`.`indexes`	`index_id`, `index_name`, `algorithm`…	`INSERT`、`UPDATE`、`DELETE`
`mysql`.`index_column_usage`	`index_id`, `column_id`, `ordinal_position`…	`INSERT/DELETE` 配对出现
`mysql`.`gtid_executed`	`source_uuid`, `interval_start`, `interval_end`…	`INSERT` 用来记录事务日志
……还有更多，你想不到的还有 innodb_dynamic_metadata、innodb_table_stats、innodb_index_stats …​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​...

三、DDL → 系统表 DML 的“隐形勾子”实战演示

下面用最随性的大白话解释几种常见情形：

CREATE TABLE 那点事儿 —— 插入 + 更新双管齐下！ 🎉🎉🎉

CREATE TABLE t_demo (
    id   BIGINT PRIMARY KEY,
    name VARCHAR NOT NULL
) ENGINE=InnoDB;
-- 背后发生：
INSERT INTO mysql.tables       VALUES ;
INSERT INTO mysql.columns      VALUES , ;
INSERT INTO mysql.indexes      VALUES ;
-- 甚至还有 innodb_table_stats、 innodb_index_stats 的 INSERT
-- 关键点：有时会出现 UPDATE tables SET se_private_id = X；主要原因是空间编号要递增

⚠️ 注意：如果你使用了 AUTO_INCREMENT = 1000 START WITH ... MySQL 会在 tablespaces/tablespace_files 表里多打一笔 INSERT，格局小了。。

ALTER TABLE ADD COLUMN —— 插入 + 删除 “戏码” 😱😱😱

ALTER TABLE t_demo ADD COLUMN age INT AFTER name;
-- 背后操作：
INSERT INTO mysql.columns  VALUES ;   -- 新增列记录
DELETE FROM mysql.columns WHERE column_id = old_placeholder; -- 删除旧占位符
UPDATE mysql.tables   SET se_private_data = ... WHERE table_id = …; -- 更新元数据
-- 如果是 INPLACE 算法， 还会触发 UPDATE innodb_dynamic_metadata
-- 如果是 INSTANT，则只做 INSERT + UPDATE，两步搞定

太水了。 其实你会发现，这里既有 INSERT，又有 DELETE，甚至 UPDATE 一边出现——这就是所谓的 “DML 勾子” 在玩 “先删后补”的戏码。

ALTER TABLE DROP INDEX —— 完全是 DELETE+INSERT 的组合 🤔🤔🤔

ALTER TABLE t_demo DROP INDEX idx_name;
-- 背后细节：
DELETE FROM mysql.indexes           WHERE index_name='idx_name';
DELETE FROM mysql.index_column_usage WHERE index_id=??;
INSERT INTO mysql.indexes            VALUES ; -- 为了保持自增 ID 连续性
UPDATE mysql.tables                SET se_private_id=...;          -- 元数据刷新
-- 还有啊， 还会写入 innodb_index_stats 的 DELETE/INSERT 行记录统计信息变化

别忘了如果你用了 COPY ALGORITHM=INPLACE;MySQL 会把旧索引标记为 “deleted”，接着再创建新索引行——这就像把旧家具搬到仓库，再买新的同款摆进去。

TRUNCATE TABLE —— 其实吧是 DROP+CREATE 的混合体 🚀🚀🚀

TRUNCATE TABLE t_demo;
-- 背后步骤：
DELETE FROM mysql.tables           WHERE table_name='t_demo';
DELETE FROM mysql.columns          WHERE table_id=...;
INSERT INTO mysql.tables            VALUES ;
INSERT INTO mysql.columns           VALUES ;
-- 再配合 innodb_table_stats、 innodb_index_stats 全部重置为零或重新插入默认值
-- 注意：GTID 信息也会写一次 INSERT 到 gtid_executed 表里以防复制冲突

四、从 GDB 与 ibd2sql 看“勾子”实战日志

以下内容摘自作者折腾 MySQL‑8.0.x 时留下的残破日志，带点“噪音”，请自行过滤掉不想看的部分。 break ha_innobase::write_row // 捕获 INSERT 操作的入口点。 哭笑不得。 break ha_innobase::update_row // 捕获 UPDATE 操作的入口点。

# 小结：DDL 并非单纯写 binlog，而是通过底层 Storage Engine 把业务需求映射成对 data dictionary 表的一系列 DML 操作。 *以上日志仅供学习参考，实际环境请勿直接复制粘贴！

break ha_innobase::delete_row // 捕获 DELETE 操作的入口点。 # 施行 ALTER ... ADD COLUMN 后看到：    Breakpoint 3, ha_innobase::write_row    Breakpoint 1, ha_innobase::update_row    Breakpoint 2, ha_innobase::delete_row # 用 ibd2sql 把 InnoDB 页面的变更导出成 SQL，看见大量 INSERT INTO `mysql`.`columns``……和 DELETE FROM `mysql`.`columns``……交错出现。

五、为什么说这些“勾子”很重要？ 👀👀👀

1️⃣ 审计追踪：如果公司要求审计每一次 schema 改动，只看 binlog 是不够的。必须追溯 我天... 到 data dictionary 表中的 INSERT/UPDATE/DELETE 才能完整还原。

归根结底。 2️⃣ PITR： PITR 时恢复到某个时间点， 需要一边回滚业务 DDL 与对应的数据字典 DML，否则恢复出来的结构会“不匹配”。这也是为何官方文档强调“不要直接用 mysqldump 恢复 schema”。🌈🌈🌈

3️⃣ Troubleshooting：Killer 场景——某次 ALTER 卡死，却找不到错误日志。打开 data dictionary 表， 吃瓜。 你会看到有残留的 “deleted but not purged” 行，这正是排查卡顿根源所在。

六、 玩转勾子的几个小技巧 🎲🎲🎲

• #1 用 INFORMATION_SCHEMA.SYSTEM_TABLES 查看最新状态： 

  SELECT * FROM information_schema.system_tables WHERE table_schema='mysql' AND table_name='tables'; 
  /* 看 se_private_id 是否递增 */
  

• #2 用 SELECT * FROM performance_schema.events_statements_history_long 检查最近施行过哪些 write_row/update_row/delete_row： 

  SELECT sql_text FROM performance_schema.events_statements_history_long 
  WHERE sql_text LIKE '%write_row%' ORDER BY event_id DESC LIMIT 10;
  

• #3 手工模拟一个“虚假”DDL： 

  BEGIN;
  INSERT INTO mysql.tables  VALUES ;
  COMMIT;   /* 这样生成一条孤立的数据字典记录，可用于测试监控工具 */
  

• #4 快速定位被标记为 deleted 的行： 

  SELECT * FROM mysql.columns WHERE column_name='' AND se_private_data IS NULL;
  

• #5 利用 pt-table-sync 同步 data dictionary：  

  pt-table-sync --execute --sync-to-master h=master,u=root,p=passwd,D=mysql,t=tables;
  # 小心，它会直接对系统表做 UPDATE/DELETE，请务必做好备份。
  

.

七、 产品推荐小插曲 —— 数据库监控神器大比拼 📊📊📊

完整平安审计+性能诊断 预算充足的大企业 Zabbix MySQL 模块 开源老牌监控工具 基本指标报警+历史趋势分析 Datadog MySQL Integration 云原生 SaaS 服务 一键部署+自动化仪表盘 

# 排名	产品名称	核心功能	适用场景
1️⃣	Percona Monitoring and Management PMM	实时查询慢日志 + InnoDB 引擎内部指标	中大型生产集群
2️⃣ Grafana + Loki + Promeus 组合方案 Metrics 可视化+日志聚合 K8s 环境下多租户监控
3️⃣ MySQL Enterprise Monitor Oracle 官方版
4️⃣	中小企业 & 初创团队
5️⃣	云上弹性伸缩环境
*以上排名仅供娱乐，不构成任何商业推荐*

八、别再盯着那层纸面上的 CREATE 而忽略背后的血肉！ 🩸🩸🩸

来日方长。 如果你现在还能把 DDL 当成“一键完成”的魔术，那就说明你还没真正打开 MySQL 内部那扇通往 system dictionary 的门。每一次业务需求背后 都隐藏着一串 INSERT/UPDATE/DELETE 勾子，它们默默地在数据字典里跳舞——有时温柔，有时凶猛，有时甚至偷偷留下废弃行，让你的磁盘空间悄然膨胀。

没法说。 所以下次当 DBA 老大喊：“快给我检查一下刚才那个 ALTER 为什么卡住！” 请先去看一下 `mysql`.`columns``\``tables``\``indexes``\``gtid_executed`\``innodb_*_stats 等系统表里的最新 INSERT/UPDATE/DELETE 行，而不是只盯着 binlog 或错误日志。只有这样，你才能真正做到“一眼洞悉 schema 演进全貌”。🚀🚀🚀 本文约 2507+ 字， 纯属个人碎碎念，若有冒犯请留言交流。祝大家玩转 MySQL 勾子无痛升级 🚧💥💥💥 © 原创 不易，请尊重作者劳动成果。