phpMyAdmin 的“分卷”功能仅按行数或字节数切分 SQL 内容并写入单个文件（如 table.sql），即使启用 Gzip 也只生成一个压缩包（table.sql.gz），而非多个独立压缩分卷文件（如 data_001.sql.gz）。
phpMyAdmin 本身不支持分卷压缩导出（即把一张大表拆成多个 .sql.gz 文件）——它只能对整个导出结果做一次 gzip 压缩，或不分卷导出为多个文件但不压缩。 你看到的“分卷”选项，实际是按 INSERT 语句行数或字节数切分 SQL 内容，生成一个单文件（如 table.sql），不是多个压缩包。
为什么 phpMyAdmin 的「分卷」不是你想要的分卷压缩？
phpMyAdmin 的「分卷」功能（在导出页勾选 Split into files）只控制 SQL 文本结构：
- 它把
INSERT语句按每50行（默认）或指定大小切开，写进同一个.sql文件里，用注释标记分片，例如：-- Part 1 -- - 即使你同时勾选
Gzip，最终也只生成一个table.sql.gz，不是table_part1.sql.gz、table_part2.sql.gz这样的多个压缩包 - 这个机制面向的是「避免单条 INSERT 过长导致导入失败」，不是解决「单文件太大无法下载/传输」问题
真正能分卷压缩导出的替代方案
要得到多个带压缩的分卷文件（如 data_001.sql.gz、data_002.sql.gz），必须绕过 phpMyAdmin，改用命令行工具组合。核心思路是：用 mysqldump 分批查数据 → 每批单独压缩 → 控制文件名序号。
- 先用
SELECT COUNT(*)算出总行数，比如1250000行 - 按每批
200000行分 7 批，用mysqldump --where+LIMIT/OFFSET或主键范围导出（推荐后者，避免 OFFSET 性能崩塌） - 每批用管道交给
gzip，并用sprintf类逻辑命名，例如：mysqldump -u root db table --where="id BETWEEN 1 AND 200000" | gzip > data_001.sql.gz - 注意：如果表无合适数字主键，可用
ROW_NUMBER()（MySQL 8.0+）临时编号，或先导出 ID 列再分段
容易被忽略的关键细节
直接套用网上“分卷脚本”常翻车，因为没处理这些：
立即学习“PHP免费学习笔记（深入）”；
-
mysqldump默认不包含CREATE TABLE语句（除非加--add-create-info），分卷导入时会报错Table doesn't exist - 多个分卷文件导入顺序必须严格一致，且不能跳过任意一个，否则主键/外键约束可能中断
- 如果表含
TEXT/BLOB字段，--hex-blob参数必须统一启用，否则分卷间二进制内容解析不一致 - phpMyAdmin 导出时自动加的
SET FOREIGN_KEY_CHECKS=0等会话设置，在手动分卷中得自己补全，否则导入可能被外键拦住
分卷压缩的本质是「用可控的批量查询替代全表扫描」，不是界面点几下就能搞定的事。真正稳定的做法，是写个简单 shell 脚本控制 mysqldump 的 --where 条件和输出路径，再加一层错误检查——别指望 phpMyAdmin 替你做这件事。
