RANDOM_BYTES() 返回二进制字节，非可读字符串，需用 HEX() 或 TO_BASE64() 转换；作 salt 须用 VARBINARY 存储且长度≥16字节；主从复制中每次执行均重新生成，不一致但安全；禁用于 ORDER BY 等高开销场景。
MySQL RANDOM_BYTES() 不能直接当随机字符串用
它返回的是二进制字节（BINARY 类型），不是可读字符串。直接 SELECT RANDOM_BYTES(8) 看到的可能是乱码或空值，尤其在客户端编码不匹配时——比如 MySQL Workbench 默认用 UTF-8 解析二进制，会失败或截断。
- 真正想生成随机字符串（如 token、salt），得配合
HEX()或TO_BASE64()转换：SELECT TO_BASE64(RANDOM_BYTES(12)) -
HEX()结果是纯十六进制字符串，长度翻倍（12 字节 → 24 字符）；TO_BASE64()更紧凑（12 字节 → 16 字符），但含+、/、=，某些 URL 场景需替换 - 别用
CONV(HEX(...), 16, 36)之类“转进制”操作——RANDOM_BYTES()是字节流，不是数值，强转会丢失高位或溢出
用 RANDOM_BYTES() 做密码 salt 必须注意长度和存储类型
作为 salt，核心是唯一性+不可预测性，RANDOM_BYTES() 满足这点，但字段定义容易出错：
- 存储列必须是
BINARY或VARBINARY类型，比如salt VARBINARY(32)；用VARCHAR存原始输出会导致隐式字符集转换，破坏随机性 - 常见错误：建表时写成
salt VARCHAR(32)，再插RANDOM_BYTES(16)，结果只存了前几个字节（因为遇到 \0 或非 UTF-8 字节就截断） - 长度建议 ≥16 字节（128 bit），太短易被彩虹表覆盖；
RANDOM_BYTES(32)更稳妥，现代硬件生成开销可忽略
RANDOM_BYTES() 在复制环境下的行为一致吗
一致。它是基于 OpenSSL 或操作系统的 CSPRNG（加密安全伪随机数生成器），不依赖 MySQL 服务端状态，也不受 binlog 格式影响。
- 主从复制中，
INSERT INTO t(id, token) VALUES (1, RANDOM_BYTES(16))在从库执行时会重新生成新值，不是复制函数调用本身——所以它**不会**导致主从不一致 - 但这也意味着：不能靠它生成“主从同步的确定性随机值”，比如测试用固定 seed 场景；需要确定性就得自己实现（如用
SHA2(CONCAT(@seed, id), 256)） - 确认是否启用：查
SELECT @@have_openssl，必须为YES；若为DISABLED，RANDOM_BYTES()会报错FUNCTION random_bytes does not exist
替代方案：什么时候不该用 RANDOM_BYTES()
它适合生成密钥材料、salt、token，但不适合做「随机排序」或「抽样」。
-
ORDER BY RANDOM_BYTES(4)看似能打乱顺序，实际性能极差：每行都触发一次系统级随机数调用，全表扫描时 I/O 和 CPU 开销陡增 - 抽样推荐用
TABLESAMPLE（8.0.23+）或WHERE RAND() ，<code>RAND()是轻量级伪随机，够用且快 - 如果应用层已用
crypto/rand（Go）、secrets（Python）等生成了安全随机字节，就别再绕一圈让 MySQL 重复生成——增加不必要的服务端负担
真正的难点不在调用函数，而在理解它返回的是 raw bytes——所有后续处理（编码、存储、传输）都得按字节流逻辑走，一步转错，安全性就归零。
