1. 建表前的关键选择：字段类型、字符集和主键

你可能觉得“建表”是 MySQL 最没技术含量的一件事，一个CREATE TABLE语句几分钟就写完了。但我在项目里反复见过一个规律：绝大多数后面对表的改动、性能排查、突发故障，根子都在建表那一步埋下了。字段类型定得随意，字符集选得顺手，主键没有认真设计，等到表里数据过千万再来调整，代价就不是改几行 DDL 那么简单了。

这篇文章会从建表、改表、删表、维护四个维度把 MySQL 表的相关操作完整过一遍。重点不是把手册里的语法抄一遍，而是把每一步背后的取舍讲清楚：为什么要选这个类型、为什么主键要自增、为什么一条 ALTER 要合并执行、什么时候 TRUNCATE 比 DELETE 更合适。里面的例子基本来自真实业务，不一定高深，但都是常见的坑。

1.1 字段类型决定业务天花板

字段类型的“天花板效应”是最容易被忽略的。以自增主键为例，很多表用INT UNSIGNED，上限是 42 亿左右，看着很大。但一旦业务异常增长，或者曾经批量导入过海量数据，ID 消耗速度会远超预期。我遇到过一张流水表用了INT，上线两年多就逼近上限，最后只能在大半夜做变更，把主键改成BIGINT。整张表几亿行，重构时间长到让值班同事怀疑人生。

整数字段有两个容易踩的点：

• INT和BIGINT的存储空间差异不大，但能容纳的量级完全不同。INT4 字节，BIGINT8 字节。对于可能长期增长的主键、流水号、外部系统 ID，直接给BIGINT反而是省事的选择。
• 负数值是否用得到。如果业务上 ID、数量、金额都不可能为负，定义成UNSIGNED能扩展一倍上限，但同时也要小心减法运算的结果类型问题，以及应用端 ORM 是否支持无符号大整数。有些语言对超过2^63-1的数值处理不好，反而会埋雷。

字符串类型同样要克制。VARCHAR(255)和VARCHAR(500)在 InnoDB 里并不一定多占磁盘，但行大小和索引长度是实打实的。索引列的长度越长，一个数据页里能放的索引条目越少，查询性能和写入性能都会跟着下降。更关键的是，VARCHAR超过一定长度后，在联合索引里很容易触碰索引长度上限，尤其在使用utf8mb4字符集时，一个字符最多占 4 字节，索引前缀长度很容易超限。

数值和时间的精度也不能含糊。金额字段千万不要用FLOAT或DOUBLE，浮点数在二进制表示下天然存在精度误差，账算不平是迟早的事。应该用DECIMAL，并且明确精度，比如DECIMAL(12,2)。时间字段要区分DATETIME和TIMESTAMP：前者存储范围大，跟时区无关，存的是什么就是什么；后者有 2038 年问题，并且会随数据库时区设置自动转换。如果在做全球化业务，时间字段的存取方式要在前期就定清楚。

1.2 字符集排序规则选错之后的连锁反应

字符集问题在建表时最容易“顺手选错”。早年很多系统默认用latin1或utf8，后来要存 emoji，才发现utf8根本存不了 4 字节字符，必须改成utf8mb4。麻烦在于字符集不是想改就能改的，存量数据迁移时，除了ALTER TABLE ... CONVERT TO CHARACTER SET，还要处理索引长度变化、旧数据乱码、连接层字符集不一致等问题。一次字符集变更，往往比预期复杂得多。

我在实际项目里总结了一条经验：新库新表一律用utf8mb4，排序规则用utf8mb4_0900_ai_ci（MySQL 8.0）或utf8mb4_general_ci（MySQL 5.7 之前更常见）。排序规则决定了字符串比较和排序的规则，_ai_ci表示不区分重音、不区分大小写。如果业务要求区分大小写，就要改用utf8mb4_bin或对应的大小写敏感规则。选错排序规则后，最典型的表现是：

• 唯一索引出现“不该重复的数据”，因为a和A被当成同一个值。
• 字符串排序结果跟业务预期不一致，例如本应区分大小写的用户名，查询时却匹配到了不同记录。

还要注意关联查询时的字符集一致性。两张表字段类型一样，字符集不同，连接时 MySQL 往往无法直接使用索引，会出现Using filesort或Using join buffer。最坑的是这种性能问题在数据量小的时候完全感觉不到，等数据量大了才发现关联查询越来越慢。排查手段是SHOW CREATE TABLE看表定义，以及EXPLAIN看执行计划。建议所有表结构保持统一字符集，字段有特殊情况也要尽量收敛在个别列上，而不是每张表各用各的。

1.3 主键设计能省掉未来大多数麻烦

InnoDB 是聚簇索引组织表，数据行本身按照主键顺序物理存储。主键的选择直接决定写入顺序、页分裂频率和二级索引的体积。很多人觉得“随便找一个业务字段当主键”就可以，比如用户表的手机号、订单表的订单号。这在小规模数据上没毛病，但数据量上来之后，会有几个明显问题：

• 业务字段变更频繁。手机号换绑、订单号重算，这些业务逻辑一旦动到主键，代价极高。
• 业务字段长度不可控。字符串主键会让聚簇索引变大，所有二级索引都会额外携带主键，放大索引体积。
• 无序主键导致随机写入。最典型的是UUID主键，插入时数据页频繁分裂，页空间利用率下降，磁盘碎片增多，写入并发高时还会引发大量页合并和缓冲池竞争。

比较稳妥的方案是自增主键，或采用分布式环境下的有序 ID（雪花算法、号段模式）。自增主键写入顺序基本是递增的，新数据追加在数据页尾部，页分裂概率低。这里不是否认业务唯一键的存在，而是把“物理主键”和“业务唯一键”分开：物理主键只管行定位与存储顺序，业务唯一键通过唯一索引来保证。

主键类型同样影响全文索引。二级索引叶子节点存的是主键值，主键越大，每个二级索引条目就越大，同样大小的内存缓存能覆盖的索引范围就越小。主键用BIGINT UNSIGNED可以，但没必要把主键设计成超大字符串。我曾经见过一张表用VARCHAR(64)的流水号做主键，二级索引建了三个，表总空间比同业务量级的自增主键表多出将近 40%，查询缓存命中率也明显偏低。这就是典型的建表决策在数月后才被“追债”的案例。

2. CREATE TABLE 实操：先把表建得规范再谈优化

建表语句看起来简单，实际写法和默认习惯里藏着不少门道。下面用一张业务表为例，讲一讲我日常会怎么设计，以及每个关键点背后的理由。先看建表语句，再拆开解释。

2.1 一张能直接抄的建表模板

CREATE TABLE IF NOT EXISTS `order_record` ( `id` BIGINT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '主键ID', `order_no` VARCHAR(40) NOT NULL COMMENT '业务订单号', `user_id` BIGINT UNSIGNED NOT NULL COMMENT '用户ID', `amount` DECIMAL(12, 2) NOT NULL DEFAULT 0.00 COMMENT '订单金额', `status` TINYINT NOT NULL DEFAULT 0 COMMENT '状态：0待支付 1已支付 2已取消', `created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', `updated_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间', PRIMARY KEY (`id`), UNIQUE KEY `uk_order_no` (`order_no`), KEY `idx_user_id` (`user_id`), KEY `idx_created_at` (`created_at`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci COMMENT='订单记录表';

几点说明：

• id用BIGINT UNSIGNED，不是为了炫技，是避免上线几年后为扩容主键做一次折磨人的大表变更。
• order_no加唯一索引。业务订单号的唯一性由索引保证，物理主键反而用无关的自增 ID，两者互不干扰。
• amount用DECIMAL，关键场景直接避免浮点误差。
• status用TINYINT，而不是VARCHAR或INT。状态这种东西可能就十几个值，TINYINT占 1 字节，理由充分。
• 每张表都带上created_at和updated_at，用DEFAULT CURRENT_TIMESTAMP和ON UPDATE CURRENT_TIMESTAMP自动维护。这个习惯在排查数据问题时非常有用，否则很难判断一条记录是什么时候写入、什么时候修改的。
• 索引只建真正会被查询条件用到的列。给user_id建普通索引是为了按用户查订单，给created_at建索引是为了按时间范围统计。索引不是越多越好，后面会展开说。

2.2 表注释和字段注释必须写到位

几乎所有团队里都有过这样的场景：接手一张老表，字段名叫a、b、c，唯一看懂的方式是去翻一段早就没人维护的文档。写注释这个习惯成本最低，收益却非常高。MySQL 支持表注释和字段注释，在CREATE TABLE里写COMMENT就可以。

后端通过information_schema.columns可以直接读取所有字段注释，很多自动生成接口文档、数据字典的工具都依赖这个机制。如果你的表结构里注释写清楚了，接手的同事能省下大量沟通时间。我个人的要求是：每个字段都要写注释，枚举类型在注释里直接标出取值含义，例如状态：0待支付 1已支付 2已取消。复杂逻辑字段哪怕多写两句也不要紧。

查看列注释的 SQL 也很常用：

SELECT TABLE_NAME, COLUMN_NAME, COLUMN_TYPE, COLUMN_COMMENT FROM information_schema.COLUMNS WHERE TABLE_SCHEMA = 'your_db' AND TABLE_NAME = 'order_record' ORDER BY ORDINAL_POSITION;

这个查询在做数据字典、做表结构评审时都很有用。顺便提一句，建表时应该同时把ENGINE=InnoDBCHARSET=utf8mb4写全，不要依赖数据库默认值。默认值会随着服务器版本、参数配置变化，写明确才能保证不同环境行为一致。很多人建表时漏掉COLLATE，结果不同表的排序规则不一致，后续 JOIN 时又得花时间排查。

2.3 AUTO_INCREMENT 的几个理解误区

自增主键用得多，理解误区也多。先说第一条：AUTO_INCREMENT列必须是索引列，而且通常作为主键。有同事为了“节省主键空间”，用自增列做普通索引，业务字段做主键，结果在 InnoDB 里数据行还是按业务主键排序，自增列不过是一个额外的唯一标识，反而浪费索引空间。

再说计数规则。AUTO_INCREMENT的值在 MySQL 8.0 之前是内存里维护的，实例重启后可能根据当前最大 ID 重新计算，这会导致某些场景下 ID 重用或被跳过。MySQL 8.0 开始把自增值持久化到 redo log，重启后不再重置。对大多数业务来说 ID 是否被跳过不重要，但如果要做数据对账、外部系统同步，就要理解自增不是严格连续的。

第三个误区是“先查当前最大值再加 1”来模拟自增。这在并发环境下一定会出事，两个事务同时读到相同最大值，然后一起插入，要么撞唯一键，要么产生重复业务数据。自增主键就交给数据库维护，应用层不要去计算下一个 ID。

还有一个批量插入的细节：INSERT大量行时，如果指定了 ID 值，会影响后续自增计数。曾经出现过一次数据导入，脚本里带了很大的 ID，再正常插入新记录时，自增 ID 突然跳了几百万。这不算 bug，但容易让对账业务误以为数据缺失或异常，所以在导入脚本里尽量明确是否要保留原 ID。

3. ALTER TABLE 改表：从基础语法到在线 DDL

线上环境跑了一段时间，改表是不可避免的。字段长度不够要加，状态值不够要改，索引要补。相比建表，改表的风险大得多，尤其是大表。ALTER TABLE 在 MySQL 里做起来看似简单，但不同操作的底层处理方式完全不同。

3.1 平时最常用的列变更操作

列级操作是 ALTER 里最频繁的，我整理成一张表：

改列长度是需求最频繁的。比如VARCHAR(20)不够存改到VARCHAR(50)，看起来很简单，实际执行方式和数据量、行格式、字段位置都有关系。MySQL 8.0 对某些列扩展可以秒级完成，但有些场景仍然需要重建表。判断的办法是看EXPLAIN或在变更前查一下官方手册对在线 DDL 的支持矩阵，不能想当然。

CHANGE COLUMN重命名的坑在于它必须重写整个列定义。很多人只改了列名，忽略了原有类型、nullable、默认值，写完一执行，列类型悄悄变了。比如原列是INT NOT NULL DEFAULT 0，写CHANGE COLUMN a b INT，默认值就丢了，null 属性也可能变化。所以在任何CHANGE COLUMN之前，先SHOW CREATE TABLE把原始定义完整复制过来，只改需要改的部分。

3.2 为什么要把多个变更合并成一条 ALTER

很多人在给表加多个字段时，会分多次执行 ALTER：

ALTER TABLE t ADD COLUMN col1 INT; ALTER TABLE t ADD COLUMN col2 VARCHAR(10); ALTER TABLE t ADD INDEX idx_col3 (col3);

这样写不是不能跑，但在大表上就是灾难。每次 ALTER 都可能重建表、扫全表，连续三次就等于把同样的表重建了三遍，不仅耗时长，还会产生大量磁盘 IO 和复制延迟。合并成一条要安全得多：

ALTER TABLE t ADD COLUMN col1 INT NOT NULL DEFAULT 0, ADD COLUMN col2 VARCHAR(10) NOT NULL DEFAULT '', ADD INDEX idx_col3 (col3);

MySQL 会尽量尝试在一次表重建中完成多个变更，至少能减少扫描次数。另一个附带的好处是：如果表启用了在线 DDL，合并操作有机会一次获得更短的锁时间。需要说明的是，MySQL 8.0 的ALGORITHM=INSTANT支持即时添加部分列，这种能力是有限制的，不是所有列都能INSTANT添加，比如在列中间插入、使用某些类型时就不支持。所以合并变更要提前判断算法，实在不确定就在低峰期执行。

3.3 大表改动的两个工具思路

线上大表直接跑ALTER TABLE ADD COLUMN，在小库上没什么问题，几百万行可能几秒钟就完成了。但当表到几个亿、单表几百 GB，且主库写入压力不低时，原生 ALTER 的锁和复制延迟就不容小视。虽然 InnoDB 的在线 DDL 已经很强，加索引、加列在某些条件下能做到LOCK=NONE，但仍有不少 DDL 需要LOCK=SHARED，意味着会阻塞写入；即便LOCK=NONE，全表扫描带来的 IO 压力也容易拖垮从库。

这个场景下，我一般会评估两个工具思路：

• pt-online-schema-change：通过创建一张影子表，把原表数据先拷贝过去，再用触发器同步增量数据，最后原表与影子表原子切换。它支持在操作过程中继续读写原表。
• gh-ost：不依赖触发器，而是利用 MySQL binlog 同步增量数据，对主库侵入更小，但对 binlog 格式有要求，需要ROW模式。

用这类工具不是为了炫技，而是把 ALTER 从“一个阻塞操作”转变为“一个可监控、可限速、可中断的异步任务”。业务允许在凌晨操作时，原生 ALTER 往往也够用；业务 7x24 小时在线时，工具化变更更稳妥。我在实际运维里还做过一个折中方案：按时间分批的数据归档后，先把大表降为小表，再跑普通 ALTER，比直接用工具更快。表改动方案没有银弹，核心是评估扫描成本、锁时长、复制延迟和业务可容忍窗口。

4. 索引与外键：决定查询快慢和写入代价的表结构

索引不是表结构里的装饰品，它是影响查询性能和写入性能的直接因素。表设计没做好，后续加索引也只是打补丁。这里挑三个经常出现争议的点展开：回表与覆盖索引、重复数据补唯一索引、外键约束该不该用。

4.1 辅助索引回表，覆盖索引怎么用

InnoDB 的主键是聚簇索引，数据行直接挂在主键 B+ 树的叶子上。其他索引统称辅助索引，辅助索引的叶子节点存储的是索引列值和主键值。所以通过辅助索引查数据，实际上分两步：先在辅助索引里找到对应的主键，再用主键到聚簇索引里取整行数据。第二步就叫“回表”。

回表不是坏事，它是 InnoDB 的基本机制。问题在于回表次数太多时，随机 IO 会明显拖慢查询。比如一张几千万行的表，WHERE条件只用到辅助索引，但SELECT需要回表读取大字段，一次查询回表几万行，性能就很难看。

覆盖索引的意思是“辅助索引本身已经包含查询需要的所有字段”，这样优化器发现不需要回表，直接扫辅助索引就能返回结果。判断方法是用EXPLAIN看Extra列：

EXPLAIN SELECT user_id, status FROM order_record WHERE user_id = 10086;

如果Extra里有Using index，说明走了覆盖索引，不用回表。如果<user_id, status>建了联合索引，而查询只需要user_id和status，就不用回表。这就是很多业务里“索引列不要随意加前缀”的原因：覆盖索引能省掉海量随机 IO。

我见过一个极端反例：有人为了覆盖所有查询，把十几个字段全塞进一个索引。后果是索引变得又宽又大，写入放大严重，实际命中率很低。覆盖索引要针对高频 SQL 来设计，一条廉价的统计查询偶尔回表没问题，一条每秒跑几十次的接口查询才值得优化。

4.2 有重复数据时怎么补唯一索引

开发过程中经常出现这种情况：数据已经跑出重复了，现在想在字段上加唯一索引，结果一执行就报Duplicate entry。这个坑的典型场景是用户手机号、业务单号。直接加索引是不可能的，必须先把存量数据清理干净。

标准排查步骤大致是这样：

第一步，找出重复数据，并观察重复程度：

SELECT mobile, COUNT(*) AS cnt FROM user_account GROUP BY mobile HAVING COUNT(*) > 1 ORDER BY cnt DESC LIMIT 20;

第二步，根据业务规则确定保留哪一条。比较稳妥的做法是保留id最小、created_at最早的那条，把其余记录标记为失效或迁入历史表，而不是直接删。删数据之前一定要备份。

第三步，对历史数据做处理，确认剩余数据唯一后，再创建唯一索引：

ALTER TABLE user_account ADD UNIQUE KEY uk_mobile (mobile);

如果表非常大，这个 ALTER 仍然要走在线 DDL 流程。唯一索引创建期间，如果还有并发写入引入新的重复值，同样会失败。所以业务写入逻辑里同时要有兜底：要么应用层加锁，要么入库前用前置查询校验，不能把唯一性完全押在一次 ALTER 上。真正稳定的方案是把唯一约束建在表结构上，并在数据入口处做幂等控制。

4.3 外键约束该不该加

外键在 MySQL 里是个争议话题。从约束语义上说，外键能保证子表数据的引用完整性，避免“订单引用了不存在的用户”这种脏数据。问题主要体现在性能和扩展性上：

• 每次插入、更新子表时，InnoDB 需要检查父表的对应记录，会多一次S锁操作，高并发写入场景下会增加锁竞争。
• 删除父表记录时，如果外键带ON DELETE CASCADE，MySQL 会逐行联动删除子表，数据量大时锁范围可能迅速扩张，引发死锁。
• 做分库分表、异构数据同步时，外键基本无法跨数据库生效，反而可能让迁移和同步逻辑变得复杂。

我的习惯是：核心业务里更倾向于“逻辑外键”，也就是父表、子表各自有索引，但不建立物理外键约束。用应用层事务或定时对账来保证数据一致性，把性能隐患留给业务自己控制。手册中总有说“不能用外键所以表设计不完整的观点”，但实际经历过线上死锁后，优先级判断还是会改变。外键不是完全不用，而是只在数据变更频率低、一致性要求极高的场景使用，比如配置表、权限表的简单关联。

如果已经决定要建立物理外键，必须保证关联列的类型和字符集完全一致，否则 MySQL 会报错。外键对应的父表列需要有索引，否则创建时也会失败。删除外键的语法是ALTER TABLE child DROP FOREIGN KEY fk_name，注意外键名不看列名，要看约束名，用SHOW CREATE TABLE查清楚再删。

5. 清空、删除和重命名：这几个操作最好在低峰期做

删除类操作的口诀永远是：先在测试环境试一遍，导出备份，再动线上。别嫌啰嗦，我见过太多因为少了个WHERE条件导致全表清空的故事。下面把DROP TABLE、TRUNCATE TABLE、DELETE FROM和RENAME TABLE放在一起讲，因为它们经常被搞混，都可能造成不可逆的影响。

5.1 DROP、TRUNCATE、DELETE 到底有哪些不同

三条语句都带“删”的意思，行为差异很大：

实际运维中，清空一张临时表用TRUNCATE是合理的；删掉一张废弃表用DROP；线上业务表中删除部分数据，必须用DELETE ... WHERE ...，并且要在低峰期限流执行，避免锁太多行拖垮主库。

DELETE大量数据时还有一个容易忽略的点：如果表没有针对性的分批策略，一次性删除几十万行，事务里的 undo log 会膨胀，主库 IO 和 binlog 都会出现明显的压力，从库也可能因为同步延迟报警。分页删除是个常见做法：

DELETE FROM order_record WHERE created_at < '2023-01-01' LIMIT 1000;

这条语句在 MySQL 里不能直接循环执行太多遍，因为LIMIT的删除没有固定游标，重复执行时需要拿到新一批主键。更稳的方式是先用SELECT取主键列表，再按主键范围分片删除，每次删除后加一个停顿或限速。总之，删除不是越快越好，平滑比速度重要。

5.2 RENAME 的原子性与连锁影响

RENAME TABLE在 MySQL 里是一个原子操作，执行过程中其他会话不会看到表“不存在”的中间状态。这个特性很有用，比如在做表结构切换时，经典的“影子表切换”就会用到：

RENAME TABLE order_record TO order_record_old, order_record_new TO order_record;

两条重命名放在同一条语句里，可以保证切换过程对应用无感。这比先DROP TABLE再RENAME安全得多，因为后者存在一个窗口期，应用正好访问到不存在的表就直接报错了。

但 RENAME 也有连锁影响。如果表上有外键，而且外键是按表名关联的，重命名后外键关系可能失效或需要级联更新。MySQL 的RENAME TABLE在有外键约束时，会自动更新引用该表的外键定义，但行为有时候并不直观，仍然建议在变更前把所有外键关系查出来，确认影响范围再操作。

日常开发里还有同事用RENAME来实现“还原上一版本表”，比如把备份表快速换回正式名。这种方式速度确实快，但要注意：RENAME 只是换了名字，底层数据文件没有变化。如果正式表已经在运行，而备份表的数据是几小时前的，切换之后这段时间的新增数据就不可见了。用 RENAME 做回滚之前，必须确认清楚数据快照的边界。

5.3 误操作后的补救路径

把这条放在最后，不是让大家期待误操作后能恢复，而是希望所有人都知道“最坏情况发生后下一步该干什么”。线上误删数据的恢复路径，通常取决于备份策略，而不是数据库本身。

如果配置了全量备份加 binlog，恢复思路大概是：用最近一次全量备份恢复到临时实例，再用 binlog 把时间点推进到误操作之前，最终把数据导出，再导回正式库。这个流程听着不复杂，实际操作时对 binlog 格式、位点解析、临时实例规格都有要求。MySQL 8.0 的 binlog 默认 ROW 格式，配合mysqlbinlog工具可以解析出具体的事务和受影响的行。解析出来的内容最好先核对——有次我们恢复时发现误删除的是一个带级联操作的存储过程，binlog 里并不是一条 DELETE 那么简单。

比恢复更重要的，是平时的逃生通道：

• 核心业务表开启binlog，确保binlog_format=ROW，这样方便精细恢复。
• 关键表定期全量备份，并且验证过备份可用。备份不代表恢复没问题，没有演练过的备份只是心理安慰。
• 涉及大表结构变更前，先留一个变更前的SHOW CREATE TABLE和必要的数据快照。
• 删除类操作在事务里执行时多留一个心眼：DELETE至少还能ROLLBACK，但DROP TABLE和TRUNCATE TABLE执行瞬间就不再受事务保护了。

我用过的最朴素也最有效的习惯是：线上执行的破坏性 SQL，永远先复制到文本文件里，写清楚执行人、执行时间、原因，执行前再读一遍。操作越危险，流程越冗长越安全。与其指望事故后的神仙操作，不如把容错前置到操作习惯中。

6. 表维护记录：统计信息、碎片和一致性检查

表建好了，日常也会改，但很多人忽略了对表本身的周期性维护。这个维护不是“没事 OPTIMIZE 一下”，而是一套有节制的健康管理。数据量、写入模式、索引更新频率都会影响表状态，维护工作也应当有节奏。

6.1 ANALYZE TABLE 什么时候必须跑

MySQL 的优化器依赖统计信息来选择执行计划，包括行数、基数、索引分布。统计数据不是实时更新的，更新频繁的表有可能让统计信息严重偏离实际，导致优化器选错索引。典型症状是：原来跑得很快的查询，某天突然变慢，EXPLAIN一看，key列变成了 PRIMARY，而实际应该走辅助索引。

ANALYZE TABLE就是重新统计表的关键信息。执行后会更新information_schema.statistics等统计表，帮助优化器做更合理的判断。它和OPTIMIZE TABLE不一样，不需要重建表，开销小很多，可以相对频繁地执行。大表在数据量发生明显变化之后，比如一次批量导入、大量历史数据删除后，都值得跑一次。

查询一张表当前统计信息可以用：

SHOW INDEX FROM order_record;

重点关注Cardinality列，它反映索引值的区分度。如果某个索引基数远小于行数，说明这个索引比较“瘦”，优化器可能不会选它。如果某个高频查询实际没走你应该它走的索引，通常就是因为统计信息过于陈旧。注意ANALYZE TABLE在 MySQL 8.0 下执行时也可能影响复制和缓冲池，所以依然建议避开高峰期。

6.2 碎片整理没有你想的那么简单

InnoDB 表的碎片主要来自频繁的删除、更新和随机插入。删除并不会立刻把物理空间归还给操作系统，而是在页内留下可复用的空洞。长期下来，表空间可能比实际数据大不少，扫描全表时 IO 量也会增加。

OPTIMIZE TABLE是常见整理方法，它会重建表，把数据重新排列，回收碎片空间，并更新统计信息。但重建表意味着全表拷贝，大表上做一次会把磁盘 IO 打满，还可能造成主从延迟。不要因为“感觉表碎片多”就贸然执行，应该先用实际指标判断：

• information_schema.tables的DATA_FREE字段可以看到空闲空间。
• 对比DATA_LENGTH和实际数据文件的规模。
• 观察全表扫描的耗时是否明显随写入删除增长。

如果碎片确实严重，优先考虑在低峰期操作。如果表太大，使用pt-online-schema-change一类的工具做无锁重建会更安全。还有一点：频繁创建、删除临时表也会让整个库的表空间元数据膨胀，这种问题就不是单表 OPTIMIZE 能解决的，需要结合存储引擎和表空间方案来整体规划。

6.3 CHECK TABLE 与日常巡检

CHECK TABLE是用来检查表结构和数据页是否损坏的命令。正常情况下不需要频繁执行，因为 InnoDB 有 checksum 机制，崩溃恢复时也会做页校验。但在硬件故障、异常断电、存储层异常之后，CHECK TABLE能给出较明确的反馈。示例：

CHECK TABLE order_record;

返回结果里Msg_type如果出现error，基本可以确认表页损坏。这时如果还有备份，最稳妥的做法是恢复到临时实例，导出数据再重建表，而不是在原地REPAIR TABLE硬修。REPAIR TABLE对 MyISAM 有实际意义，但 InnoDB 场景下通常不建议依赖它，因为复杂索引结构修复容易产生不一致。

日常巡检里最推荐的其实是一组轻量 SQL：看每张表的行数、数据大小、索引大小、最近更新时间、自增值剩余空间。这些信息通过information_schema.tables就能取到。表越多，越需要一套自动化脚本定时记录，而不是等到故障发生了才去翻库。我自己的习惯是每周跑一次巡检，输出一份表空间增长趋势和碎片变化清单，并重点观察那些大表是否因为频繁删除产生明显空间黑洞。这套流程不复杂，但能提前暴露很多问题。

到这里，整个 MySQL 表的操作链路算是比较完整了。从建表时的字段选择、字符集和主键设计，到 ALTER 的在线 DDL 和工具化变更，再到索引、外键、删除维护和巡检，每一步都对应着线上真实的代价和收益。如果只记住一句话，那就是表结构的一切设计都要为未来的数据规模和运维操作留出余地，宁可前期多想一分钟，不要后期熬夜改表到凌晨三点。