mydumper默认不加--rows和--threads时仍是单线程全表扫描，速度不比mysqldump快；提速必须显式配置--rows触发分片，并配合--threads并行读取分片，且表需有主键或唯一索引，否则--rows被忽略。
默认不加 --rows 和 --threads，mydumper 对千万级表仍是单线程全表扫描，速度不会比 mysqldump 快——这是最常被误以为“已启用并行”却实际没生效的情况。
为什么加了 --threads 还是慢？
根本原因在于：--threads 只控制「多少个线程并发读取不同表」，而对单张大表提速，必须靠 --rows（或 --chunk-filesize）触发块级分片，再配合 --threads 让多个线程并行扫不同分片。
- 不加
--rows，哪怕--threads=16，mydumper 也只用 1 个线程读整张表 -
--rows=500000表示按主键/唯一索引切分，每段约 50 万行；mydumper 自动分配给空闲线程并发执行 - 若表无主键或唯一非空索引，
--rows直接被忽略——此时需先加临时主键：ALTER TABLE t ADD COLUMN id_tmp BIGINT AUTO_INCREMENT FIRST, ADD PRIMARY KEY(id_tmp) - 验证是否生效：备份后看输出目录里是否有
db.table.00001.sql、db.table.00002.sql等连续编号文件
--rows 和 --chunk-filesize 怎么选？
优先用 --rows，它更稳定、可控，不受字段长度和字符集影响；--chunk-filesize 在变长字段多、BLOB 多的表上容易偏差大，导致分片不均甚至卡死。
- 千万级表（1000–5000 万行）：推荐
--rows=100000～500000 - 亿级表（>5000 万行）：可压到
--rows=200000，避免单 chunk 扫描太久阻塞其他线程 -
--chunk-filesize=50（单位 MB）仅建议用于已有明确 IO 吞吐瓶颈且需限制单文件大小的场景，比如上传到对象存储时防超 2GB 限制 - 别混用
--rows和--chunk-filesize，mydumper 会以--rows为准，后者被静默忽略
线程数设多少才不翻车？
不是越多越好。盲目堆高 --threads 会导致上下文切换开销陡增、IO 拥塞、inode 耗尽，反而拖慢整体速度。
win可用的mysql指令skill
下载
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- SSD/NVMe 磁盘：从
--threads=8起步，上限一般不超过 12；实测超过 14 后收益趋缓甚至倒退 - 机械盘：严格限制在
--threads=4以内，否则磁头疯狂寻道，吞吐不升反降 - 必须配合
--compress：gzip 压缩能减少 60%+ 数据体积，IO 总量下降后，实际耗时常比不压缩还短 - 检查 inode 使用率：
df -i，超 90% 就立刻清理旧 dump 目录，比调参更立竿见影
最容易被跳过的致命细节
权限、锁、一致性配置出问题，备份可能静默失败或数据不一致，等恢复时才发现，代价远高于慢几秒。
- 备份用户必须有
FILE权限：GRANT FILE ON *.* TO 'u_mydumper'@'%'，漏掉这条，SELECT INTO OUTFILE报错直接中断 -
secure_file_priv必须指向备份目录：SELECT @@secure_file_priv非空且路径匹配，否则报Access denied for SELECT INTO OUTFILE - GTID 环境下务必加
--no-binlog或--no-locks，否则可能破坏主从同步位点 - 恢复前关外键：
myloader不自动执行SET FOREIGN_KEY_CHECKS=0，遇到外键冲突就停住
真正快的关键，从来不是堆参数，而是让每个参数都踩在硬件能力与 MySQL 机制的交点上：有主键才分片，有 FILE 权限才写入，有 SSD 才敢开多线程，有 GTID 就得管 binlog。漏掉其中任一环，备份就只是“看起来在跑”。
