实测：7-Zip命令行并发解压，-mmt参数开多少核才不浪费CPU

平时部署包和日志包都是批量解，脚本里一直用 7z 命令行，但 -mmt 这个参数我从来没细究过，默认给多少就用多少。前两天一台 8 核的构建机解一个 30GB 的日志分卷包，CPU 只跑到 40%，解压花了 11 分钟，我觉得不对劲，就抽空把参数挨个掐表对了一遍。

测试环境

• 机器 A：8 核 16G，SATA SSD
• 机器 B：16 核 32G，NVMe
• 包：同一个 30GB 日志分卷包（7z 格式，LZMA2，4 个分卷）
• 命令模板：7z x archive.7z.001 -oD:\out -mmt=N -bso0 -bsp0
• 每档跑 3 次取中位数，输出目录每次清空

结果（解压耗时，秒）

几个比较反直觉的点：

1. 默认不写基本就等于满核，7z 会自己按逻辑核数分配，机器 A 上默认和 -mmt=8 差不到 2%，在误差范围内。
2. -mmt 开超过物理核数收益几乎为零，机器 B 上 16 和 32 只差 2 秒，纯属浪费调度开销。
3. 瓶颈不在 CPU 的时候，调参没用。机器 A 上我盯着任务管理器看，CPU 峰值也就 70% 出头，磁盘写入队列倒是满的，说明卡在 IO 上，这时候把 -mmt 调到 4 反而因为并发少了、写盘更连续，比默认还慢一点——但也就 6% 左右，别指望靠调参解决 IO 瓶颈。
4. 分卷包解压第一阶段是串行合并的，前几十秒 CPU 根本吃不满，别拿这几十秒的占用率下结论。

我的结论：批量脚本里 -mmt 真没必要手动指定，默认就行；要压榨性能，优先看输出盘是不是和源包在同一块盘上（我后来把输出改到另一块 NVMe，机器 B 直接降到 410 秒），以及关掉不必要的 -bso 输出。Win解压缩 在这块就没法比了，它图形界面点一下是快，但批处理里你没法精细控制线程和输出重定向，老老实实上 7z。

想问问大家：你们批量解压的时候，-mmt 是写死还是交给默认？另外有没有人试过 -mmt=on 和直接写数字在实际机器上有没有区别？我这边测下来感觉是一样的，但样本不够。