要上进的柯同学做后端或者运维的同学应该都有过这种经历：项目跑了大半年，业务方说要给订单表加个“是否加急”的标记，你顺手敲了一行 ALTER TABLE，结果一张百万行的表把主库拖得够呛；或者是某张表要加唯一约束，一执行才发现里面早就攒了几千条重复数据；再或者 WHERE 条件里明明用了索引字段，EXPLAIN 出来还是 ALL。这些问题的表现五花八门，但根子基本都集中在一个地方——MySQL 数据表管理没做到位。
这里说的数据表管理，不是只写一句 CREATE TABLE 那么简单。它包含字段选型、字符集规则、表结构变更策略、日常数据操作方式、InnoDB 物理存储细节，以及线上排障思路。今天我就把自己在这些环节里踩过的坑、总结出的经验写出来，面向的是那些会自己维护 MySQL、又没到专职 DBA 程度的开发者，内容尽量做到拿过去就能用。
1. 字段设计：类型选错，后面补多少 ALTER 都费劲
1.1 int(5) 不是长度限制，主键别随意用 int
网上搜“mysql 中 int+5”相关的问题，其实大部分是在问 int(5) 的写法。刚带项目时我也遇到新同学把 id int(5) 理解成“只能存 5 位整数”，甚至有业务需求说“用户 ID 最长可能 8 位，int 得写成 int(8)”。这个认知是错的。
int(5) 里的括号数字不是存储长度，也没有限制取值范围。int(5) 和 int(11) 在磁盘上都是 4 字节，取值范围完全相同，有符号版从 -2147483648 到 2147483647，无符号版从 0 到 4294967295。括号里的数字叫“显示宽度”，只影响某些客户端展示结果，而且主要是在配合 ZEROFILL 时用来补零，视觉效果大于实际意义。在 MySQL 8.0 里，整数类型的显示宽度本身也已经不建议继续使用，所以新表不要再用 int(5) 这种写法去卡宽度。
选型时真正要想清楚的是 int、bigint、tinyint 三者的边界。用户 ID、订单 ID 这类核心业务主键，我现在的默认选择基本都是 bigint unsigned，而不是常见的 int。原因很现实：只要业务存在跨表同步、分库分表、数据归档，或者某天接口被刷量导致 ID 消耗异常，int 的 21 亿上限并非遥不可及。核心表一次性把主键定成 bigint，比以后做一次主键类型升级要省心太多。状态位这类字段则用 tinyint 就够了，不要习惯性给每个小字段都上 int，一个 int 占 4 字节，一张千万行的大宽表里，宽度完全是被这些细节拖起来的。
1.2 金额、时间、状态字段该怎么落
金额字段最大的忌讳是用 float 或 double。很多人写 Demo 时用 float 很顺手，但金额在业务里要求精确，浮点数本身有精度误差，累计计算后会出现“多一分少一分”的问题。正确做法是使用 DECIMAL，比如 DECIMAL(10,2) 表示最大能存 99999999.99，对于常见的交易场景是够用的；如果涉及汇率、积分等需要更多小数位的场景，可以用 DECIMAL(20,4)，具体位数取决于业务要求，而不是照抄某篇文章的参数。
时间字段上，datetime 和 timestamp 的使用经常被搞混。简单区分：
timestamp存储的是 UTC 时间，查询时根据数据库会话时区转换成当地时区，4 字节存储，但有 2038 年的上限问题。datetime不依赖时区，存什么就显示什么，8 字节存储，范围大得多。
我建议多数业务表直接用 datetime(3)，毫秒精度对很多日志和流程记录都有价值，避免后面要增加毫秒时再改表。同时要求建表语句里带 DEFAULT CURRENT_TIMESTAMP(3)，更新时间字段加上 ON UPDATE CURRENT_TIMESTAMP(3)，让数据库自己维护创建和更新时间，应用层不需要额外填。状态字段用 tinyint，通过注释维护每个值的含义，不要图省事用 enum，因为 enum 后续要加枚举值是 DDL 操作，表锁风险和兼容性问题都不少，而 tinyint 加状态只需要应用层放行新数字。
1.3 字符集和排序规则：大小写、去重、排序全被它牵着走
数据表管理里最容易被忽略但又影响最深的就是字符集与排序规则。MySQL 里 utf8 这个名称实际是 utf8mb3，最多只支持 3 字节字符，存不了 emoji，也跟不上现在的文本需求。新建表统一使用 utf8mb4，不要再用 utf8，这点已经是老生常谈，但老库老表仍然会踩。
真正隐蔽的是排序规则 collation。同一个字段，排序规则不同，会直接影响去重、唯一约束、排序结果。最常见的 utf8mb4_0900_ai_ci 含义是：ai 表示不区分重音，ci 表示不区分大小写。也就是说，在默认排序规则下，MySQL、mysql、MYsql 会被 MySQL 视为同一个值。如果业务上要求邮箱、用户名这类字段区分大小写，或者允许两个只差大小写的值同时存在，那唯一索引就会成为第一个受害者，后续 ORDER BY 的结果也会和开发预期对不上。
这种约束往往是建表之前就要定清楚的。一旦表和线上数据都跑起来了，要单独把一个字段改成大小写敏感的排序规则，代价可能比迁移数据还要高，因为涉及全表扫描和重建索引。所以每次建表我都会写清楚 CHARSET=utf8mb4 COLLATE=utf8mb4_bin 或者 utf8mb4_0900_as_cs，而不是依赖默认值。注意 _bin 更“硬”，按二进制比较，_as_cs 是重音敏感加大小写敏感，二者语义有区别，业务允许时优先考虑更精确的规则。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 建表和 DDL：生产环境的表结构变更不能硬来
2.1 一张能被长期维护的表，建表语句长什么样
我经常在代码评审里看到核心业务表的建表语句只有几行，主键、索引、注释全是空的。字段名、类型、注释、默认值、索引设计、字符集这几项如果一开始不写清楚，后面连维护的人都会被迫靠猜。
分享一个相对完整的示例：
sql复制CREATE TABLE `orders` (
`id` bigint unsigned NOT NULL AUTO_INCREMENT COMMENT '自增主键',
`order_no` varchar(32) NOT NULL COMMENT '业务单号',
`user_id` bigint unsigned NOT NULL COMMENT '用户ID',
`status` tinyint NOT NULL DEFAULT '0' COMMENT '1待支付 2已支付 3已取消 4已完成',
`amount` decimal(10,2) NOT NULL DEFAULT '0.00' COMMENT '支付金额',
`channel` varchar(16) NOT NULL DEFAULT '' COMMENT '支付渠道',
`created_at` datetime(3) NOT NULL DEFAULT CURRENT_TIMESTAMP(3) COMMENT '创建时间',
`updated_at` datetime(3) NOT NULL DEFAULT CURRENT_TIMESTAMP(3) ON UPDATE CURRENT_TIMESTAMP(3) COMMENT '更新时间',
PRIMARY KEY (`id`),
UNIQUE KEY `uk_order_no` (`order_no`),
KEY `idx_user_id_status` (`user_id`, `status`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci COMMENT='订单主表';
这张表里有几个点值得说：
- 能定位一行数据的业务字段，比如订单号，要单独建立唯一索引，同时这通常也是对外查询和幂等判断的依据。
- 不要让每个字段都能
NULL。NULL在索引中的处理、聚合计算、WHERE判断上和空字符串不是一回事。实在没有值就给默认值，比如字符串给空串、数字给 0。NULL字段很容易造成COUNT(列)统计结果和业务理解对不上，也容易让NOT IN、!=这些判断出现反直觉的结果。 - 联合索引的字段顺序不要随便排。
(user_id, status)意味着它能服务“查某个用户的所有订单”和“查某个用户某种状态订单”两类场景，但如果查询条件经常只带status，这个联合索引就帮不上忙。设计联合索引时要看实际查询里等值条件的出场频率，而不是简单把“看起来重要的字段”放前面。
2.2 ALTER TABLE 的锁行为：大表不能拍脑袋
不少人对 DDL 的认知还停留在“不就加个字段吗”。实际上 MySQL 各个版本对 DDL 的处理并不一样，MySQL 8.0 之前和之后的差异非常明显。但有一点是共通的：一张大表上执行 DDL，不只是执行那一瞬间的事，它会复制数据、重建索引、在从库上回放，任何一步都可能变成生产事故。
MySQL 支持在 ALTER TABLE 里显式指定算法和锁级别，例如：
sql复制ALTER TABLE `orders`
ADD COLUMN `is_urgent` tinyint NOT NULL DEFAULT '0' COMMENT '是否加急',
ALGORITHM=INPLACE,
LOCK=NONE;
ALGORITHM=INPLACE 表示尽量不复制整表数据，LOCK=NONE 表示尽量不阻塞线上读写。但要注意：不是所有 DDL 都支持这种模式。加字段、加索引通常可以做到 INPLACE, LOCK=NONE，但修改列类型、把 varchar(50) 改成大字段这类操作，很多情况下仍然需要 COPY，也就是重建表。如果数据库不支持执行计划里要求的算法，MySQL 会直接报错，而不是默默阻塞，这其实是好事，至少比线上卡死强。
我个人对大表 DDL 的执行原则是：
- 先看表的行数和占用空间，再用
ALTER TABLE ... ALGORITHM=INPLACE, LOCK=NONE试跑，如果报不支持，就再评估是否接受短时间阻塞。 - 对超过千万行、或者 QPS 很高的核心表，不要在业务高峰直接跑 DDL，优先使用
pt-osc、gh-ost这类在线变更工具，通过创建临时表、追增量、切换表名来做，避免长时间锁写。 - 即使支持在线 DDL，大表变更也会在主库上产生额外负载，并在从库上形成延迟。变更前确认好从库延迟水位，变更后检查复制状态。
这个领域最容易踩的坑是“很小的一张表，加了 LOCK=NONE 之后以为万事大吉”，但如果数据库老版本不支持，或者当前连接已经有一个长事务占着元数据锁，ALTER TABLE 会一直等下去。所以执行前先看 SHOW PROCESSLIST，确认没有长期未提交事务。
2.3 已经有一堆重复数据时，怎么把唯一约束加上
想在已有重复数据的表上加唯一索引，MySQL 会直接拒绝：Duplicate entry 'xxx' for key 'uk_xxx'。此时需要先清理重复数据，再加约束。
先看重复范围：
sql复制SELECT user_id, COUNT(*) AS cnt
FROM t_user
GROUP BY user_id
HAVING cnt > 1;
确认重复记录后，一般保留每组里 id 最小的一条，删除其余重复：
sql复制DELETE t1
FROM t_user t1
JOIN t_user t2
ON t1.user_id = t2.user_id
AND t1.id > t2.id;
执行之前一定要先做好备份，最好是在测试环境用相同脚本跑一遍，确认影响行数符合预期，再在低峰期操作。如果表很大，建议把删除条件拆成按主键范围分批执行，避免一次删除过多数据造成锁范围扩大和主从延迟。
清理干净后，再执行：
sql复制ALTER TABLE `t_user`
ADD UNIQUE KEY `uk_user_id` (`user_id`);
另一个经常被忽略的细节是“逻辑删除”。如果表里有 deleted 标记，逻辑上删除了的用户仍然占着手机号或邮箱值，你希望能重新注册同一个手机号，此时直接对 mobile 加唯一约束，怎么都会失败。实际做法通常是：
- 删除旧数据后再加约束；
- 或者把唯一键设计成包含删除标记的组合；
- 或者在插入新数据时同步把旧逻辑删除记录的手机号置空或加后缀，再依赖唯一约束。
这不是数据库本身的问题，而是唯一约束和业务生命周期设计之间的冲突，越早想清楚越好。
2.4 ER 图能帮你理结构，但不能代替检查清单
很多同学用 MySQL Workbench 的反向工程功能导出表结构 ER 图，确实方便，能够一眼看到表和表的关联关系。导出方法不复杂：连接数据库后选择 Database -> Reverse Engineer，选定要导出的 schema，之后 Workbench 会根据外键关系或者一些命名规则自动连线。
但实际项目里，ER 图的价值往往被高估了：
- 如果建表时没有真正定义外键约束，Workbench 生成的关系连线很可能就是错的，甚至完全没有连线。大量互联网项目为了写入性能和分库分表，根本不建物理外键，图里自然没有关系。
- ER 图展示的是“有哪些表、有哪些列、是否为空、是否有索引”，但它不会告诉你某个
varchar(50)为什么是 50，不会告诉你为什么user_id和status上有联合索引，也不会告诉你字符集大小写敏感为什么如此重要。
我的建议是，把 ER 图当成一种交流工具，但真正检查表结构时，还是要回到 SHOW CREATE TABLE 和 information_schema 的信息上核对。设计评审时，看到图里一个索引名或注释缺失，可能当下看不出什么，等上线后出问题才意识到当初的表结构描述并不完整。
3. 表内数据操作：去重、排序、批量更新不能凭直觉
3.1 INSERT 冲突策略要看业务语义
数据表管理不只是在建表和变更表结构，日常写入同样影响表的使用寿命。最典型的是插入冲突处理，很多逻辑用 INSERT IGNORE 或者 REPLACE INTO 能在语法上通过，但语义差别很大：
INSERT IGNORE：遇到唯一键冲突就忽略新数据，已存在的行保持不变。REPLACE INTO：遇到主键或唯一键冲突时，先删除旧行，再插入新行。这会导致id没变但行数据被整体替换，还会触发额外删除和插入操作。INSERT ... ON DUPLICATE KEY UPDATE：冲突时只更新指定列，适合做幂等的“存在就更新，不存在就插入”场景。
从表管理的角度，我不建议在核心流水表上用 REPLACE INTO。这个操作不是简单的“覆盖”，它会先 DELETE 再 INSERT，如果表上有很多二级索引，重建成本比一次 UPDATE 高得多。而且一旦表结构里有 ON UPDATE CURRENT_TIMESTAMP，一个看似应该“原值不变”的记录也可能被更新时间戳，让数据审计变得奇怪。
另外要注意自增主键在高并发写入下出现间隙或跳跃是正常现象，不要试图用“插入失败回滚后自增 ID 必须连续”的思维去约束 MySQL。事务回滚、INSERT IGNORE 被忽略都会消耗自增 ID，追求连续 ID 只会自找麻烦。
3.2 DISTINCT 不等于业务去重
如果面试官问“MySQL 的 OR 能去重吗”，这个问题本身就很怪，因为去重和 OR 没有直接关系。开发中更常见的是 SELECT DISTINCT user_id FROM order_table 这种写法。DISTINCT 的语义是“查询返回的所有列组合不重复”，一旦 SELECT 后面跟着多列，它去重的最小单位就是“多列的组合”，而不是业务上关心的某个键。
例如：
sql复制SELECT DISTINCT user_id, channel
FROM orders;
这个查询返回的是每个用户在每个渠道下的组合记录。即使同一个用户在同一渠道下有多张订单，只会出现一次；但同一个用户如果出现过两个渠道，就会返回到两行。如果你的目标是“统计到底有多少个下单用户”，这个结果就是错的，正确写法应该是：
sql复制SELECT user_id, COUNT(*)
FROM orders
GROUP BY user_id;
去重之前要先回答“业务上的唯一键是什么”，然后决定是用 DISTINCT、GROUP BY 还是窗口函数 ROW_NUMBER()。数据表管理里最常见的一句话是“明明加了 DISTINCT 为什么还有重复”，实际查一下就知道，重复的是其他列，根本不是你以为要按它去重的那个字段。
3.3 ORDER BY 结果不总是你预想的那样
排序看起来最简单，实际上有不少跟表结构绑定的坑。
第一个坑是字符集排序规则导致的大小写问题。如果表字段使用 _ci 排序规则，ORDER BY name 出来的结果会把大小写不敏感地排在一起，A 和 a 的相对顺序取决于具体排序规则，可能不符合“先大写后小写”的预期。真要按二进制大小写顺序排，可以显式指定：
sql复制ORDER BY name COLLATE utf8mb4_bin;
第二个坑是“字符串类型的数字”排序。varchar 字段存了“1、2、10、9”，按字典排序得到的是“1、10、2、9”，不是数值顺序。如果这种字段确实要参与数值排序，要么建表时就选对类型，要么查询时转换：
sql复制ORDER BY CAST(order_num AS UNSIGNED);
但请注意，对索引字段做 CAST 或函数计算会导致该查询无法走索引，属于典型的“让数据库帮你算”的代价。正确做法优先是：字段设计阶段就直接用整数类型存数字，而不是用字符串。
第三是排序导致的临时文件问题。ORDER BY 结果如果无法从索引直接获得，MySQL 会做 filesort，数据量大时还会使用磁盘临时文件。通过 EXPLAIN 能看到 Extra 列，如果大表经常出现这种排序，就要考虑是否能用索引天然有序，或者是否要在应用层做缓存排序，而不是一味让 MySQL 硬扛。
3.4 大批量 UPDATE/DELETE 如何避免锁表
很多人写过类似下面的 SQL：
sql复制DELETE FROM archive_log WHERE created_at < '2023-01-01';
如果这个表有 2 亿行，其中 1 亿行都要删除，执行时会被拆成大量行锁和日志记录，不仅主库压力巨大，从库回放也可能长时间追不上。这不是“删除数据”本身的问题，而是操作粒度的问题。
通用做法是按主键范围分批处理：
sql复制DELETE FROM archive_log
WHERE id BETWEEN 1 AND 10000
AND created_at < '2023-01-01';
也可以写成一次删除 5000 条，然后观察主从延迟和负载再继续下一批。用脚本循环处理时，建议每批都让 created_at < '2023-01-01' 条件继续保留，目的是防止上一批删完，下一批的“起点”因为表数据变化产生重复或遗漏。
UPDATE 也一样。一次性更新全表某个状态，示例是：
sql复制UPDATE t_user SET status = 2 WHERE status = 1;
如果 status 上没有合适的索引，MySQL 会扫描大量行，每一行都加锁。访问量大时，读请求会被阻塞，业务方反馈就是“表锁住了”。虽然 InnoDB 默认是行锁，但更新条件没有索引的前提下，行锁可能直接退化为全表大量加锁，效果上跟表锁差不多。这一点是排查线上 Waiting for lock 和慢事务时需要首先怀疑的地方。
4. 行格式、碎片与统计信息：数据表的物理世界
4.1 InnoDB 表的数据到底是怎么排的
做数据表管理，如果不理解 InnoDB 的物理存储特点，很多优化都是键盘上打转。
InnoDB 是索引组织表，简单说就是数据按照主键顺序物理存储。主键索引的叶子节点保存的就是整行数据，所以通过主键查询通常最快；二级索引的叶子节点保存的是索引列加主键值，查到后再回主键索引拿整行，这个过程叫回表。
这个结构带来的实际结论：
- 每张 InnoDB 表都应该有主键。如果没有显式主键，InnoDB 会找第一个非空唯一索引作为主键；再找不到，就会生成一个隐藏的 6 字节
ROW_ID。这个隐藏主键对复制、数据归档、分页都不是好事，因为应用层根本感知不到它。 - 主键不要用太长的随机字符串，比如 UUID。主键越长，二级索引存的主键值也越长，整张表的所有索引都会被撑大。随机值插入还容易造成页分裂，写入性能差。这也是为什么很多业务表宁愿用自增
bigint或雪花 ID，而不是 UUID。
行格式方面，MySQL 8.0 默认是 DYNAMIC。当一行数据特别长，或者某个字段是很大文本时，InnoDB 会把部分数据放到溢出页，行内只保留 20 字节左右的指针。理解这一点，能解释为什么 TEXT、BLOB 字段不适合频繁更新，也解释了为什么“大字段太多”会显著拉高每张表的页读取成本。
4.2 碎片与 OPTIMIZE TABLE 的正确打开方式
长期有大量 DELETE 和 UPDATE 的表，数据和索引页会产生空洞，就像一本经常撕页的书，页数没少但真正有用的内容排列稀疏。通过 information_schema 可以查到表的大致物理状态：
sql复制SELECT table_name,
data_length,
index_length,
data_free
FROM information_schema.tables
WHERE table_schema = 'your_db'
ORDER BY data_free DESC;
data_free 代表该表当前有一定量的空闲空间，数值越大说明碎片越明显。但注意这只是一个参考，InnoDB 会复用空闲页，不一定立刻需要处理。
真正确认需要整理碎片时，常用方式包括：
sql复制OPTIMIZE TABLE your_table;
或者：
sql复制ALTER TABLE your_table ENGINE = InnoDB;
两种方式本质都会重建表，会拷贝数据并重建索引，因此必须在业务低峰期执行。大表执行前还要确保磁盘剩余空间足够，因为重建过程中需要额外空间。如果你的表本身归属于读写分离架构，重建大表还可能让复制延迟变得很明显。
我的实践是：不要定期无脑对所有表执行 OPTIMIZE TABLE。一般只在删除大量过期数据后做一次评估，而且优先在从库或非高峰期做，做完再切换流量。对于还在频繁写入的新表，少量碎片完全可以交给 InnoDB 后台慢慢复用，动不动重建大表才是不专业的表现。
4.3 统计信息不准，执行计划就会跑偏
MySQL 优化器选择执行计划时，依赖的是表里索引的统计信息，而不是精确去数表里有多少行。统计信息如果不准，最常见的后果是：明明某个字段有索引，但优化器认为“全表扫描比走索引更便宜”，于是走了 ALL，线上慢查询随之而来。
统计数据来自采样。删除大量数据或者数据量突然暴增后，表中实际分布已经变化，旧的统计信息还没更新，就可能让优化器做出错误判断。这时手动执行一次：
sql复制ANALYZE TABLE your_table;
可以刷新统计信息。ANALYZE TABLE 本身需要获取表的读锁，对于超大表也不是完全无感，但仍然比一次错误的慢查询灾难性强得多。
在 MySQL 8.0 中，有几个参数会影响到统计信息的采样精度，比如：
sql复制SHOW GLOBAL VARIABLES LIKE 'innodb_stats_persistent_sample_pages';
这个值默认 20，如果表数据分布很不均匀，比如某个值占了 80%，20 页采样得到的分布可能不够准确，可以考虑在特定场景加大采样页数。但要注意，采样页数越大，收集统计信息所需的时间也越长，需要平衡。
很多开发觉得 EXPLAIN 没走索引就是 SQL 写得不对，其实也有可能是统计信息没刷新。遇到这种问题，先查统计信息，再考虑改造 SQL，思路才完整。
5. 线上排障案例：为什么索引没用、为什么卡住、为什么唯一键会漏
5.1 一条不带引号的 SQL，可能是慢查询元凶
有一类很典型的“数据表管理”问题，是字段类型和查询条件不一致导致的隐式转换。
假设 orders 表的 order_no 是 varchar(32)，也有唯一索引 uk_order_no。查询时如果有人写：
sql复制SELECT * FROM orders WHERE order_no = 202501010001;
这里 order_no 是字符串，等号右边是整数，MySQL 会把列的值转换成数字再比较，相当于对索引列做了隐藏的函数操作，索引自然失效。EXPLAIN 结果里 type 会变成 ALL，rows 会接近整表记录数。
修复方式很简单：
sql复制SELECT * FROM orders WHERE order_no = '202501010001';
不要觉得这是低级错误。现实中很多后端框架的查询对象，会把前端传的字符串参数自动转成数字，或者某个接口历史遗留就是传 number，排查时往往要检查很久才能定位。EXPLAIN 里的 key 一列如果显示为 NULL，同时 Extra 出现 Using where，就要警惕是否存在隐式转换。
MySQL 8.0.18 之后可以高效使用 EXPLAIN ANALYZE，它会真实执行 SQL 并输出每步耗时，排障比看纯 EXPLAIN 更直观。遇到“看起来该走索引却没有走”的情况，先用它把实际执行路径打出来。
5.2 锁等待到底是谁造成的，别只靠猜
线上偶尔会收到“Lock wait timeout exceeded”的告警，很多人的第一反应是去杀掉当前出错的会话，但如果没有找到持锁事务，问题马上会复发。
InnoDB 行锁等待的真实原因，通常是某个事务拿着行锁但迟迟没有提交，另一个事务想更新同一行只能等待。排查持锁事务的核心语句：
sql复制SELECT * FROM information_schema.innodb_trx;
这个视图会列出当前还没结束的事务，包含事务开始时间、执行状态、等待锁的 SQL。如果发现某个事务 trx_started 已经很久，而且 trx_state 是 RUNNING，那么它很可能就是拖垮别人的源头。再结合：
sql复制SELECT * FROM sys.schema_table_lock_waits;
SHOW ENGINE INNODB STATUS;
可以定位到具体表和锁等待关系。另外也别忘了先看一眼 SHOW PROCESSLIST，排查长时间 Waiting for table metadata lock 的会话。这种元数据锁通常不是行锁，而是一条长查询或者没提交的事务堵住了 DDL，比如 ALTER TABLE 一直卡在准备阶段。
定位之后，措施通常是两类：
- 对已经跑了几十分钟的只读查询或空闲事务，和应用方确认后
KILL对应线程； - 对批量更新导致的锁覆盖范围过大，改成按主键分批更新，并把持锁事务的提交时间控制在很短范围内。
“锁表”这个词在 InnoDB 里多数时候并不准确，背后其实是“你在没有索引的条件下更新数据，导致大量行被锁”。只要把更新条件改到索引上，锁定范围自然就缩下来了。
5.3 唯一约束里藏着 NULL，重复数据会绕过去
线上另一个让我印象深刻的例子是“明明加了唯一索引，却还是出现了多条相同数据的记录”。查到最后，问题出在 NULL 上。
MySQL 唯一索引有一个和多数人直觉不同的规则：多个 NULL 是允许同时存在的。也就是说，一张表 email 字段上有 UNIQUE KEY，你可以在同一张表里插入以下两条记录：
sql复制INSERT INTO t_user (email) VALUES (NULL);
INSERT INTO t_user (email) VALUES (NULL);
它们不会触发唯一约束冲突。这在数据库语义里是合规的，但很多业务并不希望这样。比如“未填写邮箱的账号只允许注册一个”，那 NULL 就不是合适的设计。
解决这类问题的方案通常有两种：
- 如果业务上真的要求“空值只能出现一次”，那么不要用
NULL表示空，而是给一个业务空串或某个固定占位值，不过占位值本身也会占用唯一性语义，会有一定的建模味道；更稳妥的是单独加一张“已激活账号”表，用email做唯一键，只保存有邮箱的账号。 - 如果业务上“没有邮箱的账号允许有多个”，那
NULL反而是天然支持这个规则的，不需要额外处理。
这个案例给数据表管理带来的经验是：加唯一索引之前，要想清楚这个字段的业务空值长什么样，NULL 能否出现多次。不要以为数据库报了 Duplicate entry 就一定拦住所有重复，空值是一个永远绕不开的边界。
我在实际项目里习惯把这一类边界直接写进字段注释。比如：
sql复制`email` varchar(64) DEFAULT NULL COMMENT '邮箱，未填写时允许 NULL，多账号可为 NULL'
这样后面接手的同事不需要靠猜来理解这一列的行为。数据表管理做到最后，其实拼的就是对字段语义、边界情况和数据库底层机制的共同理解。每次线上排障回来，我都会把这些“为什么当初没拦住”的问题沉淀成建表规范，逼着自己在创建下一张表时多想一层。