企业官网建设流程全解析

最近帮人排查一条慢查询，问题最后落在了一个很基础的点上：没搞懂 InnoDB 的聚簇索引到底长什么样，导致二级索引设计得很随性，回表次数多得吓人。这种问题其实特别常见——很多开发能熟练写 SQL，但对 MySQL 架构、Server 层和 Engine 层的分工边界、InnoDB 的 B+ 树组织方式、事务与锁的实现机制，始终隔着一层窗户纸。这篇就把这些硬核内容彻底聊透：一条 SQL 从进入到落盘，两层架构各自做了什么；InnoDB 为什么用聚簇索引存储数据；B+ 树为什么是默认选择；ACID 靠 Redo/Undo Log 怎么撑起来；MVCC 和锁又是如何配合的。适合想把 MySQL 底层知识补扎实的后端开发，也适合准备面试、想深入理解 InnoDB 的读者。

1. 两层架构的边界：Server 层处理"是什么"，引擎层处理"怎么存"

1.1 一条 SQL 语句在两层的完整旅程

先理清楚一个最基本的问题：当你执行一条 SQL 时，MySQL 到底经历了什么。绝大多数人只知道"MySQL 会解析 SQL、执行 SQL"，但拆开看，这条语句的旅程是被切成两段的——Server 层负责前半段，存储引擎层负责后半段。

我拿一条最简单的SELECT * FROM orders WHERE order_id = 2025001举例。这条语句先进入连接器，连接器做两件事：建立连接、权限校验。权限校验不是只查一次，表级权限、列级权限都会在这时候确认。连接器之后是解析器，负责词法分析和语法分析，把 SQL 字符串拆成 token，再根据 MySQL 的语法规则生成语法树。这个阶段如果 SQL 写错了，比如关键字拼错、字段名不存在，报错就出现在这里，后面的一切都不会发生。

接下来是优化器，它是 Server 层里最核心的组件。优化器会拿到语法树，判断这条 SQL 该走哪个索引、多表关联时先连哪张表、需不需要临时表排序。比如SELECT ... WHERE status=1 AND amount>100，如果status和amount都有索引，优化器要比较两个索引的区分度，选一个更优的，甚至选择做索引合并。优化器最终输出的是一个执行计划，而不是数据。

真正开始干活的是执行器。执行器拿到执行计划后，开始调用存储引擎的接口。注意，执行器自己不碰数据文件，它做的是"调度"：向 InnoDB 引擎要第一行，判断是否满足条件，满足就返回给客户端，不满足就继续要下一行。整个过程是一个"引擎取数 + Server 层过滤"的流水线。对于 UPDATE 语句，执行器还会多一个步骤：先在引擎层找到对应行，拿到这行的当前版本，然后调用引擎的更新接口，引擎内部完成数据页修改、日志写入、锁维护。

在这条链条里，Server 层完全不关心数据落盘的具体格式，它只负责"这条 SQL 是什么意思、该怎么执行、怎么把结果返还"。而 InnoDB 引擎层关心的是"数据存在哪个页、页在哪个文件、索引树怎么走、这行数据的最新版本是哪条、当前有没有锁冲突"。这就是两层的核心边界。

1.2 为什么非拆不可：存储引擎插拔设计的本质

有个问题值得多想一层：为什么 MySQL 要把架构拆成 Server + Engine 两层，而不是像很多单机数据库那样一杆子捅到底？

历史原因是 MySQL 从诞生起就支持多存储引擎。Server 层通过统一的存储引擎接口（Handler API）访问不同的引擎，这就好比你的电脑有统一的 USB 接口，显示器、U 盘、键盘都能插同一个口，设备之间互不干扰。MyISAM、InnoDB、Memory、Archive 这些引擎实现同样的接口，但内部天差地别。

这个设计带来的直接好处是：往上，SQL 语法和优化逻辑可以共用一套；往下，不同的存储引擎给不同的业务场景提供差异化的能力。MyISAM 不支持事务，但全文索引和压缩在某些场景下便宜好用；InnoDB 支持事务、行锁、崩溃恢复，所以在绝大多数业务系统中成为默认选择。

不过插拔设计也意味着，Server 层能用的能力上限被引擎层限制。比如 Server 层支持 UPDATE JOIN，但如果引擎层不支持行锁，并发更新时就只能靠表锁串行化，性能直接崩盘。所以我们在讨论"MySQL 性能"时，绝大多数情况下讨论的其实是 InnoDB 引擎的表现——索引组织方式、事务隔离、锁粒度、恢复机制，这些才是真正的核心。

2. InnoDB 的聚簇索引与非聚簇索引：数据到底放在哪里

2.1 聚簇索引：叶子节点直接扛数据

InnoDB 的表和索引是一体的，表本身就是按索引组织结构存储的。这句话听起来有点绕，翻译成大白话就是：你建了一张表，InnoDB 会自动为主键建立一个索引，整张表的数据就按照这个索引的键值顺序，物理地存放在这个索引的叶子节点里。这个索引用专业术语讲叫聚簇索引。

聚类索引的叶子节点里，存的是完整的行记录，不是指向行的指针。也就是说，你查询走聚簇索引，一次就能把整行的所有列都拿到，不需要再跳去别的地方取数据。这张表的所有数据页，都是通过聚簇索引的 B+ 树结构串联起来的，数据页之间是双向链表，页内部的记录通过单向链表串联，页与页之间通过页目录实现二分查找。

这里有个非常实际的工程问题：如果建表时没指定主键怎么办？InnoDB 不会让表裸奔。它会先找第一个非空唯一索引来当聚簇索引；如果连这个也没有，就生成一个隐藏的ROWID（6 字节，自增）作为聚簇索引键。这个隐藏 ROWID 对业务不可见，但会带来一个隐患：每次插入时 InnoDB 都要生成新的 ROWID，这个生成操作有一个全局的原子计数器，高并发插入时如果走到这个兜底逻辑，会触发额外的竞争开销。所以我的建议一直很明确：建表就老老实实指定主键。

还有主键的选择问题。聚簇索引的数据行是按主键顺序物理排列的，如果主键是自增整型，新行总是插在 B+ 树的右侧，几乎不会触发页分裂。如果主键是 UUID 这类随机值，插入时会随机落在树的中间位置，为了维持有序性，InnoDB 频繁做页分裂，页面产生碎片，写入性能会受到明显影响。这也是为什么几乎所有的生产规范都会说：主键用自增 ID，而不是 UUID。

2.2 非聚簇索引与回表：二级索引不能自给自足的真正原因

非聚簇索引在 InnoDB 里叫二级索引，它跟聚簇索引最大的区别是：二级索引的叶子节点不存整行数据，只存索引键值 + 主键值。

举个例子。假设一张users表有主键id和普通索引email，那你查询SELECT * FROM users WHERE email='a@example.com'时的路径是：先走进email的二级索引树，通过 B+ 树的查找，在叶子节点里找到email='a@example.com'对应的记录，这条记录里存着主键值id；然后拿着这个主键值，再回到聚簇索引树里重新查找一次，找到完整的行数据。这个过程就叫回表。

为什么二级索引的叶子节点非要存主键值？有两个原因。第一，主键在表里是唯一的，用主键做"地址"永远不会产生歧义；第二，当聚簇索引结构发生变化时（比如页分裂、行迁移），二级索引不需要跟着改，因为主键值不变。用主键作为桥梁，把两个索引树松散地关联在一起，这样索引维护成本最低。

但回表的代价不小。每次回表都是一次 B+ 树搜索，如果二级索引的命中的行数很多，比如WHERE email LIKE '%@qq.com'命中了 10 万行，就意味着要回表 10 万次，每次都是随机读一个数据页。MySQL 会根据行数和成本来决定是走索引还是直接全表扫——有时候全表扫反而更快，就是因为回表次数太夸张了。

2.3 覆盖索引和索引下推：从减少回表次数开始的优化

理解了回表成本，就自然理解了覆盖索引的价值。所谓覆盖索引，就是查询需要的所有列都在二级索引里，不需要回表。比如SELECT id, email FROM users WHERE email='a@example.com'，因为二级索引的叶子节点本身就存了email和id，查询直接把叶子节点的内容返回就完事了，一次回表都省了。这就是为什么很多规范里会强调：不要随便 SELECT *，需要的列写出来，配合联合索引构建覆盖索引，能砍掉大量随机 IO。

还有一个容易被忽略的优化机制叫索引下推。在没有 ICP（Index Condition Pushdown）的时候，二级索引查询是两层过滤：引擎层根据索引条件定位记录，再把每条记录回表后交给 Server 层过滤剩余条件。有了 ICP，MySQL 允许将部分 WHERE 条件下推到引擎层，让引擎在二级索引树遍历时就顺手过滤掉不满足条件的记录，减少回表次数。典型场景是联合索引(name, age)查询WHERE name='xx' AND age BETWEEN 20 AND 30。在 ICP 出现之前，只靠name定位，每条都回表查 age；开启 ICP 后，引擎层在索引树上直接按 age 过滤。

这里我给一条实操建议：所有定位索引查询的时候，先看执行计划里Extra字段是不是Using index，如果显示Using index condition说明走了 ICP，如果是Using where; Using index就要想想能不能把 where 条件里的列并入索引列。

3. B+ 树的取舍逻辑：为什么 InnoDB 偏偏选它

3.1 哈希、二叉树、B 树的天然短板

很多刚接触 InnoDB 的人会问：索引为什么不用哈希？哈希查找 O(1)，在单点等值查询下不是更快吗？

哈希索引确实在等值查询上有速度优势，但它有一个致命软肋：不支持范围查询。哈希表里的数据按散列函数均匀分布，相邻的键值散列后大概率不在相邻的位置，所以WHERE id > 1000 AND id < 2000这种查询，哈希结构完全无能为力，只能全表扫。而业务系统中范围查询太常见了——时间范围、金额区间、分页排序，这些都是索引的基础操作。哈希另一个问题是无法排序，没有顺序访问的能力。所以 InnoDB 里哈希索引只作为一个自适应哈希索引的辅助结构存在，只加速等值查询的定位，不承担索引的主干职责。

再看二叉树。二叉查找树理论上查找复杂度 O(log N) 也不错，但问题出在存储介质上。MySQL 的数据在磁盘上，每次访问一个节点就要一次磁盘 IO，而磁盘 IO 是纳米级内存访问和毫秒级磁盘访问的差距，IO 次数直接决定查询性能。二叉树节点少、深度深，2 的 20 次方就对应 20 层深度，意味着最坏情况要 20 次磁盘 IO。而且二叉树在极端情况下会退化成链表，那就更没法看。

B 树是 B+ 树的"近亲"，它也有多路平衡的特性，但和 B+ 树最大的区别是：B 树的每个节点都存数据，所有键都对应一条记录。InnoDB 的一个数据页默认是 16KB，如果每个内部节点都存数据，那一个页能装的键就会少很多，树的高度会被迫增加。树高每增加一层，查询就多一次磁盘 IO。所以 InnoDB 选择了 B+ 树而不是 B 树——这不是数学上的绝对最优，而是磁盘 IO 约束下的工程最优解。

3.2 B+ 树在磁盘场景下的三重优势

B+ 树有三个特性，每一个都精准对应 MySQL 的场景需求。

第一，非叶子节点只存键，不存数据。这意味着一个 16KB 的页能塞下大量的索引键。假设主键是 8 字节的 BIGINT，指针取 6 字节，一个页能存大约 16 * 1024 / 14，约 1170 个键。这一下就把树的扇出撑大了，树的高度被压得很低。

第二，叶子节点通过链表串联。B+ 树的所有叶子节点构成一个有序链表，这个设计对范围扫描和排序极其友好。WHERE id BETWEEN 100 AND 1000时，找到下限 100 后，直接沿链表顺序向后遍历，读到的页顺序是连续的，磁盘预读能发挥最大效果。相比之下，B 树的叶子彼此独立，范围扫描要在多层的节点间反复跳转，IO 路径完全是乱的。

第三，页的利用率更高。非叶子节点不存数据，意味着同样大小的缓存池可以缓存更多的内部节点，内存命中率更好。大多数查询在内存中的索引树上就能完成任务，真正落盘 IO 的次数大幅减少。

3.3 三层 B+ 树到底能存多少数据：实际操作中的估算方法

我一直建议团队里的同学都亲手算一遍 B+ 树的容量，这个数字会让你对 MySQL 的 IO 能力有一个非常具象的判断。

还是用 16KB 页来算。根节点存键和指针，一个索引键加一个子节点指针大约 14 字节，所以根节点大约能存 1170 个键，对应 1170 个子节点。第二层每个节点同样存 1170 个键，所以第二层能覆盖 1170 * 1170，大约是 137 万个分支。第三层就是叶子节点了，叶子节点存真实数据。如果我们假设一行数据平均 1KB，一个叶子页能存 16 行，那么三层 B+ 树最多能支撑 1170 * 1170 * 16，大概是 2190 万行数据。如果假设一行数据 500 字节，就是约 4380 万行。

这个估算告诉我们几个重要事实。第一，绝大多数业务表的数据量都在三层 B+ 树的覆盖范围内，也就是说，一次主键查询最多也就 3 次磁盘 IO，这个数字是非常可观的。第二，如果表的数据量真的突破了几千万行甚至上亿，树高会从 3 变成 4，查询从 3 次 IO 变成 4 次 IO，性能并不会陡然崩溃，这也是 B+ 树在工程上特别皮实的原因。第三，二级索引树的结构完全一样，回表不过是先走一遍二级索引树（约 3 次 IO），再走一遍聚簇索引树（约 3 次 IO），最坏 6 次 IO。把这几个数字刻在脑子里，你在判断一个查询快不快时，就不再是凭感觉，而是能快速估算 IO 成本了。

4. 事务四大特性的实现账本：Redo/Undo 与 ACID 的关系

4.1 原子性和持久性：Redo Log 的预写机制

ACID 里，原子性（Atomicity）和持久性（Durability）的底层支撑是 Redo Log。

先说为什么需要 Redo Log。InnoDB 的数据以页为单位存在磁盘上，但每次事务提交都要更新数据页的话，直接把修改同步刷到磁盘是最简单粗暴的做法。问题是数据页是随机写入的，每次 commit 都刷盘，等于是高频的随机 IO，性能完全无法接受。InnoDB 采用的方案是 WAL——Write Ahead Logging，先写日志，再写数据。

Redo Log 记录的是"物理修改"，也就是某个表空间的某个页，从某个偏移量开始，改成了什么内容。事务提交时，InnoDB 先把 Redo Log 刷到磁盘（根据innodb_flush_log_at_trx_commit的设置，可能是每次提交都刷、每秒刷、或者由操作系统决定），但数据页可以留在内存里，后续在后台慢慢异步刷盘。这个设计利用了两个关键点：Redo Log 的写入是顺序的，顺序 IO 比随机 IO 快几个数量级；而且 Redo Log 追加写，不存在页分裂和碎片问题。

万一数据库崩溃，数据页还没来得及刷盘怎么办？这就是 Redo Log 的用武之地。MySQL 启动时会做崩溃恢复，从日志里把已提交但未落盘的事务重放一遍，保证已提交事务的修改不丢失，这就是持久性的实现。原子性的逻辑也顺带解决了：如果一个事务执行到一半崩溃了，部分修改已经写进数据页，怎么撤销？这时候要靠 Undo Log。

需要注意的一点是 Redo Log 和 Binlog 的区别。Redo Log 是 InnoDB 引擎层的物理日志，是循环写的，大小由innodb_log_file_size控制；Binlog 是 Server 层的逻辑日志，记录的是"这条语句做了什么事"，是追加写的，用于主从复制和时间点恢复。两个日志要配合使用，事务提交时先写 Redo Log 再写 Binlog，通过两阶段提交保证崩溃恢复后两边日志状态一致，避免主从数据不一致。理解了这个机制，你就明白为什么 DBA 会盯着innodb_log_file_size不放：太小了，事务提交频繁，日志切换也频繁；太大了，崩溃恢复时间会变长。这是个需要结合业务写入量权衡的参数。

4.2 隔离性与 MVCC 快照：Undo Log 如何构造历史版本

Undo Log 的作用远不止"事务回滚"这么简单，它还是 MVCC（多版本并发控制）的核心基础设施。

Undo Log 是逻辑日志，记录的是修改前的数据状态。INSERT 操作产生一条 insert undo log，事务回滚时直接删除这条插入即可；UPDATE 和 DELETE 操作产生的是 update undo log，记录的是修改前该行的完整旧值。每条 undo log 都会通过行记录里的DB_ROLL_PTR（回滚指针）串联起来，形成一个版本链。

举个例子。假设有一行数据id=1, balance=100，第一次事务把它改成 200，第二次事务把它改成 300。数据页里当前显示 balance=300，但通过回滚指针，可以顺着链条找到 balance=200 和 balance=100 的历史版本。MVCC 在做一致性读的时候，不是读最新的物理值，而是根据当前事务的快照信息，沿着版本链找到对当前事务"可见"的那个版本。这就是 InnoDB 多版本实现的本质——它维护的不是多个副本，而是通过 Undo Log 构建的多个历史版本。

这里有个非常容易被忽略的坑：长时间运行的大事务会让 Undo Log 不断膨胀。因为只要有一个事务的快照还引用了老版本，那些历史版本就不能被清理，undo文件可能撑到几十 GB。我曾见过一个业务每天跑一个小时级的大报表事务，最终undo表空间持续膨胀，磁盘报警。解决办法是拆分长事务、避免长时间持有一个读视图。事务提交后，purge 线程会逐步清理不再被任何快照引用的 undo 记录。

4.3 一致性：约束、锁与日志共同达成的结果

ACID 里的 C（Consistency，一致性）是最容易被人忽略的。它和前三个特性不同——AID 都有明确的机制去实现，C 更像是一个结果：事务执行前后，数据始终满足完整性约束。

一致性靠什么保证？三个层面协同。第一是数据库本身的约束：主键、唯一键、外键、非空、CHECK 约束，把畸形数据的入口堵住。第二是并发控制机制的配合：锁和 MVCC 保证多个事务交错执行时，不等于脏数据的堆叠。第三是应用层的业务逻辑：比如"转账 A 减钱、B 加钱"这个业务规则，数据库没办法从业务上理解，只能靠事务来封装，要么都成功要么都失败。

我在实际开发中见过的多数一致性问题是第三种，而且不是靠数据库能解决的。有些人喜欢在存储过程或应用代码里把转账操作拆成多个步骤，中间插入日志上报、外部调用，导致事务被拉长甚至干脆不在事务里执行。真遇到底层 Binlog 同步丢数据，那不是 MySQL 的一致性机制失效，而是业务代码没有把操作完整包裹在一个事务边界内。理解 C 的这三层来源，你在写事务时才能真正判断"这个事务该覆盖哪些语句、多长算合理"。

5. 锁与 MVCC 的协作：并发控制不是只有加锁一条路

5.1 InnoDB 锁体系：记录锁、间隙锁、插入意向锁

先区分两个粒度：表锁和行锁。表锁是对整张表加锁，开销小但并发度差；InnoDB 支持行锁，锁粒度小、并发度高，这也是 InnoDB 替代 MyISAM 的重要原因之一。

行锁再往下细分，有三种常见类型。记录锁（Record Lock）是最基础的，锁住的是索引记录本身。间隙锁（Gap Lock）锁的是一个区间，区间内的记录不允许插入。Next-Key Lock 是记录锁和间隙锁的组合，锁住的是一个开区间到闭区间——举个例子，WHERE id BETWEEN 10 AND 20在可重复读级别下，InnoDB 会锁住(10, 20]这个区间，防止其他事务在这个范围内插入新行，也就防止了幻读。插入意向锁则是一种特殊的间隙锁，它表示某个事务想在间隙中插入数据，多个间隙锁之间可以兼容，但插入意向锁和间隙锁冲突。

不同隔离级别下，锁的行为差异很大。读已提交（RC）级别，InnoDB 只加记录锁，不加间隙锁，所以 RC 级别下可能出现幻读——同一个事务内两次查询返回不同的行集。可重复读（RR）级别，InnoDB 默认使用 Next-Key Lock，就是为了防幻读。理解了这一点，你会明白为什么生产环境默认隔离级别是 RR——它不是 Oracle 那样的"读已提交默认"，而是 MySQL 为了兼容主从复制而选择的更严格的锁定级别。

锁粒度还有个容易忽略的点：行锁是加在索引记录上的，不是加在"行数据"上的。执行 UPDATE 时，MySQL 会通过索引定位到目标记录，然后对索引记录加锁。如果 UPDATE 的 WHERE 条件没有走索引，InnoDB 只能全表扫描所有记录，逐条加锁，最终的结果是锁了整张表的所有行。这完全等价于一次表锁，而且更糟糕——它还占了大量行锁空间。这也是为什么 DBA 反复强调：更新条件一定要走索引，否则并发性能直接归零。

5.2 快照读与当前读：MVCC 让读写不互斥的真相

MVCC 最核心的价值是让"读"和"写"不阻塞。在 InnoDB 里，读操作分为两类：快照读和当前读。

快照读也叫一致性非锁定读，普通的 SELECT 语句就是快照读。它不加锁，依赖 MVCC 的版本链生成一个一致性快照。在可重复读级别下，事务的第一个 SELECT 语句会生成一个 Read View，后续所有查询都基于这个 Read View 判断可见性。判断的规则相当简洁：比较每行版本链里的trx_id和 Read View 里记录的活跃事务列表，如果该行版本的创建事务在快照创建之后才开始，或者仍然活跃，就沿版本链往前找更旧的版本，直到找到可见的那个。这个机制保证了：在一个事务内多次 SELECT 返回的结果是一样的，同时其他事务的更新、提交不会阻塞这个读操作。

当前读则是加锁的读，包括SELECT ... FOR UPDATE、SELECT ... LOCK IN SHARE MODE，以及所有 UPDATE、DELETE 语句。当前读必须读到最新的已提交版本，并且会对读取的记录加锁，防止其他事务并发修改。这里有一个事务隔离的重要细节：UPDATE 语句的 WHERE 条件如果加的是范围条件，当前读会用 Next-Key Lock 锁定整个范围，而不仅仅是目标行，这样后续插入新记录到锁定范围时会阻塞，从而防止幻读。

我特意把这两类读分开讲，是因为很多并发问题都出在混淆了它们。比如常见的死锁场景：事务 A 先 SELECT 查询数据（快照读，无锁），然后 UPDATE 更新该行（当前读，加锁）；事务 B 也做同样的操作。两个事务都先读到了旧版本数据，再互相等待对方释放锁，就产生了死锁。这不是 MVCC 的缺陷，而是"快照读 + 当前读"混合使用时的天然摩擦。解决办法是统一访问模式：要么都走当前读，要么事务开始后尽早把需要加锁的行先锁住，避免读到旧版本后再去竞争锁。

5.3 死锁和锁等待排查：实际运维中的两条"硬经验"

排查锁问题，我平时基本靠三张信息渠道，这里直接分享给大家。

第一是SHOW ENGINE INNODB STATUS，在输出里找LATEST DETECTED DEADLOCK段落，能看到最近一次死锁涉及的两条事务的完整 SQL、加锁顺序、等待的资源。死锁发生后，InnoDB 会自动牺牲其中一个事务（回滚），所以它不是无限挂起的，但业务侧必须捕获到"事务被回滚"的异常并做重试。

第二是信息模式表：information_schema.innodb_trx看当前事务列表，information_schema.innodb_lock_waits看谁在等谁的锁，performance_schema.data_locks看具体的锁对象。有一次我排查线上"某条 UPDATE 卡了 30 秒"，就是靠这几个表发现是一个长事务先改了同一行没提交，后面的更新在等行锁。这条链路的问题本质是事务边界太宽，不是锁配置的问题。

第三是经验性的排查顺序。先看是不是大事务：开启事务后做了大量查询、外部调用，迟迟不提交，持锁时间自然就长。再看是不是锁顺序不一致：两个事务都先更新 A 再更新 B，和先更新 B 再更新 A，互相交换资源，死锁概率急剧上升。最后看是不是索引失效：更新条件没用上索引，行锁退化成全表锁，并发瞬间成串行执行。把这三点捋一遍，大部分线上锁问题都能快速定位。

提示：死锁无法百分百避免，数据库层面只能检测和回滚。真正有效的防御是业务侧控制加锁顺序、缩短事务时间，并对死锁回滚做重试处理。重试时要带幂等策略，否则重试本身可能造成重复扣款之类的业务事故。

最后再聊一点个人体会。MySQL 的这些底层机制平时都藏在执行计划后面，只有出了问题才浮出水面——慢查询、锁等待、undo 膨胀，每个现象背后都能对应到这一整套架构设计。我自己踩过几次坑之后养成了一个习惯：写 SQL 之前先在脑子里把索引树走一遍，估算回表次数；启动事务前先确定加锁范围；上线前用EXPLAIN看关键语句的执行计划，重点盯type字段和Extra字段。把这些动作变成日常习惯，很多性能事故其实可以在编码阶段就避免掉。