MySQL数据表操作全攻略：从设计优化到死锁排查-代码聚汇网

MySQL数据表操作全攻略：从设计优化到死锁排查

芙蓉塘外有轻雷·2026-09-03·阅读 100 GEO检测（免费）

MySQL数据表操作索引优化

|难度：普通|阅读约 38 分钟

1. 数据表操作这件事，为什么值得当成能力而不是命令来练

新手刚接触MySQL时，最容易陷入一个状态：建表用CREATE TABLE，加字段用ALTER TABLE，查数据用SELECT，好像每个操作都能找到对应命令，但真到项目里一跑就出问题。不是字段类型选错导致后期无法索引，就是表结构改了一版后数据对不上，更麻烦的是线上表不敢动，加一个字段锁了半天，业务直接超时。这些问题的根源其实不在命令本身，而在于对"数据表"这个对象的理解太薄。

我做了这么多年Java后端，几乎每个项目都离不开MySQL，但真正让我觉得"数据表操作"是个值得反复琢磨的能力，是在处理过一次订单表拆分之后。那张表六千多万行，加了快三十个字段，索引十几个，每次查询都像在泥里走路。那段时间我反复在做的并不是什么高深算法，而是最基础的表结构设计、索引取舍、字段调整、数据校验这些动作。回头才明白，所谓"数据表操作"，本质上是三件事的组合：结构化设计能力、变更控制能力和数据一致性保障能力。

这篇文章就围绕这三件事展开，按我实际做项目时的推进顺序来讲。先讲设计阶段要想清楚的底层机制，再讲一套从建表到查询优化的完整动作流程，接着聊表结构变更会引发的连锁反应，然后走一遍死锁排查的完整链路，最后用工具辅助审视和收尾建议把这些能力固化成习惯。无论你是在学MySQL的初学者，还是已经在业务里被表折腾过的开发者，这篇文章给的都不是孤立命令，而是一套能直接复用的处理思路。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 动手建表前，必须先想清楚的底层机制

2.1 存储引擎选择不是形式主义，直接决定你后续能做什么操作

同一个MySQL实例里，不同表的存储引擎可以不同，这个很多人知道，但真到选型时往往随手用默认值，或者只会说"InnoDB支持事务，MyISAM性能好"。实际上对于数据表操作而言，引擎差异带来的影响比大多数人感受过的要深远得多。

InnoDB是行级锁，MyISAM是表级锁。行级锁意味着修改一张表里某一行时，其他行还能正常读写；表级锁则意味着哪怕你只改一行，整张表在锁释放前都无法写入。对于线上业务表，但凡有并发写入，MyISAM几乎是不可用的。但InnoDB也不是全无代价，它的索引组织方式是聚簇索引，也就是数据按照主键顺序物理存储，这意味着：

插入数据如果主键不是自增的而是随机的UUID，会导致页分裂，写入性能大幅下降
二级索引查询时，如果SELECT的列不在索引里，需要回表查主键再定位数据行，这个回表动作在高频查询下会放大IO损耗

我经手过的项目里，凡是后期表操作痛苦不堪的，几乎都踩过这两个雷。不是引擎选错了，而是没搞懂引擎特性导致建表时埋下了雷。

所以建表前第一件事，不是写CREATE TABLE语句，而是先问自己几个问题：这张表的写入模式是追加多还是更新多？并发程度怎么样？是否需要跨行事务？如果答案是"写入频繁并且并发不低"，直接走InnoDB，不用犹豫。

2.2 字符集与排序规则，看似最不起眼却最容易翻车

字符集选错导致的乱码问题，是每个MySQL使用者都绕不过去的一道坎。但比乱码更隐蔽的坑，是排序规则不一致导致的关联查询失败或索引失效。

MySQL的utf8mb4字符集下，排序规则常见的有utf8mb4_general_ci和utf8mb4_unicode_ci。前者速度快但排序精度一般，后者更符合Unicode标准。两张表关联查询时，如果关联字段的排序规则不同，MySQL可能无法使用索引，甚至直接报"Illegal mix of collations"错误。这个报错我在线下环境遇到过不止一次，原因往往是不同时期建的表用了不同的默认字符集配置。

规范化做法是：整个实例统一使用utf8mb4和utf8mb4_unicode_ci，并且建库、建表、建字段时都显式指定。有人觉得显式指定啰嗦，但比起线上数据出现乱码再想办法修复，建表时多敲几个字符的成本几乎可以忽略。

2.3 字段类型选型的几个现实原则

字段类型的选择是数据表操作中最能看出功力的环节。同一个业务含义的字段，用INT、BIGINT还是VARCHAR，后期性能和存储成本差异很大。

有几个原则我实践下来非常稳：

尽量用数字类型存储数字。电话号码不要用INT，因为可能超出范围或者出现前导零，建议用VARCHAR配合格式校验。但状态码、枚举值这类纯数字，用TINYINT或INT即可。
金额字段用DECIMAL，不用FLOAT或DOUBLE。浮点类型在比较和聚合时会出现精度偏移，曾经有个财务系统的对账逻辑因此差了几分钱，排查了整整一个下午。
时间字段优先用DATETIME或TIMESTAMP，不要用VARCHAR存时间字符串，否则排序和范围查询都会变得低效。TIMESTAMP有2038年问题，DATETIME没有，根据业务生命周期选择。
大文本字段不要直接塞在主表里，宁可拆出子表或者用单独存储。之前处理过一个用户反馈表，每条反馈附带了上千字的JSON日志，直接导致主表行均大小飙升，缓冲池命中率下降。

这些都是建表时的"合同条款"，后期再改的成本远高于一开始多思考几分钟。

3. 一套完整动作演练：设计、建表、数据操作到查询优化的推进路径

3.1 从需求到字段清单，以一个成绩表为例

为了让这套动作可复现，我用一个比较经典的学生课程成绩场景来走一遍流程。需求是：记录学生的基本信息、所选课程以及每次考试的成绩，并能支撑"查询某门课排名前N的学生""统计某个学生的平均分"这类业务。

很多初学者上来就建一张大宽表，把所有信息放进去。这种方式在数据量小的时候没问题，但成绩数据会不断累加，宽表更新频率高且容易出现数据冗余。更合理的做法是拆成学生表、课程表、成绩表三张表，其中成绩表作为关联核心。

学生表字段可以是：student_id、student_name、class_name、enroll_year。课程表字段可以是：course_id、course_name、teacher_name、credit。成绩表字段至少包括：id、student_id、course_id、score、exam_time，并且把student_id和course_id作为联合索引，这样可以高效支撑按学生查成绩和按课程查排名的场景。

这个设计的关键在于：成绩表的主体是"某学生在某次考试中选某门课得了多少分"，它天然是一个关系实体，而不是学生属性或课程属性的延伸。把变化频率高的事实（成绩）和相对稳定的描述信息（学生、课程）分开，是表结构设计的核心逻辑。

3.2 建表SQL怎么写才不容易返工

下面是这个成绩表体系的建表示例，附带实践中验证过的参数习惯：

sql复制CREATE DATABASE IF NOT EXISTS school_system 
DEFAULT CHARACTER SET utf8mb4 
DEFAULT COLLATE utf8mb4_unicode_ci;

USE school_system;

CREATE TABLE student (
    student_id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '学号ID',
    student_name VARCHAR(50) NOT NULL COMMENT '姓名',
    class_name VARCHAR(100) NOT NULL DEFAULT '' COMMENT '班级',
    enroll_year SMALLINT UNSIGNED NOT NULL DEFAULT 0 COMMENT '入学年份',
    created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
    updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
    PRIMARY KEY (student_id),
    KEY idx_class (class_name)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci COMMENT='学生表';

几个容易被忽视的细节：

student_id用了BIGINT UNSIGNED而不是INT。学生量级可能达不到几十亿，但使用自增主键时，只要发生过删除操作，AUTO_INCREMENT就不会回退，INT的上限没那么遥远，直接给BIGINT更省心。
updated_at用ON UPDATE CURRENT_TIMESTAMP，这样应用层不需要每次修改都手动维护这个字段。这个习惯在需要排查数据变更时间线时特别有用。
所有表都显式加上ENGINE、CHARSET、COLLATE和COMMENT。COMMENT看似不起眼，但半年后回头看表结构时，没有注释的字段会让人抓狂。

成绩表的建表SQL要更谨慎一些，因为成绩表是高频写入和查询的对象：

sql复制CREATE TABLE exam_score (
    id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '主键',
    student_id BIGINT UNSIGNED NOT NULL COMMENT '学生ID',
    course_id BIGINT UNSIGNED NOT NULL COMMENT '课程ID',
    score DECIMAL(5,2) NOT NULL COMMENT '成绩，保留两位小数',
    exam_time DATETIME NOT NULL COMMENT '考试时间',
    created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
    PRIMARY KEY (id),
    UNIQUE KEY uk_student_course_time (student_id, course_id, exam_time),
    KEY idx_course_score (course_id, score),
    CONSTRAINT fk_student FOREIGN KEY (student_id) REFERENCES student(student_id),
    CONSTRAINT fk_course FOREIGN KEY (course_id) REFERENCES course(course_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci COMMENT='考试成绩表';

唯一键uk_student_course_time在这里的作用是确保同一位学生在同一门课的同一场考试中不会被重复录入。联合索引idx_course_score则直接支撑"按课程查排名"这类高频查询，让排序和范围筛选可以在索引内完成而不需要回表。

3.3 排序、去重与int+N这类细节背后的执行逻辑

表建好之后，日常数据操作中有些看似简单的问题，其实暗藏执行逻辑层面的差异。

先说排序。ORDER BY在数据量大时如果走了文件排序（filesort），性能会明显下降。让ORDER BY走索引的方式是：排序字段的方向和索引定义一致，并且WHERE条件里用到的等值字段尽量作为索引前缀。举个例子，idx_course_score(course_id, score)这个索引，执行"WHERE course_id = 1 ORDER BY score DESC"时可以直接从索引倒序扫描，但如果业务需要"按班级分组后按成绩排序"，索引就无能为力了。

再说去重。MySQL里DISTINCT和GROUP BY都能去重，但语义和执行路径不同。想统计"有哪些学生参加了考试"，用SELECT DISTINCT student_id FROM exam_score没问题。但如果同时要带出学生的其他信息，直接写SELECT student_id, student_name FROM ... GROUP BY student_id会触发ONLY_FULL_GROUP_BY报错。这类查询正确的思路是先确定你想保留的列，再用聚合函数或子查询处理。

顺便回答一个常见的疑惑："mysql的or能去重吗"。OR条件本身不具备去重能力，它只负责扩展匹配范围。比如WHERE course_id = 1 OR course_id = 2，结果中两门课都选的学生会各自出现在结果集里，这取决于你的查询意图。如果是想要去重的集合，应该用UNION而不是OR。如果把OR条件改成IN (1,2)，执行计划通常也会转为更高效的索引范围扫描。

关于mysql中int+5这个搜索词，我猜很多时候是有人在看数据类型对运算的影响。INT类型加5在SQL里直接写UPDATE table SET field = field + 5即可，但如果字段类型是VARCHAR，MySQL会做隐式转换。隐式转换看起来不报错，但会导致索引无法正常使用。我在一个日志表上遇到过一次，字段是VARCHAR存的数字序列，按范围查询时执行计划直接走了全表扫描，就是因为隐式转换。所以字段类型设计规范化，不只是在存储层面有意义，在查询优化层面同样关键。

3.4 NULL值对聚合和索引的干扰

成绩表中如果允许score为NULL，会出现一个很容易误判的问题：AVG(score)不会把NULL行计算在内，但COUNT(score)也不会统计NULL行，而COUNT(*)会统计所有行。同一个字段在不同函数下统计口径不一致，就会产生报表数据对不上的情况。

我建议成绩字段设计为NOT NULL，如果某位学生缺考，用单独的状态字段标记。这比让成绩为NULL干净得多。处理历史数据时，如果已经有NULL混入，查询时要主动用COALESCE或IS NULL进行显式处理，不要指望默认行为符合业务直觉。

4. 结构变更不是执行一条ALTER那么简单，连锁反应必须提前预判

4.1 加字段不一定锁全表，但线上操作必须谨慎

MySQL 8.0之前的版本里，ALTER TABLE ADD COLUMN在大部分情况下会触发表级拷贝，意味着操作执行期间这张表无法正常写入。即使MySQL 8.0支持了INSTANT算法，能够瞬间添加某些字段，也不意味着所有ALTER操作都能原地完成。修改字段类型、修改字符集、重建索引这类操作仍可能需要拷贝数据或重建表。

线上环境做表结构变更，我的习惯是至少留足三倍操作耗时的缓冲窗口，并用低峰期执行。有一个比较实用的工具是pt-online-schema-change，它通过创建影子表、同步增量数据、切换表名来避免长时间锁表。如果不想引入额外工具，也可以用原生ALTER带着ALGORITHM和LOCK参数，先评估出允许的执行方式，再决定是否继续。

4.2 修改字段类型之后，索引和数据格式都要重新审视

把VARCHAR(50)改成VARCHAR(200)通常代价不大，但把VARCHAR改成TEXT，或者把INT改成BIGINT，就可能改变索引的大小和排序行为。特别是当这个字段是索引的一部分时，索引重建耗时和数据文件膨胀都不可避免。

一个真实的案例：有张用户表，手机号字段原本是VARCHAR(20)，因为业务扩展需要存储座机号码加区号，长度扩展到VARCHAR(30)。ALTER执行完主流程只花了十几秒，但紧接着发现关联查询延迟上升。原因是这个字段上有一个二级索引，字长变大后索引页能容纳的键值数量变少，树的高度虽然没有立刻变化，但缓冲池里能缓存的索引项明显减少，IO次数上去了。

所以结构变更不只是看"语句能不能跑完"，还要在变更后观察一段时间的慢查询和缓冲池命中率。如果发现性能回退，优先考虑调整索引结构或用前缀索引缩小索引体积。

4.3 唯一索引与重复数据清理的前后关系

热搜词里有一条"mysql设置唯一已经有重复数据库"，对应的场景很常见：表里已经存在重复数据，这时候直接给字段加唯一索引会失败。正确做法是先把重复数据清理掉，再加唯一索引。

具体步骤可以这样：

sql复制-- 1. 找出重复的记录ID，保留每组中最小的那个ID
SELECT MIN(id)
FROM exam_score
GROUP BY student_id, course_id, exam_time
HAVING COUNT(*) > 1;

-- 2. 删除重复记录，这里以临时表方式避免误删
CREATE TEMPORARY TABLE tmp_keep AS 
SELECT MIN(id) AS keep_id
FROM exam_score
GROUP BY student_id, course_id, exam_time;

DELETE FROM exam_score
WHERE id NOT IN (SELECT keep_id FROM tmp_keep);

-- 3. 添加唯一索引
ALTER TABLE exam_score ADD UNIQUE KEY uk_unique(student_id, course_id, exam_time);

删除重复数据前务必先备份，或者至少用SELECT先确认影响行数。这个操作一旦误删，在没有备份的情况下非常难恢复，尤其是数据表可能还承载着业务实时写入。

5. 死锁不是随机事件，一次完整排查链路能避免同款问题反复出现

5.1 从报错到锁等待，先弄清死锁发生的必备条件

MySQL的死锁日志看起来吓人，满屏的事务ID和行锁信息，但本质上要发生死锁必须满足四个条件：互斥、持有并等待、不可剥夺、循环等待。在InnoDB的加锁机制里，最容易引发的场景就是两个事务以不同顺序锁定同一组行记录。

比如事务A先更新成绩表中student_id=1的记录，再更新student_id=2的记录；事务B刚好相反，先更新student_id=2，再更新student_id=1。当两个事务同时执行时，就可能互相持有对方需要的行锁不放，最终InnoDB的检测机制介入，回滚其中一个事务。

这种场景在业务代码里很容易出现。批量更新时如果每次加载的数据顺序不一致，而SQL又按主键从小到大去更新，冲突会明显减少。让所有更新都按照固定顺序执行，是规避死锁最有效、成本最低的手段。

5.2 死锁日志怎么读，具体排查步骤复盘

有一次线上出现死锁，我按如下链路定位：

第一步，开启死锁日志输出。用SHOW ENGINE INNODB STATUS查看最近一次死锁的详细信息。日志中LATEST DETECTED DEADLOCK段落记录了发生死锁的时间、两个事务的执行SQL以及持有的锁。

第二步，从日志里确定两个事务的SQL形态。当时的场景是批量更新用户积分。事务1执行UPDATE user_score SET score = score + 10 WHERE user_id = 101，事务2执行UPDATE user_score SET score = score - 5 WHERE user_id = 100。表面看两个事务没有交集，但在批量任务调度里，事务1的批里还包含user_id = 100的更新，事务2的批里也包含user_id = 101。日志中显示的只是当前语句，而事务本身可能已经持有其他行锁。这就解释了为什么两条看起来不相干的SQL发生了死锁。

第三步，检查代码中的事务边界。问题出在一个批量任务里，循环体内开启了事务，每次更新没有立即提交，而是等一批数据全部处理完才提交。事务持有行锁的时间被人为拉长，死锁概率自然上升。修复方式是把大事务拆小，每处理一条或一小批就提交一次，并且在代码里捕获死锁异常后做重试。

从这次排查中总结出的通用排查顺序是：先看两条SQL涉及的数据行是否有重叠，再看事务边界是否过长，再看更新顺序是否一致。三步走完，80%以上的死锁问题都能找到根因。

5.3 减少死锁的几条实操习惯

更新SQL尽量走主键或唯一索引，让锁定的行范围最小化。
批量任务控制每次事务处理的行数，建议不超过200条，避免一次锁太多行。
如果业务允许，更新前先按主键排序，保证所有并发任务以相同的顺序访问行。
逻辑层做好重试机制，捕获死锁异常后延迟100~200毫秒再次执行，不要直接把异常抛给用户。
隔离级别默认是REPEATABLE READ，如果业务对一致性要求允许，可以考虑降低到READ COMMITTED，减少间隙锁带来的锁冲突。

6. 工具链辅助下的表级审视，从Workbench到系统表查询

6.1 用Workbench把表结构、索引和ER关系可视化

MySQL Workbench是官方提供的基础但好用的图形化工具。它的价值不只是能双击看数据，更多体现在把表结构设计变成可视化模型。

在Workbench里通过Database菜单选择Reverse Engineer，可以连接已有数据库并自动生成ER关系图。外键关系会以连线形式呈现，谁依赖谁一目了然。面对遗留系统时，这个功能帮助极大。早期我接手一个老项目，数据库里有一百多张表，代码文档早就过时了，靠Reverse Engineer生成关系图后才理清楚表之间的完整链路。

从ER图反向审视还能发现一些设计问题，比如某张表完全没有外键关系，但字段命名像是别的表ID，这时候就要查一下是不是漏建了外键，或者业务代码里正在做隐式关联。外键在实际开发中有人为了性能故意不用，但至少可视化时能看出表之间的参照依赖关系，才能在改表时评估影响面。

6.2 用information_schema做表级体检

information_schema是MySQL内置的元数据数据库，几乎所有的表结构操作审查都可以从这里拿数据。

我经常用的几个查询：

sql复制-- 查看某张表的索引情况
SELECT index_name, column_name, seq_in_index, non_unique
FROM information_schema.statistics
WHERE table_schema = 'school_system' AND table_name = 'exam_score'
ORDER BY index_name, seq_in_index;

-- 查看每张表的行数估计和数据大小，判断哪些表需要优化
SELECT table_name, table_rows, data_length, index_length
FROM information_schema.tables
WHERE table_schema = 'school_system'
ORDER BY data_length DESC;

information_schema的table_rows是估算值，不等同于精确的COUNT(*)，但用来比较各表的规模量级足够了。通过体检可以发现冗余索引、重复索引和长时间未使用的大表，从而制定下一步的整理方案。

还有一个容易忽略的字段是LAST_CHECK_TIME和LAST_OPTIMIZE_TIME，如果某张表长时间没有做优化，而它的碎片率很高，就该考虑执行OPTIMIZE TABLE来回收空间。

6.3 从EXPLAIN看表操作的真实执行代价

EXPLAIN是数据分析师和开发者的眼睛。写一条SQL，前面加EXPLAIN，就能看到这条查询用了哪个索引、扫描了多少行、是否回表、是否产生了临时表。

初学者看EXPLAIN最容易犯的错误是只盯着type列。比如type显示ref就已经很高兴，但忽略了extra列里的"Using filesort"和"Using temporary"，这两个信号一旦出现，说明排序或去重没有用好索引，数据量稍微上来一点就会成为性能瓶颈。

我自己习惯把EXPLAIN的每个关键列都过一遍：type要尽量达到ref或range，rows要足够小，filtered要合理，extra里尽量不要有Using temporary。遇到extra里有"Using index condition"时，说明索引下推能力被用起来了，通常是一个不错的信号。

给一个实际排查案例：一条成绩统计SQL执行了1.2秒，EXPLAIN发现走了course_id索引，但extra显示Using where。原因是索引只覆盖了course_id和score，而WHERE里还带了exam_year(dt)这样的范围条件，无法完全用索引过滤所有条件。调整方式是新建一个(course_id, exam_time, score)的复合索引，把这几个条件全部塞进索引列里，执行时间降到80毫秒。

6.4 数据同步和异构迁移场景下的表级注意事项

如果工作涉及数据同步或异构数据库迁移，表操作更要注意兼容性。例如把SQLServer或PostgreSQL的数据同步到MySQL时，数据类型映射是一个高频踩坑点。SQLServer的datetime2精度比MySQL的DATETIME高，同步时如果目标列是DATETIME，可能出现精度截断。PostgreSQL的布尔类型直接搬到MySQL可以用TINYINT(1)，前提是业务SQL里没有依赖原生BOOLEAN语义。

大数据量同步通常走DataX这类工具，里面可以配置通道并发数和批量大小。但比调并发更重要的，是同步前先核对两张表的唯一键和边界值，否则很容易出现重复数据。目标端是MySQL时，建议先把表上的非必要索引删掉，等数据同步完成后再批量建索引，这样可以节省大量写入时间。原因很简单，每一条INSERT都要同步维护所有二级索引，索引越多写入越慢。

7. 数据表操作中那些一旦养成就能少熬夜的现场习惯

最后这部分是纯粹的经验之谈。回顾这几年处理过的所有表结构问题，发现最后救命或者害人的，往往不是某条SQL写得好不好，而是操作前有没有一套固定习惯。

第一个习惯是永远先备份。不管只是加个索引，还是清掉重复数据，都要在测试环境先跑一遍脚本，确认影响行数符合预期，再复制到生产环境。若生产环境数据量特别大，不要直接备份整库，至少把目标表做一个逻辑导出。

第二个习惯是变更脚本要版本化，不要随手在服务器上敲ALTER。项目里维护一个sql目录，每次结构变更都是独立的SQL文件，命名规范如V20250510_001_add_score_index.sql，提交到Git里与代码一起发布。这样出问题时能准确知道哪个版本的代码对应哪个表结构，也不会出现测试环境改了表、生产环境忘改的尴尬。

第三个习惯是给每个字段都写COMMENT，并且表注释里说明这张表的用途和维护负责人。数据库是团队资产，你写的注释未来可能是别人排查问题的唯一线索。

第四个习惯是慢查询日志要定期看一眼。数据表结构和索引到底合不合理，不能只看设计时的理想要求，要拿真实查询说话。通过mysqldumpslow工具或者直接查performance_schema里的events_statements_summary_by_digest，可以快速定位哪些SQL在反复触碰性能瓶颈。

关于MySQL数据表操作，能写的内容远不止命令本身。它既涉及从业务抽象出实体的建模能力，又涉及对底层存储引擎和索引机制的深刻理解，还涉及在线上环境做变更时的工程素养。把这些能力沉淀成一套固定的执行框架，比背下再多语法都更有价值。有些坑踩过一次之后只要养成对应习惯就不再犯，比如涉及重复数据先备份、加锁更新固定顺序、上线前看EXPLAIN、变更脚本走版本管理。这些习惯初看都会增加一点操作成本，但反馈到你节省的熬夜排查时间上，成本几乎可以忽略。