mysqldump导出提速需显式加--single-transaction（innodb一致性快照）、--quick（防oom）、--extended-insert（多值insert减解析）、--skip-triggers/--skip-routines（跳过无需对象）；导入前必须set unique_checks=0、foreign_key_checks=0、autocommit=0以禁用校验与事务开销。
mysqldump导出时加哪些参数能明显提速？
默认导出方式对百万级以上表就是“龟速”，关键不是数据量本身，而是默认行为触发了大量低效操作。必须显式加参数绕过这些陷阱：
-
--single-transaction：对InnoDB表启用一致性快照，避免锁表，但只在事务隔离级别支持下生效（不能和--lock-tables共用） -
--quick：强制逐行读取，防止大表被全量加载进内存导致OOM；配合--skip-extended-insert可调试单行语句，但正式导出要关掉它 -
--extended-insert：生成多值INSERT语句，减少SQL解析次数——这是提速最直接的参数，不加它，100万行可能产生100万条独立INSERT -
--skip-triggers和--skip-routines：如果目标库不需要触发器或存储过程，跳过它们能缩短导出时间并减小文件体积
导入SQL文件前必须关闭哪些检查？
导入时默认每条INSERT都校验唯一索引、外键、自动提交事务，这会让速度跌到原来的1/10以下。必须在导入前手动禁用：
- 执行
SET unique_checks=0：停用唯一索引校验，等导入完再设回1重建索引（比边插边校验快得多） - 执行
SET foreign_key_checks=0：关闭外键约束，否则每行都要查关联表 - 执行
SET autocommit=0：把整个导入包包进一个事务里，避免每行都刷一次redo log；但要注意别超innodb_log_file_size限制，否则会卡住甚至崩溃
别依赖mysqldump自带的DISABLE KEYS语句——它只对MyISAM有效，InnoDB下无效。
为什么不用Navicat或Workbench导入大SQL文件？
图形工具会在客户端做SQL解析、语法高亮、进度渲染、连接保活，这些功能在导入千万行时全变成负优化：
- 内存持续增长，容易触发
Killed或Out of memory - 网络传输层不做压缩，纯文本SQL走TCP，带宽利用率极低
- 无法控制
autocommit、unique_checks等底层开关，参数被封装死
正确做法是用命令行mysql客户端直连本地socket（mysql -S /var/lib/mysql/mysql.sock），绕过网络栈，同时确保--local-infile=1开启（需服务端secure_file_priv允许路径）。
拆分大SQL文件真有用吗？
有用，但仅限于两种情况：一是导入中途失败需要重试，二是目标MySQL配置不允许超大事务（比如max_allowed_packet设得太小）。拆分不是为了提速，而是为了可控。
- 用
split -l 50000按行数切分不如按语句边界切分——sed -n '/^INSERT/p' file.sql | wc -l先估算每INSERT块行数，再用awk按INSERT INTO分段更稳妥 - 切分后导入必须保证每个文件开头有
USE db_name;，否则报错Unknown database - 并行导入多个分片？别试。InnoDB表级锁和buffer pool争用会让并发反而更慢，除非你确认表之间无关联且已关掉
foreign_key_checks
真正该花时间的地方是：确认innodb_buffer_pool_size够大（建议70%物理内存），以及把innodb_log_file_size调到足够容纳单次导入事务——这点最容易被忽略，日志文件太小会导致频繁checkpoint，拖垮整体速度。
