不能。MD5(RAND())生成的是32位固定格式十六进制哈希值，仅含小写和数字，无大小写及符号，且RAND()在单条语句中确定性重复，导致多次调用结果相同。
直接用 MD5(RAND()) 生成字符串，真能当密码或测试数据用？
不能。它生成的是 32 位固定格式的十六进制串（如 d799e1b276adebb6e572ba6964731806），全是小写字母+数字，不含大写、符号，且长度不可控——这不是“随机字符串”，是哈希值。更关键的是：RAND() 在单条语句中是确定性的，MD5(RAND()) 在同一行里多次调用会返回相同结果，比如 SELECT MD5(RAND()), MD5(RAND()) 很可能输出两个一模一样的值。
SUBSTRING(MD5(RAND()), 1, n) 是最简方案，但有隐性限制
这个写法确实能快速拿到 n 位小写+数字组合，适合对字符集无要求的场景（比如填充 varchar 字段做性能压测）：
SELECT SUBSTRING(MD5(RAND()), 1, 10);
但它的问题很实在：
- 永远只有 36 个可选字符（0–9 + a–z），无法加入大写、标点
-
MD5()输出均匀性差，高位字符分布偏斜（实测前 4 位重复率明显高于后几位） - 在
INSERT ... SELECT批量插入时，若表行数多，RAND()可能被优化复用，导致部分行值重复
写存储过程时，RAND() 调用位置决定随机性是否可靠
常见错误是把 RAND() 放在循环外，或在拼接逻辑里反复复用同一个计算结果。正确做法是：每次取字符都独立触发 RAND()，且确保它落在目标字符集索引范围内：
例如生成 8 位含大小写+数字的字符串：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
DELIMITER //
CREATE FUNCTION rand_pass(len INT) RETURNS VARCHAR(255)
READS SQL DATA
DETERMINISTIC
BEGIN
DECLARE chars VARCHAR(62) DEFAULT 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789';
DECLARE res VARCHAR(255) DEFAULT '';
DECLARE i INT DEFAULT 0;
WHILE i < len DO
SET res = CONCAT(res, SUBSTRING(chars, FLOOR(RAND() * 62) + 1, 1));
SET i = i + 1;
END WHILE;
RETURN res;
END//
DELIMITER ;注意这几点：
-
FLOOR(RAND() * 62) + 1中的+ 1不可省——SUBSTRING索引从 1 开始 - 函数必须声明为
READS SQL DATA，否则 MySQL 8.0+ 会拒绝在存储过程中调用 - 别用
DETERMINISTIC声明真实随机函数，虽然语法允许，但会误导执行计划缓存行为
批量插入千万级测试数据时，RAND() 性能瓶颈在哪？
不是 RAND() 本身慢，而是它阻止了 MySQL 的向量化执行和索引预估。当你写 INSERT INTO t SELECT rand_pass(10), ... FROM huge_table，引擎必须为每一行单独计算函数值，无法并行批处理。
更高效的做法是分批次 + 预生成：
- 用
information_schema.columns或临时序列表驱动循环，避免全表扫描 - 在存储过程中用
INSERT ... VALUES批量写入（每次 1000 行），比逐行INSERT快 10 倍以上 - 若字段有唯一约束，提前加
UNIQUE INDEX会导致插入失败率上升，建议先关索引，插完再建
真正容易被忽略的，是字符集与排序规则对 SUBSTRING 的影响——如果列定义为 utf8mb4_bin，而你的字符集字符串含 emoji 或特殊符号，FLOOR(RAND() * LEN) 可能越界。稳妥起见，始终用 ASCII 字符集构造源字符串。
