关于 SQL Server 中生成 GUID 这事儿，有几个关键点值得单独拎出来说清楚。先说结论：NEWID() 每次调用都会生成一个无序的随机 GUID，全局唯一性没问题，但因为它完全随机，插入到聚集索引时容易引发页分裂，性能会受影响。如果非要用有序 GUID，得换 NEWSEQUENTIALID()——但这个函数只能用在默认约束里，不能直接在 INSERT 的 VALUES 中调用。
NEWID() 在 SQL Server 中生成 GUID 的实际效果
NEWID() 是 SQL Server 自己独有的函数，每次调用都返回一个全新的 uniqueidentifier 值——本质上是 128 位的随机 GUID。它不依赖时间戳或机器信息，所以在分布式场景下也能保证全局唯一性。但代价呢？完全随机，毫无顺序可言。插入时会在聚集索引上引发大量页分裂，性能直线下降。
很多人容易犯的一个错误是，想把它当成“时间有序的 ID”来用，结果发现主键索引的性能断崖式下跌。如果确实需要有序 GUID，得用 NEWSEQUENTIALID()，但注意它只能定义在默认约束里，不能直接在 INSERT 语句中调用。这一点必须搞清楚。
INSERT 语句中直接使用 NEWID() 的写法与限制
可以在 INSERT 的 VALUES 子句里直接调用 NEWID()，适用于单条或批量插入时每行需要独立 ID 的场景：
INSERT INTO users (id, name) VALUES (NEWID(), 'Alice'), (NEWID(), 'Bob');
不过有几个细节需要留意：
NEWID()每次出现在表达式中都会重新计算，所以SELECT NEWID(), NEWID()返回的是两个不同的值，别指望它们相等。- 不能在视图定义、聚合函数或 WHERE 条件中“稳定引用”同一个值。如果想复用同一个 GUID，必须先存入变量：
DECLARE @id UNIQUEIDENTIFIER = NEWID(); INSERT ... VALUES (@id, ...); - 在触发器或计算列中使用时要特别小心——可能引发不可预期的多次求值，结果跟你预想的不一样。
用 NEWID() 实现随机抽样时的性能陷阱
很多人喜欢用 ORDER BY NEWID() 来做随机排序，比如取 10 条随机记录：
SELECT TOP 10 * FROM products ORDER BY NEWID();
这写法看起来简洁，但实际执行时，SQL Server 会为表中每一行都调用一次 NEWID()，然后全量排序。数据量稍大，比如超过 10 万行，性能就会明显变慢。更高效的做法是：
- 小表（<1000 行）直接
ORDER BY NEWID()问题不大。 - 中大表：改用
TABLESAMPLE，比如SELECT * FROM products TABLESAMPLE (10 PERCENT)，但注意它不保证精确的行数。 - 如果严格要求 N 行且对性能敏感，可以用窗口函数 +
CHECKSUM(NEWID())降序取 Top N，避免全排序。
跨数据库兼容性问题——别在非 SQL Server 环境硬套 NEWID()
不同数据库的 UUID 生成函数差异很大。PostgreSQL 用 gen_random_uuid()（需要 pgcrypto 扩展），MySQL 用 UUID()（格式是 xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx，但含时间成分，不是真正的随机 GUID），SQLite 干脆没有内置 UUID 函数，只能靠应用层生成。
如果项目要兼容多个数据库，不要在 SQL 层硬写 NEWID()。要么统一由应用层生成 UUID4 后再传入，要么抽象出数据库适配层。直接迁移 SQL 脚本时，这个函数是最容易卡住的地方之一，提前做好规划能省不少麻烦。
