MySQL 8.0+最快方案是递归CTE配合INSERT…SELECT，因单次执行生成千万级数据，避免逐行插入的日志刷盘、索引更新与锁竞争；存储过程循环插入百万级以上显著变慢，实测100万条需5–15分钟，一千万条易失败或耗时数小时。
INSERT ... SELECT 配合递归 CTE 是 MySQL 8.0+ 最快的方案，单次执行即可生成一千万条，不用循环、不卡死、事务可控
为什么不用存储过程逐行插入？
逐行 INSERT 在百万级以上就会明显变慢，本质是每条语句都触发一次日志写入、索引更新和锁竞争。实测 MySQL 8.0 下，纯 WHILE 循环插入 100 万条通常要 5–15 分钟，且容易因超时或内存溢出中断；到一千万条时，几乎必然失败或耗时数小时。
MySQL 8.0 推荐：用递归 CTE + 批量 INSERT
MySQL 8.0 支持 WITH RECURSIVE，能一次性生成整数序列，再结合 INSERT ... SELECT 批量写入，性能碾压循环。关键点：
-
max_recursive_depth默认为 1000，必须提前调大：SET SESSION max_recursive_depth = 10000000; - 避免在 CTE 内多次调用
RAND()—— 它不是常量函数，在递归中重复计算会拖慢速度，应在外层 SELECT 中生成 - 关闭自动提交：
SET autocommit = 0;，最后COMMIT，否则每行都刷盘 - 如果目标表有非主键索引，建议先
DROP INDEX，数据插入完再重建，提速 2–3 倍
示例（生成 1000 万条用户数据）：
SET SESSION max_recursive_depth = 10000000;
SET autocommit = 0;
<p>CREATE TABLE test_user (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
name VARCHAR(32),
age TINYINT,
email VARCHAR(64),
create_time DATETIME
) ENGINE=InnoDB;</p><p>WITH RECURSIVE seq AS (
SELECT 1 AS n
UNION ALL
SELECT n + 1 FROM seq WHERE n < 10000000
)
INSERT INTO test_user (name, age, email, create<em>time)
SELECT
CONCAT('user</em>', n),
FLOOR(18 + RAND() <em> 60),
CONCAT('u', n, '@test.com'),
DATE_SUB(NOW(), INTERVAL FLOOR(RAND() </em> 3650) DAY)
FROM seq;</p><p>COMMIT;MySQL 5.7 或低版本怎么办？
没有递归 CTE，只能退回到“自连接膨胀法”或“内存表中转”，但要注意：
- 别用
INSERT INTO ... SELECT FROM t1, t1 AS t2, t1 AS t3...无节制自连接 —— 表本身为空时会报错，且易爆内存 - 稳妥做法：先用
INSERT插入 1 条，再用INSERT INTO ... SELECT ... FROM t1逐步翻倍（2→4→8→…），执行 24 次得 1677 万条。但需手动控制轮次，且@i变量在多语句中易丢失，务必每次重置：SET @i = 0; - 更稳的替代：建一张
ENGINE=MEMORY的临时表，用存储过程往里插（每 10 万条COMMIT一次），再INSERT INTO real_table SELECT * FROM memory_table
最容易被忽略的性能陷阱
很多人跑通了但实际极慢，问题往往不在 SQL 写法，而在环境配置：
-
innodb_log_file_size过小（默认 48MB）会导致频繁 checkpoint，一千万条可能卡在 70%；建议设为 512MB 或 1GB -
sort_buffer_size和read_buffer_size太小会让批量 INSERT 降级为多次小写入 - SSD 是刚需 —— HDD 上跑一千万条，即使优化到位也常要 30 分钟以上
- 如果用 Navicat 或其他 GUI 工具执行，关掉“每条语句后刷新结果”选项，否则客户端反复拉取元数据会拖慢整体进度
真正跑起来之后，你会发现瓶颈不在 SQL，而在磁盘 I/O 和日志刷写节奏 —— 调对参数，比改 SQL 更管用。
