MySQL中RAND()在VALUES列表里每条语句只计算一次，导致多行随机值相同；正确做法是用INSERT...SELECT或单行循环插入。
MySQL 中 RAND() 在 INSERT ... SELECT 循环里不生效？
直接说结论：rand() 在单条 insert ... select 语句中是“每行求值一次”，但如果你用循环（比如存储过程里的 while）反复执行同一条含 rand() 的插入语句，它每次都会重新生成——这本身没问题；真正踩坑的是：很多人误以为 rand() 能在 values 列表里“对每行独立计算”，结果发现所有行的随机数一模一样。
原因很简单：INSERT INTO t VALUES (RAND(), 'x'), (RAND(), 'y') 这种写法中，RAND() 在整条语句执行前只计算一次（MySQL 5.7+ 行为），不是每组括号各算一次。所以两行的随机数完全相同。
- 正确做法是改用
INSERT ... SELECT+ 衍生表或UNION ALL模拟多行 - 或者用存储过程循环，每次只插一行：
INSERT INTO t VALUES (RAND(), 'fixed') - 如果依赖
RAND()做分布测试，记得加ORDER BY RAND()只适用于SELECT，不能用于INSERT的值生成
PostgreSQL 怎么让 generate_series() 配合随机数批量插入
PostgreSQL 没有 RAND()，但有 random()，而且它在集合函数里行为更可控。配合 generate_series() 是最干净的批量造数方式。
例如插入 1000 行带随机整数、随机字符串的数据：
INSERT INTO test_data (id, score, tag)
SELECT
s,
floor(random() * 100)::int,
substr('abcde', (random() * 5)::int + 1, 1)
FROM generate_series(1, 1000) AS s;注意点：
-
random()在每一行输出中独立计算，不会像 MySQL 那样被“提前固化” -
floor(random() * N)是安全的整数范围取法；别用round()，它会让两端概率减半 - 字符串随机取字符时，
(random() * 5)::int可能得 0，而substr(..., 0, 1)返回空，要加+ 1对齐索引
Python 脚本批量插入带随机数据时，为什么数据库报错 “Data too long”
这是典型的数据类型不匹配：你用 random.choice(string.ascii_letters) 拼了 200 字符的“随机字符串”，但数据库字段定义是 VARCHAR(50)，而 ORM 或原生驱动没做截断，直接扔进去就炸。
实操建议：
- 生成字符串前先定长：
''.join(random.choices('abc123', k=50))，别用choice+ 循环拼接 - 数值类字段，用
random.randint(1, 99)而不是int(random.random() * 100)，后者可能溢出边界 - 如果用 SQLAlchemy，别依赖
@hybrid_property或自定义函数生成随机值再 insert——它不会自动注入到 SQL，容易漏掉 - 批量插入超 1000 行时，分批提交（如每 500 条
commit），避免事务日志撑爆
SQLite 的 random() 插入性能突然变慢？
SQLite 的 random() 函数本身不慢，但如果你在循环里逐条执行 INSERT INTO t VALUES (random(), ...)，性能瓶颈根本不在随机数，而在 WAL 模式下的日志刷盘和单语句解析开销。
优化路径很明确：
- 关掉自动提交：
conn.execute("PRAGMA synchronous = OFF")和"PRAGMA journal_mode = MEMORY"（仅测试用） - 用
executemany()批量传参，而不是循环调用execute() - 别在 Python 里用
[random.random() for _ in range(N)]预生成再插——内存占用大且无必要；SQLite 支持INSERT INTO t SELECT random(), ... FROM generate_series(1,1000)（需启用extension-functions或用 CTE 模拟）
真正容易被忽略的是：SQLite 的 random() 返回的是 -9223372036854775808 到 +9223372036854775807 范围内的整数，不是 [0,1) 小数——拿它当浮点用会出整型溢出错误。
