在循环中反复调用 newid() 会导致每次生成新 guid，无法保证循环变量 @i 正确递增或终止，易引发无限循环或逻辑错误。
为什么不能在循环里反复调用 NEWID()
看似简单直接的写法：DECLARE @id UNIQUEIDENTIFIER; WHILE @i ，实际会触发两个隐性问题：一是每次 <code>NEWID() 都生成完全随机值，插入位置不可预测，若表有聚集索引（尤其是主键即聚集索引），将频繁引发页分裂；二是 SQL Server 不会对循环内重复调用做优化，每轮都走完整随机数生成流程，CPU 开销线性增长。更关键的是，这种写法无法利用 NEWSEQUENTIALID() 的顺序优势——它根本不能出现在 SET 或 SELECT 中，只接受默认约束绑定。
建表时就该用 NEWSEQUENTIALID() 默认约束
真正安全高效的起点不是存储过程怎么写，而是表结构是否预先适配。只要主键是 UNIQUEIDENTIFIER 类型且需聚集索引，必须在建表时声明默认值：
CREATE TABLE orders (
id UNIQUEIDENTIFIER DEFAULT NEWSEQUENTIALID() PRIMARY KEY,
order_no VARCHAR(20),
created_at DATETIME2 DEFAULT GETDATE()
);
这样后续所有 INSERT INTO orders (order_no) VALUES ('ORD-001') 都自动获得本机递增 GUID，插入位置集中在索引末尾，避免页分裂。注意：NEWSEQUENTIALID() 只在单机有效，重启后序号重置，不保证全局连续，但对写入性能提升显著。若业务要求跨服务器唯一性+顺序性，得额外加 created_at 字段并组合排序，不能只依赖 ID。
需要返回刚生成的 GUID 时用 OUTPUT，别先 SELECT NEWID()
当存储过程需拿到新记录 ID 做后续操作（比如插入关联子表），常见错误是先生成再插入：
- ❌ 错误模式：
SET @id = NEWID(); INSERT INTO parent (id, name) VALUES (@id, @name); INSERT INTO child (parent_id, val) VALUES (@id, @val);—— 这绕过了默认约束，失去顺序性保障，且并发下可能撞 ID（虽概率极低） - ✅ 正确做法：
INSERT INTO parent (name) OUTPUT INSERTED.id VALUES (@name);—— 让 SQL Server 在插入瞬间生成并返回，既保持默认约束语义，又避免应用层干预
如果一次插多行并需批量返回，OUTPUT 同样支持：INSERT INTO parent (name) OUTPUT INSERTED.id, INSERTED.created_at SELECT name FROM @temp_table;。此时返回结果集可直接 INSERT INTO #tmp_ids 供后续使用，无需循环。
跨数据库移植时别硬写 NEWID()，改用应用层生成标准 UUID v4
若存储过程未来要迁到 PostgreSQL 或 MySQL，硬编码 NEWID() 会导致语法报错或行为不一致。例如：
- MySQL 的
UUID()返回带短横线字符串，而 SQL Server 的UNIQUEIDENTIFIER存二进制，直插会失败 - PostgreSQL 的
gen_random_uuid()需手动启用pgcrypto扩展，且类型为UUID，非字符串
稳妥方案是：在应用层（C# 的 Guid.NewGuid()、Java 的 UUID.randomUUID()）生成标准 UUID v4 字符串，传入存储过程作为参数；表字段仍用 UNIQUEIDENTIFIER，SQL Server 自动转换。这样既保留跨库兼容性，又避免 T-SQL 层面对数据库特性的强耦合。真正难处理的从来不是生成动作本身，而是生成后的插入位置控制和跨环境一致性——这两点必须从建表和调用链路设计阶段就定死。
