MySQL DDL实战指南：从建表设计到线上变更避坑

前阵子有个后端朋友跟我吐槽，说系统上线三个月之后慢查询越来越多，好几条SQL明明看着能走索引，可执行计划里还是在扫全表。我让他把建表语句发过来，看了一眼就发现问题了：订单表主键不是自增整数，而是35位业务单号字符串，时间字段用VARCHAR存储，表字符集还停留在utf8mb3，另一张关联表却是utf8mb4。这就是典型的MySQL DDL阶段埋下的债，平时不炸，一到大促就全爆出来。

DDL这块确实不起眼，大多数开发者日常都在写SELECT、INSERT、UPDATE，只有在启动新项目或者加字段的时候才会碰一下CREATE TABLE和ALTER TABLE。但恰恰是这个低频操作，决定了后面所有SQL的生死。一篇讲全MySQL DDL的干货文挺难找，文档倒是很全，可没人告诉你哪些坑会踩，哪些写法会把一张表锁死。我打算从这些年实操里踩过的、以及帮别人排查过的DDL问题出发，把CREATE、ALTER、DROP、TRUNCATE、索引管理、线上执行纪律这些事拆开讲一遍。适合刚接触MySQL的新手，也适合那些写过几年SQL但没系统整理过DDL的同学。

1. DDL与DML的边界：先想清楚你在动什么

1.1 DDL到底包含哪些语句

很多人在面试里被问“DDL和DML有什么区别”，第一反应是：DDL是建表、改表、删表的，DML是增删改查的。这个方向没错，但不够完整。

从MySQL官方定义来看，DDL是Data Definition Language，数据定义语言。常见的CREATE、ALTER、DROP、TRUNCATE、RENAME都属于DDL，另外CREATE INDEX、DROP INDEX这类索引操作在MySQL里也被归为DDL。还有COMMENT相关、ANALYZE TABLE、OPTIMIZE TABLE、REPAIR TABLE这些维护性操作，从广义上看也跟表结构定义紧密相关。

DML则是Data Manipulation Language，数据操纵语言，核心是INSERT、UPDATE、DELETE、SELECT。看起来就是“定义”和“操作”的区别，但实际使用中的边界没有这么简单，因为TRUNCATE虽然语法上像DML的动作，官方却明确把它划到DDL里，这直接决定了它的事务行为和回滚效果，后面第四部分会专门展开。

搞清楚这个分类不是抠字眼。我们排查线上问题的时候，第一件事就是看操作类型，然后再决定用什么手段处理。比如一个事务里先UPDATE了几行数据，再执行一条ALTER TABLE，很多人以为可以随时ROLLBACK，实际MySQL在执行ALTER TABLE的时候会把当前事务隐式提交掉，前面的UPDATE就再也回不去了。这个坑我在生产环境里见过不止一次，某次内部版本升级时，有人为了“反正能回滚”，在一个事务里既改了业务数据又改了表结构，结果出了状况想回数据，才发现UPDATE那部分已经跟着提交了，只能靠备份恢复。

1.2 一个容易被忽略的事务陷阱

MySQL和Oracle、SQL Server在DDL事务行为上有很大差别。Oracle支持DDL的隐式提交但至少很多DDL可以通过事务控制去做更细粒度管理，SQL Server也有类似机制；MySQL这边相对简单粗暴，几乎所有DDL都会导致当前事务提交。

具体来说，如果你执行了：

START TRANSACTION; UPDATE user SET nickname = 'test' WHERE id = 1; ALTER TABLE user ADD COLUMN age INT DEFAULT 0; ROLLBACK;

最终的结果是：UPDATE生效了，ALTER也生效了，ROLLBACK没有把任何东西撤销掉。因为执行ALTER的瞬间，事务已经被隐式提交，后面的ROLLBACK只是开启了一个空事务再回滚，什么都没回滚掉。

这个行为在官方文档里写得清楚，但实际开发里知道的人真不多。我遇到过某团队做数据订正脚本，把“改状态 + 加字段”放在一个事务里，订正到一半报错，想回滚，结果状态改了，字段也加了，数据还留在错误状态。最后没办法，只能通过解析binlog把那部分UPDATE倒出来，手工清洗再回写。

所以有一条纪律值得写死在团队规范里：DDL永远单独执行，不跟DML混在同一个事务脚本中；如果确实要保证业务数据可回滚，就把DML和DDL拆成两步，分别做备份点。

2. 建表设计里的学问：大多数后期问题在前三个月就埋好了

2.1 字段类型选择：别让VARCHAR扛所有事

CREATE TABLE是第一道关卡，可偏偏很多人建表时图省事，字段类型随手一敲。最常见的情况是把ID、手机号、订单号全部塞进VARCHAR，时间字段也用VARCHAR，金额用FLOAT。

VARCHAR本身没有错，错的是不分场合地用它。以订单号为例，35位的业务单号看起来确实需要字符型，但如果这个表的数据量会超过百万，主键用VARCHAR带来的问题就很具体：占用空间大、B+树索引比较字符串比比较整数慢、聚簇索引叶子节点能容纳的行数变少。更麻烦的是，如果业务上还有按订单号范围统计的需求，VARCHAR排序是按字典序排，不是按你理解的时间顺序排。

时间字段放VARCHAR就更难受了。MySQL的DATE、DATETIME、TIMESTAMP都有专门的存储格式、比较逻辑和索引优化。你用VARCHAR存了“2024-06-01 12:30:45”，查询时用BETWEEN去筛选，要么隐式转换导致索引失效，要么必须严格保证格式统一，否则漏数据。我见过一个报表系统，因为时间字段是VARCHAR且有的行混入了“2024/6/1”这种格式，导致月度统计每月都会少几条数据，排查了两天才发现是格式不统一。

金额字段用FLOAT也是一颗雷。FLOAT是浮点数，存在精度丢失，银行场景和订单金额累计场景绝对不能用。项目里老实的做法是DECIMAL(10,2)或者DECIMAL(12,2)，看业务体量决定整数位和小数位。用FLOAT做金额累计，短期内看不出问题，但数据量一大，SUM出来的结果会和财务系统的对账单差几分钱，谁都没法解释清楚。

下面是几个常见字段类型的选型参考，网上文档写得分散，我这边整理成一个实战维度比较浓的版本：

2.2 字符集与排序规则：乱码和隐式转换的根源

字符集的选择是CREATE TABLE里极容易被忽略、但后续极难改的一环。早几年很多系统还在用utf8，准确来说是utf8mb3。MySQL的utf8最多支持3字节，而常见的中文是3字节，表情符号是4字节，所以用utf8建的表插入一条带表情的内容就会报错，或者乱码。后来大家统一迁移到utf8mb4，但不彻底的迁移又会留下新问题。

比如一张订单表用utf8mb4，另一张用户表用utf8mb3，两表按用户ID关联的JOIN其实影响不大，但如果关联字段涉及中文昵称，就会出现隐式转换，因为两边排序规则不同，MySQL会自动做转换，索引失效、查询变慢。更隐蔽的是，建表时没指定字段级别的字符集，表级别改了，字段还是旧的，这种半迁移状态最容易让人迷惑。

排序规则也值得一提。utf8mb4_general_ci和utf8mb4_unicode_ci在中文场景下绝大多数时候表现一致，但严格来说unicode_ci在部分特殊字符上的排序规则更标准。MySQL 8.0默认排序规则是utf8mb4_0900_ai_ci，如果和旧库的utf8mb4_general_ci字段做关联，同样会触发隐式转换。所以建表时最好统一写明：

CREATE TABLE user_info ( id BIGINT NOT NULL AUTO_INCREMENT, nickname VARCHAR(50) NOT NULL, PRIMARY KEY (id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

线上排查时，可以用一条SQL快速看表字符集和排序规则：

SELECT TABLE_NAME, TABLE_COLLATION FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'your_db';

2.3 主键与约束设计：自增不是唯一答案

主键设计是我在DDL沟通里花时间最多的话题。自增INT主键确实省心，但分布式场景、分库分表场景里，自增ID没法跨库保证全局唯一，这时候可以用BIGINT配合雪花算法生成的有序ID。而UUID字符串做主键的问题刚才提过，空间浪费很严重，不建议。

另一个容易被忽略的是复合主键。业务表用两个字段做联合主键，这在某些维度表里合理，但如果其中一列本身区分度很低，索引树会变得很深，插入性能也会衰减。通常情况下我更推荐用无意义的自增ID做主键，再给业务字段单独建普通或唯一索引，这样既保证了数据定位效率，又保持了业务查询的灵活性。

约束方面，NOT NULL应该成为默认习惯，尤其是核心业务字段。MySQL 8.0之前不强制支持CHECK约束的完整语义，很多人就在应用层做校验，但数据库层面完全不设防。8.0之后CHECK约束真正生效了，可以在建表时显式声明，例如：

CREATE TABLE order_info ( id BIGINT NOT NULL AUTO_INCREMENT, order_status TINYINT NOT NULL DEFAULT 0, amount DECIMAL(10,2) NOT NULL, PRIMARY KEY (id), CONSTRAINT chk_order_status CHECK (order_status IN (0, 1, 2, 3)) );

加了CHECK约束以后，非法状态值在数据库入口就会被拦下来，比全靠应用层判断稳妥得多。建表时还有一个小习惯值得培养：每张表都加上create_time和update_time，前者用DEFAULT CURRENT_TIMESTAMP，后者用DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP。这两个字段在很多数据修复、问题回溯场景里能救命，花这么低成本换来的排查能力，非常值。

3. ALTER TABLE是重灾区：加字段、改类型、换字符集都有坑

3.1 字段变更的常规操作与语法区别

ALTER TABLE可能是DDL里最常用的语句了，但语法细节上的坑也不少。

增删字段的常规写法是：

ALTER TABLE user_info ADD COLUMN age INT DEFAULT 0 COMMENT '年龄'; ALTER TABLE user_info DROP COLUMN age;

修改字段类型时，有MODIFY和CHANGE两个语法。MODIFY只改字段定义，不改字段名；CHANGE可以同时改字段名和类型。很多人容易把CHANGE的旧名新名顺序写反，语法是这样的：

-- 只改类型 ALTER TABLE user_info MODIFY COLUMN nickname VARCHAR(100) NOT NULL; -- 改名加改类型 ALTER TABLE user_info CHANGE COLUMN nick nickname VARCHAR(100) NOT NULL;

如果你用CHANGE但写成了“新名旧名”，MySQL会直接报错或者产生一个你完全没预料到的新字段。这个错我看了不止一个同事踩过。

改字段位置也有讲究。默认新增字段是在表末尾，如果想放到指定位置，用AFTER或者FIRST：

ALTER TABLE user_info ADD COLUMN age INT DEFAULT 0 AFTER nickname;

但如果一张表已经有很多数据，AFTER操作在某些版本的MySQL里可能导致表重建，比追加到末尾要慢很多。生产环境里，字段位置本身不影响查询性能，所以除非有强需求，否则没必要为了“看着舒服”去移动字段位置。

改字符集又是一个容易误解的地方。ALTER TABLE ... DEFAULT CHARACTER SET只是修改表的默认字符集，不会自动转换已有字段的字符集。如果你想让所有字段的字符集一起变，需要用CONVERT TO CHARACTER SET：

ALTER TABLE user_info CONVERT TO CHARACTER SET utf8mb4;

这两者的区别非常关键。旧数据是utf8mb3且已经存在乱码，CONVERT会按当前字符集重新编码；如果仅仅是新建字段想用新字符集，则用DEFAULT CHARACTER SET就够了。不少人在迁移字符集时少写了CONVERT，结果查数据发现还是乱码，就是没搞清这个语义。

3.2 为什么你的ALTER会锁表或者一直卡住

这是DBA生涯中大家最常问的问题之一。明明只是一条加字段的语句，为什么运行了一个小时还没结束，业务侧写操作全部堵住了？

要理解这个，得先知道MySQL执行ALTER的基本策略。早期版本里，很多ALTER操作都会拷贝整张表数据到新表，也就是COPY算法，期间原表上DML会被阻塞。MySQL 5.6开始引入了InnoDB Online DDL，不少操作支持INPLACE算法，允许在重建表的过程中继续执行写入，但具体能不能INPLACE，取决于操作类型和版本。

拿8.0来说：

• ADD COLUMN在表末尾新增字段，8.0.12之后支持INSTANT算法，秒级完成，不复制数据不锁表。
• 修改VARCHAR长度，如果不超过该字段类型的最大长度限制，有些场景可以INPLACE，但扩大长度有时候需要重建。
• 添加二级索引，InnoDB支持INPLACE算法，过程中读写不受影响。
• 修改主键字段，大概率需要COPY算法，整个过程会锁表。
• 修改字符集，通常需要COPY算法，数据量越大耗时越长。

所以一条ALTER卡住的原因通常有两个层面。第一，操作本身触发了COPY算法，全表数据要复制一遍，表大、磁盘慢，自然就久；第二，即使支持INPLACE，执行前需要获取元数据锁（MDL），如果此时有别的事务正在访问这张表，ALTER会在队列里一直等，表现就是“卡住不动”。

排查这类卡住的思路很直接。先查METADATA LOCK等待：

SELECT * FROM performance_schema.metadata_locks; SELECT * FROM performance_schema.data_locks;

再结合PROCESSLIST看是谁持有锁：

SHOW FULL PROCESSLIST;

然后去确认那个长时间的查询或者事务，要么等它结束，要么KILL掉，ALTER才能真正开始执行。有一次我帮某团队处理一个跑了三个小时还在等待的加字段操作，排查下来是一张统计报表的SELECT事务一直没提交，元数据锁被它死死攥住，ALTER排在后面干等。KILL掉查询后，ALTER十秒内就完成了。

3.3 大表变更的现实选择

如果表已经上亿行，哪怕是一条加索引的ALTER也可能执行几分钟甚至更久。原生的Online DDL在部分场景下能减少锁的影响，但大量写入业务依然无法接受。

社区里常用的做法是用在线表结构变更工具，原理大致是：创建一张新表，按目标表结构建好，然后用触发器或者增量拷贝的方式把原表数据同步到新表，同步完成后在低峰期做一次简短的表切换。整个过程业务基本无感，适合大表、高并发场景。

但工具不是银子弹。它要求表必须有明确的主键，而且操作过程中触发器会带来额外开销，对写入频繁的表会有一定压力。另外，切换表名的瞬间虽然很短，仍然存在DDL排队问题。所以我个人的实践是：

• 小表（百万行以内）：直接用原生ALTER，低峰期执行。
• 中大型表（千万级）：评估能否接受几分钟的锁影响，能接受就原生ALTER，不能接受就上在线变更工具。
• 超大表（亿级别）：白天绝不动，晚上低峰期配合工具执行，并且有完整回退方案。

还有一个容易被忽略的点：ALTER之前先检查空闲磁盘空间。COPY算法需要足够的临时空间，空间不足会导致变更中断，留下半张临时表。前年我处理过一次数据库磁盘被临时文件打满的事故，就是ALTER TABLE改字段类型时触发了COPY，临时文件占了几十GB，最后只能停机扩容，非常狼狈。所以执行大表ALTER前，务必确认磁盘剩余空间至少是表体积的1.5倍到2倍。

4. DROP、TRUNCATE、DELETE：三者的边界与误操作恢复

4.1 语法与机制上的本质差异

这三个语句在很多人眼里都是“删数据”，但它们权限级别不同、事务行为不同、对自增ID的影响也不同，误用代价天差地别。

DELETE是DML，逐行删除，支持WHERE条件，删除操作会写binlog，也可以放进事务里回滚。TRUNCATE是DDL，直接把表的数据页重置，速度快得多，不支持WHERE，执行后自增ID会重置，而且因为属于DDL，在事务里执行后基本不可回滚。DROP则是直接把整张表的结构和数据一起删掉，表空间释放，彻底消失。

用表格表达更清晰：

比较隐蔽的一个点是，TRUNCATE在使用InnoDB时，虽然官方定义为DDL，但某些版本里它在内部会以DROP + CREATE的方式实现，所以binlog里的记录其实是DROP TABLE + CREATE TABLE的格式。这也是为什么基于binlog做误删恢复时，TRUNCATE比DELETE更难处理，因为已经看不到逐行的删除记录了。

4.2 误删之后能做什么：备份与binlog

如果误执行了DROP TABLE或者TRUNCATE，第一步永远不要慌，先确认有没有备份。有完整备份加binlog的话，恢复思路是清晰的：

1. 先确认误操作时间点，找到对应的binlog文件和position。
2. 用全量备份把数据恢复到误操作之前的状态。
3. 用mysqlbinlog把备份时间点到误操作之间的增量binlog解析出来。
4. 跳过DROP/TRUNCATE相关的事件，把增量数据重新导入。

具体解析命令大概是：

mysqlbinlog --start-datetime="2024-06-01 00:00:00" --stop-datetime="2024-06-01 12:00:00" /var/lib/mysql/binlog.000012 > recovery.sql

注意，binlog_format建议使用ROW模式。STATEMENT模式下DELETE、UPDATE记录的是SQL语句本身，重建时很容易因为数据环境不同而无法精确还原；ROW模式下每条变更都有前后镜像，恢复准确率高得多。

没有备份的情况下，难度陡然上升。某些文件系统层面的误删恢复工具理论上可以尝试，但MySQL的数据文件通常比较大且频繁写入，文件恢复成功率很低。这也是我一直强调备份是底线的原因：DDL操作前，哪怕只是加一个索引，最好也要有当天的备份，有备无患。

另外有一个小细节，DROP TABLE前MySQL支持类似于回收站的做法吗？原生不支持。所以某些团队会选择“软删除”方案：核心表不提供DROP权限，只允许RENAME TABLE把表改名加后缀，比如user_info_bak_20240601。这算是一种低成本的安全网。真的确认没用了，再在保留一段时间后物理删除。这个习惯在多人协作的项目里非常管用。

5. 索引管理：用DDL把慢查询消灭在表结构阶段

5.1 索引创建与选择的实用维度

索引管理也是DDL的一部分，CREATE INDEX、DROP INDEX、ALTER TABLE ADD INDEX都归到这里。索引的目的是加快查询，但每多一个索引，写入的时候就多一份维护成本，所以建索引要考虑查询模式，而不是看到慢查询就加。

实际工作中我一般按以下顺序判断：

• 第一步：看WHERE条件里哪些字段被高频使用。
• 第二步：看这些字段的区分度如何。比如状态字段只有0和1两种值，区分度极低，单列索引意义不大。
• 第三步：考虑联合索引，在区分度高的字段上建前缀列。
• 第四步：观察查询是否只需要某几个字段，如果是，可以用覆盖索引减少回表。

覆盖索引是个很实用的技巧。查询只访问索引中包含的列，就不需要回表查数据，速度会快很多。例如：

CREATE INDEX idx_user_status ON user_info(status, create_time);

如果某个查询只查status和create_time，那么通过这个索引就能拿到全部数据，这是覆盖索引的效果。

联合索引的顺序又是个高频考点。最左前缀原则说的是：查询条件只有包含联合索引最左边的列，才能高效使用这个索引。所以建联合索引时，把等值查询的字段放前面，范围查询字段放后面，这样索引的利用率最高。比如按时间段查某状态下用户，建议(status, create_time)，而不是(create_time, status)。

5.2 存量索引的清理与冗余识别

线上跑久了，表上的索引会越来越多，冗余索引也在悄悄累积。最常见的是idx_a和idx_a_b这两个索引同时存在，idx_a在联合索引idx_a_b中已经被覆盖了，属于冗余。冗余索引不仅浪费空间，还拖慢UPDATE、INSERT的性能，因为每改一行数据都要同步维护所有相关索引。

识别冗余索引有一个简便办法：看information_schema.STATISTICS，也可以通过查询慢日志和explain判断执行计划里哪些索引从未被使用。我自己操作时，习惯先做一轮分析：

SELECT TABLE_NAME, INDEX_NAME, GROUP_CONCAT(COLUMN_NAME ORDER BY SEQ_IN_INDEX) AS cols FROM information_schema.STATISTICS WHERE TABLE_SCHEMA = 'your_db' GROUP BY TABLE_NAME, INDEX_NAME;

再把结果里前缀重复的索引找出来，人工确认后通过DROP INDEX或者ALTER TABLE DROP INDEX清理。

MySQL 8.0还提供了一个很实用的功能：不可见索引。你可以把索引标记为INVISIBLE，优化器默认不会选它，但索引仍然存在，写入时依然维护。如果确认一段时间内没有产生任何慢查询依赖它，再真正删除。这相当于一个观察窗口，比直接DROP更安全。

ALTER TABLE user_info ALTER INDEX idx_nickname INVISIBLE;

这个功能在生产环境里非常有用，尤其是你想删一个索引但不确定有没有漏网的查询依赖它的时候。

6. 线上执行DDL的实战纪律与问题排查

6.1 一个卡住的ALTER背后是什么

前面提到过元数据锁会导致ALTER一直等待，我再展开讲一下完整的排查链路，因为这是线上最常见的DDL异常场景。

故障现象通常是：某条ALTER TABLE语句执行了很久没有返回，同时业务侧开始出现大量插入超时或者元数据锁等待。用SHOW FULL PROCESSLIST看，能看到ALTER处于Waiting for table metadata lock状态。这时候别急着KILL ALTER，因为真正的问题可能不是它，而是前面某个长时间未提交的事务或者一条大查询。

排查步骤我建议这样走：

1. 先把所有连接状态列出来，找到那些已经是Sleep但超过几秒的事务，它们往往持有MDL锁。
2. 用information_schema.innodb_trx查看当前活跃事务，尤其是执行时间长、但状态不是Running而是Sending data或者Sleep的。
3. 找到具体连接后，是等它自然结束还是KILL，取决于业务容忍度。有时候那个事务确实在做大查询，等它跑完也许比杀进程代价更低。
4. KILL掉阻塞方之后，ALTER通常会自动开始执行，这时再用SHOW FULL PROCESSLIST确认状态从Waiting变成了altering。

有一次现场排查，ALGER卡了半小时，我按这个方法找到阻塞方是一个连了数据库的备份客户端，开了事务却一直没有提交。杀掉那个会话后，ALTER秒级完成。这类问题有个规律：越是内部工具、监控脚本、报表系统，越容易持有DB连接干等，反而业务代码通常都规范提交。

6.2 执行DDL前必须完成的三项检查

考虑到DDL的破坏半径，我建议团队形成一套固定动作，每次执行DDL前按顺序过三关。

第一关：备份检查。确认至少有一份可用的全量备份，并且binlog开启、binlog_format是ROW。没有备份的情况下执行DROP或者改表，心理负担完全不同。很多公司在测试环境还好，生产环境因为没有完整备份导致数据永久丢失的事故，每年都能听到。

第二关：影响评估。先估算表行数和表体积，再确认ALTER操作是INSTANT、INPLACE还是COPY。如果是COPY，就要看磁盘剩余空间是否足够、业务是否接受可能的锁影响、有没有低峰期窗口。如果行数超过一定量级，应该转化成工具方案或者分阶段迁移，而不是直接在高峰期硬刚。

第三关：回退方案。对于ALTER操作，回退有时候比执行还复杂。加一个字段容易，但这个字段被写入了大量业务数据之后，再DROP掉会不会有问题？修改字段类型后，数据语义是否发生不可逆变化？所以操作前要写好回退脚本，至少要明确“变更失败怎么还原”和“变更成功后，万一数据不合适怎么处理”两条路径。

我实际做线上变更时，还会多用一招：先在测试环境用相同或者接近的数据量跑一遍同样的DDL，记录耗时和资源消耗。测试环境和生产环境硬件不同，但耗时量级和锁表现很接近，能提前暴露不少坑。千万别拿生产环境当实验场，这句话说出来是常识，但每年都有人违反。

另外，DDL语句本身建议单独建一个文件保存，不要直接在客户端里手敲。把完整的变更脚本、执行时间、影响行数、回滚方式记录在案，后续追查问题的时候会省掉大量沟通成本。尤其表字段比较多的老项目，改动历史不去记录，根本没人说得清某个字段是干什么的、什么时候加的、为什么这么设计。

最后聊一点个人体会

DDL这东西，语法上真不难，难的是搞清楚一条语句在底层会触发什么动作、在什么样的情况下可能造成锁表、在什么情况下会永久丢数据。我见过太多项目，前期建表随随便便，后期SQL慢、扩展难、数据对不上账，最后只能靠运维加班补坑。反过来，那些建表时愿意多花半小时想字段类型、字符集、主键设计和索引策略的项目，后面几年会省下无数个凌晨。所以我把这篇内容看成一份“DDL前必须读一遍的清单”。如果你正打算建新表或者改动现有表结构，按这里提到的点逐一核对一遍，应该能避开大部分常见的坑。