SQL Server中“数据填充”指用嵌套查询动态生成值填入目标列：1. WHERE中用IN/EXISTS子查询实现条件批量更新；2. SELECT中用标量子查询填充派生列；3. INSERT…SELECT中嵌套构造新记录。
SQL Server 本身没有“数据填充”这个内置操作概念，所谓“通过嵌套查询实现自定义的数据填充”，实际指的是用嵌套查询（子查询）驱动 INSERT、UPDATE 或 SELECT 语句，把计算出的、关联出的、条件筛选出的值，填入目标列或临时结果中——本质是“用查询逻辑代替硬编码值”。直接写死值或用 DEFAULT 不算“自定义填充”，靠子查询动态生成才算。
WHERE 子句里用子查询做条件填充
这是最常见也最容易出错的场景：你想更新/插入一批记录，但判断依据不是固定值，而是另一张表的实时聚合结果或关联状态。
- 错误写法：
UPDATE Orders SET Status = 'Processed' WHERE CustomerID = 123—— 只能填死值，无法适配多客户逻辑 - 正确做法：用子查询返回符合条件的
CustomerID集合，再批量作用于主表UPDATE Orders SET Status = 'Processed' WHERE CustomerID IN (SELECT CustomerID FROM Customers WHERE Region = 'North' AND LastOrderDate > '2025-01-01') - 注意点：
IN子查询必须返回单列；若可能为空，IN (NULL)会整个失效，应改用EXISTS或显式处理空集 - 性能影响：子查询若未加索引（比如
Customers.Region），外层UPDATE会变慢甚至锁表
SELECT 子句里用标量子查询填充派生列
当你需要在查询结果里“现场计算并填充”一列（比如每个客户的最新订单时间、平均评分、是否 VIP），且该计算依赖另一张表，就用标量子查询（返回单个值）。
- 示例：
SELECT CustomerName, (SELECT MAX(OrderDate) FROM Orders o WHERE o.CustomerID = c.CustomerID) AS LastOrder FROM Customers c - 关键限制：子查询必须保证对每一行都返回 0 或 1 个值；如果可能返回多行，SQL Server 直接报错
Subquery returned more than 1 value - 替代方案：改用
LEFT JOIN+GROUP BY更高效，尤其数据量大时；标量子查询适合逻辑简单、子表小或仅需单值的场景 - 兼容性提醒：SQL Server 支持，但某些旧版客户端工具（如老旧 SSMS 插件）可能对嵌套过深的标量子查询渲染异常
INSERT … SELECT 中嵌套查询构造填充数据
真正意义上的“填充表”动作，往往发生在从已有数据构造新记录时。这时不能靠 VALUES，而要靠 INSERT ... SELECT，且 SELECT 部分可含多层嵌套。
- 典型用途：按规则生成测试数据、补全缺失维度、迁移清洗后数据
INSERT INTO ProductSummary (ProductID, Category, AvgPrice, LastUpdated) SELECT p.ProductID, p.Category, (SELECT AVG(Price) FROM Sales s WHERE s.ProductID = p.ProductID), GETDATE() FROM Products p WHERE p.IsActive = 1 - 容易踩的坑：
SELECT列数和顺序必须与INSERT目标列严格一致；子查询若引用了外部p别名，必须确保别名在作用域内（即不能在子查询里重新定义同名表） - NULL 处理：标量子查询没匹配到行时返回
NULL，这通常符合预期；但如果你需要默认值（比如 0），得包一层ISNULL(..., 0) - 事务安全：这类
INSERT建议显式加BEGIN TRAN，尤其涉及多表关联时，避免部分成功导致数据不一致
嵌套查询填充真正的复杂点不在语法，而在执行计划不可见性——你写的是一行子查询，SQL Server 可能为它生成嵌套循环、哈希匹配或排序合并，而这些行为只在 SET STATISTICS XML ON 后看执行计划才能确认。没验证过性能就上线，很容易在数据量翻倍后突然卡住。
