导出大表卡在uuid主键本质是隐式排序开销大，应取消“按主键排序”、改用无order by的查询导出、确保uuid字段有utf8mb4_bin索引，并注意csv/excel格式化陷阱及触发器或视图导致的真卡点。
导出大表时卡在 UUID 主键字段上，本质是排序和去重开销太大
Navicat 默认导出逻辑会尝试对主键做隐式排序（尤其当目标格式要求有序，如 Excel 或 CSV 用“按主键顺序导出”选项），而 UUID 是无序字符串，MySQL 的 ORDER BY id 在千万级表上会触发全表扫描 + 文件排序，极易卡死或 OOM。这不是 Navicat 崩溃，而是它在等 MySQL 返回排好序的结果。
真正有效的解法不是调高内存，而是绕过排序依赖：
- 取消勾选导出向导里的「按主键排序」或「保持插入顺序」——该选项在「高级」页签中，默认常被误开
- 改用「导出查询结果」而非「导出表」：右键表 →「查询表」→ 在 SQL 编辑器里写
SELECT * FROM t1（不加ORDER BY），再点工具栏「导出」按钮 - 若必须分批导出，用
WHERE id > 'xxx-xxx-xxx' LIMIT 10000手动切片，注意用字符串比较（UUID 是 hex 字符串，不能转成数字）
导出含 UUID 的大表前，必须确认索引是否存在且有效
没有索引的 UUID 字段，WHERE 过滤、ORDER BY、甚至 Navicat 的「预览前 100 行」都会变慢。但很多人建了索引却没生效——因为 UUID 类型字段默认用 utf8mb4_general_ci 排序规则，而该规则对长字符串索引效率极低。
检查并优化方式：
- 执行
SHOW INDEX FROM t1 WHERE Key_name = 'PRIMARY'，确认Seq_in_index是 1 且Collation不是A（表示降序）或空 - 若主键是
VARCHAR(36)，建议显式指定更紧凑的排序规则：id VARCHAR(36) COLLATE utf8mb4_bin PRIMARY KEY - 避免在 UUID 字段上建额外的二级索引——除非真有
WHERE uuid IN (...)场景，否则纯增删查场景下，聚簇索引已足够
导出到不同格式时，UUID 字段引发的兼容性陷阱
Navicat 导出为 Excel 或 CSV 时，会对 UUID 字段做自动格式化：Excel 可能把它识别为科学计数法（如 123e4567... 被截断），CSV 若未加双引号包围，导入时可能因逗号或换行符错位。
实操要点：
- 导出为 CSV 时，务必勾选「文本限定符」设为双引号（"），并在「字段分隔符」旁确认「转义字符」启用
- 导出为 Excel（.xlsx）时，在「高级」页签中关闭「将字符串值转换为数字」——否则以数字开头的 UUID（如
1abc...）会被 Excel 强制转成数值并丢失前导 1 - 若后续要导入回 MySQL，导出时选择「包含创建表语句」并勾选「导出数据为 INSERT 语句」，Navicat 会自动给 UUID 字段加上单引号，避免语法错误
真正卡顿的根源常不在 UUID，而在关联查询或触发器
你以为卡在 UUID 字段，其实可能是 Navicat 在导出前执行了隐式 SELECT COUNT(*) 或触发了视图/函数依赖。尤其当表上有 BEFORE SELECT 触发器（虽然 MySQL 不支持该类型，但某些自定义函数或视图逻辑会模拟类似行为），或定义了复杂生成列，导出过程就会卡住。
快速定位方法：
- 先在 Navicat 查询窗口运行
SELECT COUNT(*) FROM t1，看是否卡住——如果卡，说明表本身有锁或统计信息异常 - 禁用所有外键约束（
SET FOREIGN_KEY_CHECKS = 0）后再导出，排除外键级联检查开销 - 临时移除视图或物化逻辑：若该“表”实际是视图，导出前先
CREATE TABLE t1_copy AS SELECT * FROM t1_view，再导出副本
导出大表时最易忽略的是：Navicat 的「导出进度条」显示卡在 99%，其实是它在等待 MySQL 返回最后一批数据包，而网络或防火墙可能对长连接做了超时中断；此时不要强行关掉，改用命令行 mysqldump 配合 --skip-triggers --no-create-info 更稳。
