NEWID() 生成的 GUID 含连字符、仅含0-9/A-F、长度固定36位，不满足业务对可读性、无分隔符及全字符集（大小写字母+数字）的需求；其行级唯一性优于RAND()，适合作为随机种子。
NEWID() 生成的字符串为什么不能直接当随机码用
因为 NEWID() 返回的是标准 GUID（如 'A1B2C3D4-E5F6-7890-G1H2-I3J4K5L6M7N8'），含连字符、长度固定 36 位、字符集受限（只有 0–9 + A–F），不满足“可读、无分隔符、支持大小写字母+数字”的常见业务需求（比如邀请码、订单号后缀）。
直接 REPLACE(NEWID(), '-', '') 只是去掉横线，得到 32 位十六进制串，仍缺字母 G–Z 和小写，且过长。真正要的是可控长度、全字符集、无重复的随机字符串。
用 NEWID() 做随机源比 RAND() 更可靠
RAND() 在单条 SELECT 语句中多次调用会返回相同值（SQL Server 对同一语句只计算一次 RAND()），无法用于逐行生成不同随机串；而 NEWID() 每次求值都生成新 GUID，天然具备行级唯一性和不可预测性，适合作为随机种子。
实操建议：
- 用
ABS(CHECKSUM(NEWID())) % N生成 [0, N) 区间整数，替代RAND()的不稳定行为 - 把字符表定义为变量（如
@chars = 'ABCDEFGHJKLMNPQRSTUVWXYZ23456789'），避开易混淆字符（I, O, 0, 1） - 用
SUBSTRING(@chars, ABS(CHECKSUM(NEWID())) % LEN(@chars) + 1, 1)抽单个字符，循环拼接
存储过程中拼接随机字符串的高效写法
避免用 WHILE 循环拼接（性能差、不易维护），改用基于 sys.all_objects 或递归 CTE 的集合式生成。但最简实用方案仍是 WHILE —— 只要长度固定（如 8 位），循环 8 次开销极小：
DECLARE @len INT = 8, @i INT = 1, @result VARCHAR(32) = '';
DECLARE @chars VARCHAR(64) = 'ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz23456789';
WHILE @i <= @len
BEGIN
SET @result = @result + SUBSTRING(@chars, ABS(CHECKSUM(NEWID())) % LEN(@chars) + 1, 1);
SET @i = @i + 1;
END
SELECT @result AS random_string;
注意点：
-
LEN(@chars)必须加+1，否则SUBSTRING索引可能为 0，导致空字符 - 不要用
CHAR(65 + ABS(CHECKSUM(NEWID())) % 26)手动算 ASCII——易出界，且难控制大小写混合 - 若需全局唯一，应在调用方加唯一约束或先查重，
NEWID()本身不保证跨批次唯一
为什么不用 NEWID() 直接截取子串
有人试过 LEFT(REPLACE(NEWID(), '-', ''), 8)，看似简单，但问题明显：
- 输出只含 0–9 和 A–F，字符集太窄，碰撞概率升高
- GUID 前 8 位实际是时间戳相关段，连续调用时高位雷同，随机性不足
- 十六进制字符分布不均（比如 A–F 出现频率低于 0–9），影响熵值
真正需要的是均匀采样自定义字符集，而不是对 GUID 做裁剪。这也是所有靠谱实现都绕不开 CHECKSUM(NEWID()) + 字符表映射的原因。
字符集定义和长度控制这两个点，一旦写死就容易在后期被忽略，尤其当业务要求从 8 位升级到 12 位、或增加特殊符号时，必须同步检查所有调用点和索引长度限制。
