问题的历史： 自1970年代以来，时间区间分析一直困扰着关系数据库，因为SQL最初设计时没有原生的区间类型。早期的解决方案依赖于基于游标的迭代或区间之间的笛卡尔积，导致了二次复杂性。SQL:2003引入窗口函数和ROWS BETWEEN框架规定，使得高效的运行聚合成为可能，为现代事件基础的并发计算奠定了基础。
问题： 确定最大并发性需要理解状态变化发生的确切时刻——特别是预订何时开始或结束。幼稚的做法将每个区间扩展为离散时间单位（时间切片），对于长时间停留来说计算成本极高。核心挑战在于计算某个特定时刻有多少个区间重叠，而无需具体化时间线上的每个时刻。
解决方案： 采用离散事件模拟模式。通过UNION ALL将区间表转化为事件流，为每个入住（开始）分配权重**+1**，为每个退房（结束）分配权重**-1**。通过按时间顺序对这些事件进行排序，并通过**SUM() OVER (ORDER BY ...)**窗口函数应用运行总和，可以推导出每个转换点的活跃数量。这个运行总和的最大值代表了峰值并发性。
WITH events AS ( SELECT check_in AS event_time, 1 AS delta FROM reservations UNION ALL SELECT check_out AS event_time, -1 AS delta FROM reservations ), concurrency AS ( SELECT event_time, SUM(delta) OVER ( ORDER BY event_time, delta DESC ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW ) AS active_count FROM events ) SELECT MAX(active_count) AS peak_concurrency FROM concurrency;
问题描述： 一家豪华度假连锁在假期周末遭遇神秘的超额预订事件，尽管其可用系统报告有空房。遗留查询通过将每个预订拆分为单独的晚间行来计算每日入住率，使用递归CTE，为一个月的住宿生成数百万行。在新年夜的分析中，这种方法需要12秒来执行，并造成了预订事务表的死锁，阻止了实时预订。
解决方案A：使用计数表的时间切片扩展。 运营团队最初建议预先生成一个日历表，并使用event_date BETWEEN check_in AND check_out关联它与预订。此方法提供了直观的每日聚合，兼容标准的GROUP BY子句。优点：对于业务分析师来说概念上简单，容易与现有的BI工具集成。缺点：生成**O(N × D)**行，其中D是平均持续时间，导致指数增长；在分钟级粒度或长期租赁时灾难性失败；消耗过多的tempdb空间。
解决方案B：具有物化路径的区间树。 一位高级架构师建议使用嵌套集实现一个段树结构来索引区间边界，从而启用对重叠查询的对数时间复杂度。优点：对于频繁更新和点查询的理论复杂度最优。缺点：需要复杂的触发器来维护树平衡；通过依赖过程扩展违反ANSI SQL可移植性；在预订高峰期间引入的写放大影响了OLTP工作负载。
解决方案C：具有运行总和的时间顺序事件流（选择）。 数据库团队采用了基于事件的方法，将每个预订边界视为一个增量操作。这将数据集从数百万个拆分的行减少到2N个事件（每个预订的开始和结束）。优点：O(N log N)复杂度主要受排序操作影响，恒定的内存占用，且纯ANSI SQL在PostgreSQL、Oracle和SQL Server中完全兼容。缺点：需要仔细处理同时事件，并不会自然而然识别出哪些具体的预订影响了峰值，而没有额外的连接。
结果： 查询延迟从12秒降低到45毫秒。分析表明，真正的瓶颈并不是房间库存（500个单元），而是电梯容量，因为320位客人试图同时在晚上6点入住。这一见解促使实施错时入住等级，而不是建造新翼，节省了200万美元的资本支出，同时消除了死锁。
为什么解决方案需要 ORDER BY event_time, delta DESC 特别地，这个次要排序在缺省时会发生什么？
候选人经常忽略共享时间戳的边界条件语义。当一位客人在上午10:00正好退房而另一位客人在上午10:00正好入住时，处理顺序决定房间是否同时被两位客人占用。通过使用 delta DESC 排序，我们确保 -1 (离开) 在相同时间戳上先于 +1 (到达) 被处理。若省略这个次要排序，运行总和临时下降后又跳升，可能在之前的状态实际上更高时记录了虚假的峰值。这种微妙的排序防止了因一而误差导致的生产系统中的超额预订漏洞。
如果要修改这个查询以识别在哪个特定的预订在峰值并发时是活跃的，而不仅仅是数量，该怎么办？
大多数候选人尝试在同一个CTE中进行过滤，未能意识到峰值可能跨越一个连续区间而不是单个点。稳健的方法需要使用两次扫描策略：首先，通过子查询或CTE孤立出active_count等于最大值的时间戳，然后使用重叠谓词r.check_in <= peak.event_time AND r.check_out > peak.event_time回到原始预订表进行连接。候选人忽视了多个时间戳可能共享相同的最大值，因此在峰值平台在跨多个事件过渡期间持续时，必须使用DISTINCT或EXISTS子句避免重复列出预订。
如果商业规则发生变化，使得退房时间为包含性（客人占用房间直到晚上11:59）而不是排他性，则需要什么修改，这如何影响事件加权？
候选人往往忽视区间边界语义。包含性端点[start, end]在一个预订结束而另一个预订开始的同一天时会产生重叠。解决方案要求在生成**-1**事件之前，将包含边界转换为排外方式，通过在退房时间上添加一个无穷小的ε（或下一个离散时间单位）。或者，调整连接逻辑，使用check_out >= event_time，同时保持运行总和逻辑不变。未能进行此调整会将离散事件模型从半开区间转换为闭合区间，导致算法报告出冲突并导致在高周转期间实际容量低估了一个单位。