能，但必须配合函数+合理循环结构，否则速度断崖下降；纯WHILE单行INSERT默认autocommit=1，每行刷日志、校验约束、更新索引，10万条常需几分钟甚至失败；应改用INSERT...SELECT批量落库，并用内存表中转、分批提交、合规随机函数生成数据。
能，但必须配合函数 + 合理的循环结构，否则插入速度会断崖式下降，5万条可能卡死或超时。
为什么不能只靠 WHILE 循环硬插
纯 WHILE 每次 INSERT 都是一次独立事务（除非显式开启事务），MySQL 会反复刷日志、校验约束、更新索引。10万次单行插入在普通机器上常要几分钟甚至失败。
- 默认 autocommit=1，每插一行就提交一次，I/O 压力极大
- 没加事务包裹，
ROLLBACK无法回退整批数据，出错后表状态难清理 - 字段值全靠
RAND()和CONCAT()拼，重复率高、不符合业务分布（比如手机号、邮箱格式）
必须先创建随机函数再写存储过程
MySQL 存储过程里不能直接用复杂表达式生成合规字符串（如带分隔符的手机号、中文名），得把逻辑下沉到函数里。否则存储过程体臃肿、不可复用、调试困难。
- 先执行
SET GLOBAL log_bin_trust_function_creators = 1，否则建函数报错ERROR 1418 - 姓名函数建议用预置姓氏+名字列表拼接，比纯
RAND()更真实；不要用ORDER BY RAND() LIMIT 1查表取名——查10万次就是10万次全表扫描 - 手机号可用
CONCAT('1', FLOOR(RAND()*9), LPAD(FLOOR(RAND()*100000000), 8, '0'))，避免无效号段 - 函数返回值类型要明确，比如
VARCHAR(20)，别用TEXT，否则存储过程中调用可能隐式转换失败
INSERT ... SELECT 批量替代单行 INSERT
存储过程里别写 INSERT INTO t VALUES (...) 10万次。改用内存表或临时表中转，再一次性 INSERT ... SELECT 落库，性能差10倍以上。
- 建一张
ENGINE=MEMORY表（如tmp_data），结构和目标表一致 - 在存储过程中往
tmp_data插入几千行（比如每次循环插 1000 行），用INSERT INTO tmp_data SELECT ... FROM dual UNION ALL SELECT ...构造多行 - 循环结束后，执行
INSERT INTO real_table SELECT * FROM tmp_data，再TRUNCATE tmp_data - 全程用
START TRANSACTION包裹，失败时ROLLBACK干净回退
主键和唯一约束容易踩的坑
自增 id 不用管，但业务主键（如 user_code）或唯一索引字段一旦重复，整个存储过程会中断，且不会自动跳过。
- 别依赖
RAND()生成唯一码，概率再低，10万次也大概率撞车；要用UUID_SHORT()或CONCAT(DATE_FORMAT(NOW(), '%y%m%d'), LPAD(@i:=@i+1, 6, '0'))这类确定性方案 - 如果表有唯一索引（如
email），函数里生成后必须先SELECT COUNT(*)校验是否存在，存在就重试——但重试逻辑会让过程变慢，不如提前规划好不重复的生成规则 - 外键字段（如
role_id）必须确保引用的值已存在，否则报ERROR 1452；建议先查出目标表MIN(id)和MAX(id)，再用FLOOR(RAND() * (max-min)) + min安全取值
真正卡住人的从来不是语法，而是没意识到 MySQL 的 I/O 瓶颈和约束检查开销。生成 5 万条数据，重点不在“怎么写循环”，而在“怎么让每一次磁盘写都值得”。
