必须将时间过滤条件置于主表外层，子表仅用于存在性判断；否则子查询独立执行导致索引失效、漏数据，且IN遇NULL逻辑失控，应改用EXISTS并建立order_id+updated_at复合索引。
嵌套查询里时间戳字段没走索引，查得慢还漏数据
直接在子查询里用 WHERE updated_at > @last_time 过滤，外层再 JOIN 或 IN，看起来逻辑清楚，但执行计划常把子查询当独立结果集先算完——updated_at 上的索引根本没用上，查得慢，还漏行。
更致命的是语义陷阱：比如订单主表更新了，但子表（如 order_items）没动，子查询就筛不出这条 order_id，外层 IN 就丢掉整个订单。
- 必须把时间过滤条件放在主表（如
orders.updated_at），子表只用于存在性判断或关联补全 - 避免写成
SELECT * FROM orders WHERE id IN (SELECT order_id FROM order_items WHERE updated_at > ?) - 改用
EXISTS+ 外层主表时间过滤，让索引生效且语义明确
用 EXISTS 替代 IN 避免 NULL 和性能陷阱
IN 在子查询返回 NULL 时行为不可控：只要子结果含 NULL，整条 IN 判断就为 UNKNOWN，该行被过滤掉，不是你想要的“不存在”逻辑。
EXISTS 只关心是否存在匹配行，不拉数据、不判 NULL，执行器也更容易把谓词（比如 i.updated_at > ?）推入内层做索引查找。
- 正确写法：
SELECT o.* FROM orders o WHERE o.updated_at > '2026-06-30' AND EXISTS (SELECT 1 FROM order_items i WHERE i.order_id = o.id AND i.updated_at > '2026-06-30') - 务必给子表建复合索引：
CREATE INDEX IX_order_items_orderid_updated ON order_items(order_id, updated_at) - 别依赖
SELECT *在子查询里——SELECT 1足够，减少数据传输开销
MERGE 里嵌套查询当源，参数传错就全表覆盖
用 MERGE INTO target USING (nested_query) AS src 做增量同步很常见，但一旦时间参数没传对（比如 @last_time 是 NULL），WHERE updated_at > @last_time 永远为假，USING 结果为空——WHEN NOT MATCHED 就会把源表所有行插入目标表，相当于全量重刷。
- 每次执行前校验参数：
IF @last_time IS NULL THROW 50000, 'last_time cannot be NULL', 1; - 在
USING子句里显式加WHERE过滤，别指望外层ON或WHEN条件兜底 - 同步任务成功后，必须立刻持久化新位点到控制表（如
sync_control），不能只靠变量临时存
深嵌套导致日志暴涨，拆成临时表分步控制
三层以上嵌套（比如主表 → 关联子表 → 关联子子表 → 时间过滤）会让 SQL Server 执行计划难以优化，容易触发大事务、长日志链，甚至阻塞其他操作。
生产环境别硬扛，把中间结果落盘更稳。
- 先用
SELECT order_id INTO #new_orders FROM orders WHERE updated_at > @last_time提前筛出主键集 - 再基于
#new_orders关联子表，加EXISTS或JOIN补数据 - 最后用
MERGE或批量INSERT/UPDATE写入目标，每步都可控、可查、可加索引
真正难的不是写出来，是确认每一层过滤都落在可索引字段上，且时间边界（> 不是 >=）、空值处理（IS NOT NULL）、时区对齐（统一用 UTC）这些细节是否全部到位。
