util.importtable() 比传统方式快，因其跳过 sql 解析路径，直接解析文件为二进制并通过 x protocol 批量写入缓冲池；实测比 load data infile 快 20%~40%，并行导入需满足主键/唯一索引、mysql ≥ 8.0.21、纯文本无跨行字段三条件。
MySQL Shell 的 util.importTable() 为什么比传统方式快？
因为 util.importTable() 不走 SQL 解析路径，而是直接将 CSV/JSON/TABLE 文件解析为二进制格式，通过 MySQL X Protocol 批量写入 InnoDB 缓冲池，跳过了词法分析、权限校验、单行事务封装等开销。实测千万级数据导入耗时可比 LOAD DATA INFILE 再降 20%~40%，尤其在 SSD + 多核 CPU 环境下优势明显。
并行导入必须满足的三个前提条件
不是所有表都能开并行——漏掉任一条件都会退化为单线程：
- 目标表必须有主键或非空唯一索引（否则无法分片定位）
- MySQL Shell 连接的 MySQL 实例版本 ≥ 8.0.21（低于此版本不支持
parallelThreads参数） - 导入文件必须是按行分割的纯文本（CSV/TSV），且无跨行字段（如含换行符的 TEXT 字段需提前转义）
util.importTable() 关键参数怎么设才不翻车？
默认参数看似省事，但大数据场景下极易触发内存溢出或锁等待。实操中必须显式控制：
-
schema和table必须明确指定，不能依赖自动推断（否则可能映射错列） -
skipRows: 1要加——如果 CSV 含表头，否则首行会被当数据插入 -
dialect: "csv"或"tsv"必须声明，否则字段分隔符识别错误率极高 -
parallelThreads: 4是安全起点；超过 CPU 核心数 × 1.5 容易引发 IO 争抢，反而变慢 -
bytesPerChunk: "16M"推荐设为 8M–32M 区间，太小导致调度开销大，太大则单 chunk 内存占用飙升
导入前必须手动关闭的两项机制
Shell 不会自动帮你关这些——靠参数开关也无效，必须提前执行 SQL：
- 执行
SET FOREIGN_KEY_CHECKS = 0：否则每 chunk 都要校验外键，性能断崖下跌 - 执行
ALTER TABLE your_table DISABLE KEYS：禁用非唯一索引更新，等导入完成再ENABLE KEYS
这两步漏掉，1000 万行导入可能从 3 分钟拖到 25 分钟以上。导入脚本里建议把它们和 util.importTable() 放在同一事务块里，避免中间失败导致状态不一致。
真正卡住人的往往不是并发数调多，而是 CSV 字段类型和表定义不匹配（比如字符串字段里混了 NULL 字面量但没设 defaultValues），或者 bytesPerChunk 设得太大导致单次分配内存超限——这些错误不会报“导入失败”，而是静默降级为单线程，还跑得特别慢。动手前务必用前 1000 行做 dry-run 测试。
