Navicat结构同步对分区表会触发整表MDL读锁，且比普通表更危险：因其默认以REPEATABLE READ开启长事务并全表扫描，而分区表元数据仍为逻辑整表，锁粒度未细化到分区。
Navicat结构同步对分区表是否触发MDL锁
会，而且比普通表更危险。Navicat结构同步本身不区分是否分区表，只要目标库是MySQL 5.6+、引擎为InnoDB，它就默认以REPEATABLE READ开启长事务，对源表和目标表都执行全表扫描（比如SELECT COUNT(*)或SELECT * FROM table_name LIMIT 1），全程持有MDL读锁——分区表只是把数据物理切分，元数据（如INFORMATION_SCHEMA.PARTITIONS）仍是一张逻辑表，锁的粒度仍是整张表，不是单个分区。
为什么分区表在结构同步中更容易卡住
分区表结构变更常伴随隐式风险，Navicat无法识别这些约束，导致同步过程更易触发阻塞：
- 分区字段必须是主键/唯一键的一部分，但Navicat「设计表」里拖动列顺序或改主键时，可能生成无效DDL（例如漏掉
PARTITION BY RANGE (UNIX_TIMESTAMP(created_at))），执行失败后事务未回滚，MDL锁残留 - 添加新分区（
ALTER TABLE ... ADD PARTITION）本身支持ALGORITHM=INPLACE，但Navicat结构同步不暴露该参数选项，仍可能退化为COPY模式，尤其当存在FULLTEXT索引或外键级联时 - 若目标表已手动增删过分区（如DBA用命令行加了
p202610），而Navicat比对时只看表定义不看SHOW CREATE TABLE输出的完整分区语句，容易误判为“结构一致”，跳过同步，或反向执行DROP PARTITION - 分区表常用于大表（千万级以上），Navicat预览阶段的
SELECT若没走分区裁剪（比如WHERE条件未覆盖分区字段），就会扫全分区，加剧MDL持锁时间
如何安全同步分区表结构而不锁生产库
绕开Navicat黑盒事务模型，用可控方式分步操作：
- 先在目标库手动执行
SHOW CREATE TABLE table_name，确认当前分区定义、引擎、字符集、外键状态，与源库严格比对 - 禁用Navicat的
Preview DDL before execution（Preferences → DDL），避免预览阶段就启事务持锁 - 不使用「结构同步」全量比对，改为右键单张分区表 →
Synchronize to Database，限定范围，缩短锁窗口 - 涉及分区变更（如
ADD/REORGANIZE）时，直接手写带ALGORITHM=INPLACE, LOCK=NONE的语句，在SQL查询窗口执行，并提前用EXPLAIN PARTITIONS验证条件是否命中分区 - 若必须用结构同步，确保源库是权威结构（如Git管理的DDL脚本初始化的库），且目标库无手工修改痕迹；同步前用
SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX WHERE TRX_STATE = 'RUNNING'清空残留事务
多人协作时最易被忽略的分区同步陷阱
分区表的“隐性一致性”比字段名更难保障：Navicat不校验PARTITION DESCRIPTION值（比如VALUES LESS THAN (1730332800)对应的时间戳是否准确）、不检查MAXVALUE是否被覆盖、也不提示TO_DAYS()函数在跨月时是否引发边界错位。一次看似无害的同步，可能让新插入的数据全部落入pmax，而没人立刻发现。
