MySQL实战能力地图：从八股文到生产级诊断与优化

1. 项目概述：这不是背诵清单，而是一张MySQL实战能力地图

“MySQL篇八股文总结”——看到这个标题，很多刚接触数据库的开发者第一反应是：又要硬啃一堆面试题了？但作为在数据库领域摸爬滚打十多年、亲手调优过上万张表、处理过单日亿级写入峰值、也踩过主从延迟跳变到30分钟这种坑的从业者，我必须说：把MySQL“八股文”当成孤立知识点去死记硬背，是效率最低、风险最高的学习方式。它真正该扮演的角色，是一张可执行、可验证、可延展的MySQL能力地图。这张地图上标出的不是标准答案，而是你日常开发、运维、排查中必然要穿越的关卡：为什么COUNT(*)比COUNT(列)快？为什么加了索引查询反而变慢？为什么事务里SELECT ... FOR UPDATE锁住的不止查询行？这些所谓“八股”，本质是MySQL内核机制在真实场景下的投影。关键词“MySQL”“八股文”“总结”背后，藏着三类核心需求：一是应届生/转行者需要快速建立系统性认知框架，避免被碎片化教程带偏；二是中级工程师急需厘清模糊地带（比如隔离级别与锁机制的耦合关系），为复杂业务建模打基础；三是DBA或后端负责人需要一套可落地的自查清单，用于新项目评审、慢查治理和故障复盘。这篇文章不提供“标准答案速查表”，而是带你一层层剥开现象，还原MySQL在磁盘、内存、网络、事务、并发这五个维度的真实工作逻辑。你可以把它当作一份“操作手册”，当遇到ORDER BY失效、GROUP BY结果异常、INSERT卡顿等问题时，直接翻到对应章节，按步骤验证、定位、解决。它不承诺让你秒过面试，但能确保你在生产环境里，面对一条SQL、一个连接、一次主从同步中断，心里有底、手里有招。

2. 内容整体设计与思路拆解：从“考什么”转向“怎么用”

2.1 为什么放弃传统“问答罗列式”结构？

市面上绝大多数MySQL“八股文”资料，采用的是“Q&A”线性堆砌：Q1：什么是事务？A1：ACID……Q2：什么是索引？A2：B+树……这种结构看似清晰，实则暗藏巨大陷阱。我曾辅导过一位在某电商公司做订单系统的工程师，他能把所有八股答案倒背如流，但当线上出现“支付成功但订单状态未更新”的问题时，却花了三天时间才定位到是应用层事务传播配置错误，而非数据库本身故障。问题出在哪？——问答式结构割裂了知识的上下文。事务的ACID特性，必须放在“高并发下单扣减库存”这个具体场景里理解；索引的B+树结构，只有结合“WHERE user_id = ? AND status = 'paid' ORDER BY create_time DESC LIMIT 20”这条真实SQL的执行计划，才能看清为什么联合索引顺序如此关键。因此，本总结彻底摒弃Q&A，采用场景驱动+机制穿透双主线：每个核心模块（连接、查询、事务、索引、复制）都以一个高频、高危、易错的真实场景切入，再层层下钻到存储引擎、锁管理器、查询优化器等内核组件的工作原理，最后回归到可验证的诊断命令和修复动作。例如，讲“隔离级别”不从定义开始，而是先抛出场景：“用户A在APP里提交退款申请，用户B同时在后台将该订单标记为‘已发货’，最终数据库里这笔订单的状态是什么？”——这个场景天然引出读写冲突、幻读判定、锁粒度选择等一系列深层问题。

2.2 为什么聚焦InnoDB而非MyISAM或其他引擎？

MySQL支持多种存储引擎，但当前95%以上的生产环境核心业务表，几乎全部运行在InnoDB之上。原因非常务实：MyISAM的表锁在高并发下是性能黑洞，且不支持事务和外键；Memory引擎数据全在内存，宕机即失；NDB集群版部署复杂，生态支持弱。InnoDB成为事实标准，不是因为它“完美”，而是因为它在事务可靠性、并发性能、崩溃恢复能力三者间取得了最平衡的工程解。因此，本总结所有技术点均默认基于InnoDB引擎展开，所有参数、命令、现象分析，都指向InnoDB特有的机制。比如，讨论“MVCC多版本并发控制”时，会深入到InnoDB的undo log段如何组织、read view结构如何生成、DB_TRX_ID和DB_ROLL_PTR两个隐藏字段如何协同工作；分析“锁”时，会明确区分InnoDB的记录锁（Record Lock）、间隙锁（Gap Lock）、临键锁（Next-Key Lock）各自触发条件及对SELECT ... FOR UPDATE、UPDATE、DELETE语句的实际影响。这种聚焦，避免了初学者在不同引擎特性间混淆，也确保了所学内容能直接映射到你的生产环境。

2.3 为什么强调“可验证性”而非“理论正确性”？

数据库是典型的“实践科学”。一个理论正确的结论，如果无法通过EXPLAIN、SHOW ENGINE INNODB STATUS、performance_schema等工具实时观测、验证，那它对工程师的价值就大打折扣。因此，本总结中每一个核心论断，都配套提供最小化可复现的验证步骤。例如，要理解“为什么SELECT * FROM t WHERE id = 1走索引，而SELECT * FROM t WHERE id > 1可能不走索引”，不会只讲“范围查询导致索引失效”这种模糊说法，而是给出具体操作：

1. 创建一张测试表t(id INT PRIMARY KEY, name VARCHAR(50))，插入10万行数据；
2. 执行EXPLAIN SELECT * FROM t WHERE id = 1，观察key列为PRIMARY，rows为1；
3. 执行EXPLAIN SELECT * FROM t WHERE id > 1，观察key列仍为PRIMARY，但rows变为约5万（全索引扫描）；
4. 进一步执行SELECT COUNT(*) FROM t WHERE id > 1，对比SELECT COUNT(*) FROM t的执行时间差异。
   这种“理论-命令-现象-归因”的闭环，确保你学到的不是教科书定义，而是手边就能用的诊断技能。这也是为什么文中大量穿插mysql>命令行示例、information_schema查询语句、sys库视图调用——它们不是装饰，而是你每天打开终端就要敲的代码。

3. 核心细节解析与实操要点：穿透表象，直击内核机制

3.1 连接层：不只是“连上就行”，而是资源消耗的起点

MySQL的连接（Connection）远非一个简单的TCP握手。每个客户端连接，在服务端都会创建一个独立的线程（Thread）或协程（取决于版本和配置），并分配专属的内存空间，包括：

• 线程栈（Thread Stack）：默认192KB，用于存储函数调用栈、局部变量。若应用使用长连接且频繁调用深度递归存储过程，此值可能成为瓶颈；
• 排序缓冲区（sort_buffer_size）：每个连接独享，用于ORDER BY、GROUP BY的内存排序。默认256KB，若EXPLAIN显示Using filesort，且sort_buffer_size设置过小，会导致大量磁盘临时文件IO；
• JOIN缓冲区（join_buffer_size）：用于无索引关联的嵌套循环连接（Nested Loop Join）。默认256KB，若EXPLAIN显示Using join buffer (Block Nested Loop)，且关联数据量大，此缓冲区不足会引发多次全表扫描。

提示：sort_buffer_size和join_buffer_size是每个连接独占的内存，而非全局共享。这意味着，若你的应用最大连接数max_connections设为1000，而这两个参数均为2MB，则仅这两项就需消耗2GB内存（1000 × 2MB），极易触发OOM Killer。这是线上最常见的内存泄漏式误配。

实操中，必须通过SHOW PROCESSLIST和performance_schema.threads实时监控连接状态。重点关注Command列（Sleep表示空闲连接，Query表示正在执行，Locked表示被锁阻塞）和Time列（Sleep状态持续时间过长，往往是应用未正确关闭连接）。一个经典案例：某SaaS平台凌晨批量任务后，Threads_connected持续维持在800+，远超日常峰值300，SHOW PROCESSLIST发现大量Sleep连接Time值超过3600秒。根因是应用层连接池配置了minIdle=100，但未设置maxIdle和removeAbandonedOnBorrow=true，导致空闲连接永不释放。解决方案并非简单调大wait_timeout，而是修正连接池策略，并配合pt-kill工具自动清理超时Sleep连接。

3.2 查询优化器：你的SQL，它真的“懂”吗？

MySQL查询优化器（Query Optimizer）的核心任务，是为一条SQL生成成本最低的执行计划（Execution Plan）。但它不是AI，而是一个基于统计信息和启发式规则的“经验派工程师”。其决策高度依赖两个关键输入：

• 表的统计信息（Table Statistics）：由ANALYZE TABLE命令收集，存储在information_schema.STATISTICS和mysql.innodb_table_stats中，包含行数（cardinality）、索引分布等。若统计信息陈旧（如大表INSERT百万行后未ANALYZE），优化器会误判索引选择性，导致本该走索引的查询走了全表扫描；
• 成本常量（Cost Constants）：如disk_sweep_cost（磁盘扫描单位成本）、memory_read_cost（内存读取单位成本），定义在mysql.server_cost和mysql.engine_cost表中。这些值决定了优化器如何权衡“走索引+回表”与“直接全表扫描”的成本。

一个典型误区是认为“加了索引就一定走”。实测案例：一张用户表users(id, name, city, age)，在(city, age)上建联合索引。执行SELECT * FROM users WHERE city = 'Beijing' AND age > 25，EXPLAIN显示type=range，走索引；但执行SELECT * FROM users WHERE city = 'Beijing' AND age > 18，EXPLAIN却显示type=ALL，全表扫描。原因在于：age > 18匹配行数过多（假设北京用户平均年龄30，此条件覆盖90%数据），优化器计算出“走索引+回表”的总成本高于“全表扫描”，故主动放弃索引。此时，FORCE INDEX(city_age)强制走索引反而是更差选择，因为会引发海量随机IO。正确解法是：ANALYZE TABLE users更新统计信息，或调整optimizer_switch='index_merge=on'启用索引合并。

注意：EXPLAIN的rows列是优化器预估的扫描行数，非实际值。要获取真实扫描行数，必须开启performance_schema并查询events_statements_summary_by_digest，或使用SET profiling = 1;后执行SHOW PROFILES。预估偏差过大，往往是统计信息不准或优化器模型缺陷的信号。

3.3 事务与锁：ACID不是口号，是每一行数据的生死契约

InnoDB的事务实现，是redo log（重做日志）、undo log（回滚日志）、buffer pool（缓冲池）和lock system（锁系统）四者精密协作的结果。理解它们，是解决“死锁”、“长事务阻塞”、“主从延迟”的基石。

• redo log：保证持久性（D）的“保险单”
  redo log是物理日志，记录“在某个数据页的某个偏移量，写入了什么内容”。其核心价值在于：将随机写IO转化为顺序写IO。当UPDATE一条记录时，InnoDB先将变更写入redo log buffer（内存），再刷盘到ib_logfile*（磁盘），最后才异步刷脏页到ibdata（数据文件）。这意味着，即使数据库崩溃，只要redo log完整，重启后就能通过重放日志恢复所有已提交事务。innodb_log_file_size（默认48MB）和innodb_log_files_in_group（默认2）共同决定redo log总容量。若总容量过小（如共128MB），在高并发写入场景下，log sequence number (LSN)追不上checkpoint，会触发log checkpoint阻塞，导致UPDATE响应时间飙升。实测建议：redo log总容量应至少能容纳1小时的写入量。计算公式：总容量(MB) ≥ (每秒写入量KB × 3600) / 1024。例如，监控到Innodb_os_log_written每秒增长2MB，则redo log总容量应≥7200MB。

• undo log：实现隔离性（I）和原子性（A）的“时光机”
  undo log是逻辑日志，记录“如何撤销一个操作”。例如，DELETE一条记录，undo log会记录“INSERT 回这条记录”；UPDATE一个字段，undo log会记录“UPDATE 回旧值”。undo log不仅用于事务回滚，更是MVCC的基石。当一个事务以REPEATABLE READ隔离级别执行SELECT时，InnoDB会根据该事务启动时生成的read view，从undo log链中找到对应版本的数据。innodb_undo_tablespaces（默认2）和innodb_undo_log_truncate（默认ON）控制undo log的存储和自动清理。若undo log表空间长期不清理，会占用大量磁盘空间，且purge线程压力剧增，拖慢整个实例性能。

• 锁机制：并发安全的“交通警察”
  InnoDB的锁不是简单的“行锁”或“表锁”，而是一套精细的分级体系：

  • 记录锁（Record Lock）：锁定索引记录本身，如SELECT * FROM t WHERE id = 10 FOR UPDATE；
  • 间隙锁（Gap Lock）：锁定索引记录之间的“间隙”，防止幻读，如SELECT * FROM t WHERE id BETWEEN 10 AND 20 FOR UPDATE会锁住(10,20)这个区间；
  • 临键锁（Next-Key Lock）：记录锁 + 间隙锁的组合，是REPEATABLE READ默认的行锁模式，如SELECT * FROM t WHERE id > 10 FOR UPDATE会锁住(10, +∞)。
    死锁检测是InnoDB的自动能力，但预防才是王道。核心原则：所有事务按相同顺序访问表和行。例如，订单系统中，若A事务先更新order表再更新payment表，B事务却先更新payment再更新order，死锁概率极高。解决方案是统一业务逻辑，或在应用层对关联资源加分布式锁。

4. 实操过程与核心环节实现：从命令到现象，构建完整诊断链

4.1 慢查询治理：不是优化SQL，而是优化“问题发现-定位-修复”闭环

慢查询（Slow Query）是数据库性能问题的“显性症状”，但其背后成因千差万别。一个高效的治理流程，必须覆盖“捕获-分析-验证-固化”四个环节。

第一步：精准捕获（Capture）
启用慢查询日志是基础，但关键在参数调优：

• slow_query_log = ON：开启日志；
• long_query_time = 1.0：阈值设为1秒（而非默认10秒），避免漏掉大量“亚秒级”但高频的慢查询；
• log_queries_not_using_indexes = ON：记录所有未走索引的查询，这是索引设计缺陷的直接证据；
• slow_query_log_file = /var/log/mysql/slow.log：指定日志路径，确保磁盘空间充足。

注意：long_query_time是执行时间，不包括等待锁的时间。若一条SQL因锁等待耗时5秒，但实际执行仅0.1秒，它不会被记录为慢查询。此时需结合performance_schema.events_waits_history_long查找锁等待事件。

第二步：深度分析（Analyze）
mysqldumpslow是入门工具，但生产环境必须用pt-query-digest（Percona Toolkit）：

pt-query-digest /var/log/mysql/slow.log --limit 10 --report-format json > report.json

它能聚合相似SQL（忽略WHERE后的字面值差异），统计Count（执行次数）、Exec time（总执行时间）、Rows sent（返回行数）、Rows examine（扫描行数）等关键指标。重点关注Rows examine / Rows sent比值，若远大于1（如1000:1），说明存在严重“扫描浪费”，需检查索引覆盖是否完整。

第三步：现场验证（Verify）
对pt-query-digest识别出的Top SQL，必须在生产库（或影子库）上EXPLAIN验证：

• 检查type列：ALL（全表扫描）、index（全索引扫描）是危险信号；
• 检查key列：是否使用了预期索引；
• 检查Extra列：Using filesort（需排序但无合适索引）、Using temporary（需临时表）、Using where; Using index（索引覆盖，最优）；
• 检查rows列：是否与pt-query-digest报告的Rows examine接近，若偏差巨大，说明统计信息陈旧。

第四步：方案固化（Solidify）
优化不是一锤子买卖。必须将有效方案固化为可审计、可追踪的流程：

• 对新增索引，执行ALTER TABLE t ADD INDEX idx_city_age (city, age)后，立即用SELECT * FROM sys.schema_index_statistics WHERE table_name = 't'验证索引使用率；
• 对修改long_query_time等参数，必须通过SET PERSIST long_query_time = 1.0（MySQL 8.0+）使其永久生效，并记录在配置管理平台；
• 建立“慢查询周报”，向研发团队同步Top 5慢查询、优化措施及效果（如Rows examine下降90%），形成持续改进文化。

4.2 主从复制：不只是“数据同步”，更是可用性与一致性的生命线

MySQL主从复制（Replication）是高可用架构的基石，但其稳定性高度依赖对底层机制的理解。

复制延迟（Replication Lag）的根因分析
Seconds_Behind_Master是常用指标，但它是“黑盒”值。真正要深挖的是SHOW SLAVE STATUS中的三个关键位点：

• Read_Master_Log_Pos：从库IO线程读取到主库binlog的哪个位置；
• Exec_Master_Log_Pos：从库SQL线程执行到主库binlog的哪个位置；
• Relay_Log_Pos：从库SQL线程在中继日志（relay log）中的执行位置。

延迟的本质，是Exec_Master_Log_Pos追不上Read_Master_Log_Pos。常见原因：

• 主库写入压力过大：主库binlog写入速度远超从库SQL线程执行速度。解决方案：升级从库硬件，或启用slave_parallel_workers > 0（MySQL 5.7+）开启并行复制；
• 从库SQL线程单点瓶颈：即使开启了并行复制，DDL语句（如ALTER TABLE）仍会强制串行执行。解决方案：将大DDL操作安排在低峰期，或使用pt-online-schema-change工具在线改表；
• 网络抖动或IO瓶颈：Read_Master_Log_Pos增长缓慢，说明IO线程受阻。检查从库磁盘IO等待（iostat -x 1）和网络延迟（ping、mtr）。

GTID（Global Transaction Identifier）的实践价值
GTID是MySQL 5.6引入的复制增强特性，格式为source_id:transaction_id（如a1b2c3d4-5678-90ab-cdef-1234567890ab:1）。其核心优势在于：

• 故障切换零丢失：主库宕机后，从库可通过SELECT MASTER_POS_WAIT('a1b2c3d4-5678-90ab-cdef-1234567890ab', 100)精确等待到指定GTID，确保切换后数据完全一致；
• 跳过错误更安全：传统SET GLOBAL sql_slave_skip_counter=1可能跳过关键事务，而gtid_next可精准跳过单个GTID，如SET GTID_NEXT='a1b2c3d4-5678-90ab-cdef-1234567890ab:100'; BEGIN; COMMIT; SET GTID_NEXT='AUTOMATIC';。

实操心得：启用GTID前，必须确保所有从库Exec_Master_Log_Pos与主库File/Position完全对齐，且gtid_mode=ON、enforce_gtid_consistency=ON已在主从库全局生效。一次未校验的GTID切换，可能导致复制链路永久断裂。

4.3 索引设计：不是“越多越好”，而是“恰到好处”的艺术

索引是数据库的“高速公路”，但修太多路，反而造成“交通管制”混乱。一个优秀的索引设计，必须回答三个问题：查什么？怎么查？查多少？

联合索引的“最左前缀”原则再解读
INDEX idx_name_city (name, city)，以下查询能用到索引：

• WHERE name = 'Alice' AND city = 'Beijing'（全匹配）；
• WHERE name = 'Alice'（只用左列）；
• WHERE name = 'Alice' AND city > 'Beijing'（左列等值，右列范围）。

但以下查询不能：

• WHERE city = 'Beijing'（跳过左列，索引失效）；
• WHERE name > 'Alice' AND city = 'Beijing'（左列范围，右列等值，仅用到name部分）。

更深层的陷阱在于索引列顺序的选择。对于WHERE status = 'paid' AND create_time > '2023-01-01' ORDER BY amount DESC，应建INDEX idx_status_time_amount (status, create_time, amount)，而非(create_time, status, amount)。原因：status是离散值（如'paid','pending','failed'），选择性高，放在最左能快速过滤；create_time是范围条件，放在中间；amount是排序字段，放在最后实现索引覆盖，避免Using filesort。

覆盖索引（Covering Index）的极致利用
当SELECT的字段全部包含在索引中时，InnoDB无需回表查询聚簇索引，直接从二级索引页返回数据，性能提升显著。例如，用户中心查询SELECT user_id, name, email FROM users WHERE status = 'active'，若建INDEX idx_status_uid_name_email (status, user_id, name, email)，则EXPLAIN的Extra列会显示Using index，表明是覆盖索引。此时，user_id作为主键，必须包含在索引中，否则无法保证唯一性。

索引维护的“成本意识”
每个索引都是双刃剑：

• 空间成本：一个B+树索引，其大小约为表数据的1.2~1.5倍；
• 写入成本：每次INSERT/UPDATE/DELETE，都要维护所有相关索引，增加CPU和IO开销。
  因此，必须定期审计索引使用率。MySQL 5.7+提供了sys.schema_unused_indexes视图：

SELECT * FROM sys.schema_unused_indexes WHERE object_schema = 'your_db' AND object_name = 'your_table';

若某索引连续一周count_star = 0，且无UPDATE/DELETE涉及该索引列，则可安全删除。

5. 常见问题与排查技巧实录：那些文档里不会写的“血泪教训”

5.1 “明明加了索引，为什么还是全表扫描？”——索引失效的12种真实场景

索引失效是最高频的“八股文”问题，但网上答案往往流于表面。以下是我在生产环境中亲手验证过的12种根因及对应解法：

5.2 “事务卡住了，但SHOW PROCESSLIST看不到锁？”——隐式锁与锁升级的迷雾

有时，SELECT ... FOR UPDATE或UPDATE语句长时间无响应，SHOW PROCESSLIST显示State = 'Updating'或'Sending data'，但SELECT * FROM performance_schema.data_locks却查不到任何锁记录。这往往指向两个深层机制：

• 隐式锁（Implicit Lock）：InnoDB对新插入的记录（Insert Intention Lock）不立即加锁，而是等到其他事务尝试读取该记录时，才在SELECT ... LOCK IN SHARE MODE或SELECT ... FOR UPDATE过程中，将隐式锁转换为显式锁。这意味着，锁的持有者可能是一个尚未完成INSERT的事务，而data_locks只显示显式锁。排查方法：SELECT * FROM performance_schema.events_statements_current WHERE SQL_TEXT LIKE '%INSERT%' AND STATE = 'EXECUTING'，找到正在执行INSERT的线程ID，再KILL它。

• 锁升级（Lock Escalation）：当一个事务持有的行锁数量超过innodb_row_lock_threshold（默认1000）时，InnoDB会尝试将行锁升级为页锁（Page Lock）甚至表锁（Table Lock），以减少锁管理开销。但MySQL官方并未暴露锁升级的监控指标。实证方法：当Innodb_row_lock_waits突增，且Innodb_row_lock_time_avg显著升高时，极可能是锁升级导致。解决方案：拆分大事务，将单次UPDATE百万行改为分批UPDATE ... LIMIT 1000。

5.3 “COUNT(*)为什么比COUNT(列)快？”——不只是“不校验NULL”，而是存储引擎的底层差异

这个问题的答案，常被简化为“COUNT(*)不校验NULL，COUNT(列)要校验”。但这只是表象。根本原因在于存储引擎对COUNT(*)的特殊优化：

• MyISAM引擎：COUNT(*)直接读取表的元数据rows字段（该值在SELECT时实时更新），O(1)时间复杂度；而COUNT(列)必须遍历所有行校验NULL，O(N)。
• InnoDB引擎：没有rows元数据缓存（因MVCC和行锁，行数是动态的），所以COUNT(*)和COUNT(列)都需要遍历。但COUNT(*)只需遍历索引树（通常是主键索引），而COUNT(列)若该列无索引，则需遍历聚簇索引（即全表扫描），IO成本更高。

实测验证：

-- 创建测试表 CREATE TABLE t_count (id INT PRIMARY KEY, name VARCHAR(50), status TINYINT); INSERT INTO t_count VALUES (1,'a',1),(2,'b',0),(3,'c',NULL); -- 添加索引 CREATE INDEX idx_status ON t_count(status); -- 执行对比 SELECT COUNT(*) FROM t_count; -- EXPLAIN: type=index, key=PRIMARY, rows=3 SELECT COUNT(status) FROM t_count; -- EXPLAIN: type=index, key=idx_status, rows=3 (因有索引) SELECT COUNT(name) FROM t_count; -- EXPLAIN: type=ALL, key=NULL, rows=3 (name无索引，全表扫描)

结论：COUNT(*)最快，因其总是走主键索引；COUNT(列)的速度，取决于该列是否有索引。因此，“优化COUNT查询”的本质，是为被计数的列创建高效索引，而非迷信COUNT(*)。

5.4 “TRUNCATE TABLE比DELETE FROM快，但为什么不能回滚？”——DDL与DML的本质鸿沟

TRUNCATE TABLE和DELETE FROM都清空表，但前者是DDL（Data Definition Language），后者是DML（Data Manipulation Language）。这一分类差异，决定了它们的根本行为：

• DELETE FROM：逐行删除，每行生成undo log，可被事务回滚；触发DELETE触发器；AUTO_INCREMENT计数器不变；
• TRUNCATE TABLE：本质是重建表：先DROP原表，再CREATE一个同名空表。因此：
  • 不生成undo log，无法回滚（即使在事务中执行，也会立即提交）；
  • 不触发任何DML触发器；
  • AUTO_INCREMENT计数器重置为1；
  • 表结构定义（如COMMENT、ENGINE）保持不变，但CREATE TABLE语句中的ROW_FORMAT等属性可能被重置为默认值