mysql 8.0 本身不支持内置多线程数据加载；真正加速导入需外部组合mysqlpump导出后分拆sql文件，再用多个mysql客户端并发执行，并注意死锁、字符集、权限及i/o配置等关键约束。
MySQL 8.0 本身不支持“多线程数据加载”这个说法——mysqlpump 是单进程工具，但可通过 --default-parallelism 启用并行导出，而导入仍需靠外部手段（如 mysql 客户端分拆 SQL 并发执行）才能实现真正多线程加载。
mysqlpump 的并行导出：不是加载，是导出阶段的并发
mysqlpump 是 MySQL 5.7 引入、8.0 默认包含的逻辑备份工具，它支持按库/表粒度并发读取和生成 SQL，但导出结果仍是单个或多个 .sql 文件，**不直接执行加载**。
-
--default-parallelism=N控制并发线程数（默认为 2），N 值建议 ≤ CPU 核心数；设为 0 表示自动检测，但实际常不如手动指定稳定 - 仅对
--include-databases或--include-tables指定的对象生效；未显式指定时，并行度可能被降级为 1 - 并发导出时，每个线程独立连接服务器，会占用额外
max_connections配额，需确保max_connections≥ N ×（库数或表组数）+ 管理连接 - 不支持对单张大表内部做行级分片并行——它按对象（库/表）分发任务，不是按数据量切分
真正多线程“加载”得靠外部组合：mysql + shell 脚本分拆 + 并发执行
MySQL 服务端没有内置“多线程 SQL 导入”命令。mysql 客户端本身是单线程执行 SQL 流。要加速导入，必须把 dump 出来的 SQL 拆成多个文件，再用多个 mysql 进程并发执行：
- 用
mysqlpump --skip-definer --compress-output=NONE > full.sql导出无压缩纯文本（便于split或awk处理） - 按
CREATE TABLE/INSERT INTO边界拆分：例如用csplit（Linux）或 PowerShell 脚本识别USE `db`;或INSERT INTO `t`行做切片 - 每个子文件单独执行：
mysql -u root -p -D target_db ，注意加 <code>&后台运行，并用wait控制并发数（避免打爆连接） - 更稳妥的做法是用 GNU Parallel：
ls part_*.sql | parallel -j 4 mysql -u root -p -D target_db，-j 4限制同时运行 4 个进程
容易踩的坑：字符集、权限、事务与锁
并发导入比单线程敏感得多，以下问题高频出现：
-
ERROR 1205 (HY000): Deadlock found when trying to get lock：多个mysql进程同时写同一张 InnoDB 表，尤其含外键或二级索引时极易死锁；应确保每个进程只操作不同库/表，或提前DROP TABLE再重建 - 导入中途报
ERROR 1366 (HY000): Incorrect string value：导出时没统一--set-gtid-purged=OFF --default-character-set=utf8mb4，导致 emoji 或生僻字乱码；导入前务必确认目标库character_set_database和连接字符集一致 - 权限不足：并发连接需要更多
PROCESS、SUPER（旧版）或BACKUP_ADMIN（8.0+）权限，mysqlpump默认要求SELECT+LOCK TABLES，但并行时还隐式依赖SHOW VIEW -
max_allowed_packet不够：并发导入大量INSERT ... VALUES (...),(...),...时，单条语句超限直接中断；服务端和客户端都需调大，如mysql --max-allowed-packet=512M
真正影响加载速度的从来不是“能不能开多线程”，而是磁盘 I/O 能力、InnoDB 日志刷盘策略（innodb_flush_log_at_trx_commit=2 可提速但丢数据）、以及是否关闭唯一性检查（SET unique_checks=0）等底层配置。并发只是表象，绕不开这些硬约束。
