为我的 SQL Server 数据库寻找横向扩展选项。
我有一个有 1500 万行的表，它每天增加 10,000 行。从可用于横向扩展的各种选项中，我选择了分区，因为只需在数据库中进行更改，并且应用程序代码将保持不变。表 I m 分区是 BOOKING 表，它具有以下列：-
1) Bookingid
2) Ordered
3) Userid
4) Starttime
5) Endtime
等等
我决定每年对这个表进行分区，所以我选择 Starttime 列作为我的分区键。首先，我创建了 BOOKING 表的副本作为 BOOKING_Partition，将 Booking 表的所有数据导入 Booking_Partition 表。
分区遵循的步骤：-
1） 创建文件组
2） 将文件附加到文件组
3） 创建分区函数
4） 创建分区方案
6 ）在分区方案
7 上使用 Starttime（分区键）和 Bookingid（我使用组合）创建集群索引) 最后我通过运行查询来检查分区是否成功。是的，我的表已成功分区。
现在我想检查我现有的查询是否有任何性能变化我检查了最常用的查询，是否在应用程序加载时获取 40 天的数据
从 Booking_Partition 选择 Bookingid、OrderId、UserId，其中 Starttime >= GETDATE()-20 AND Starttime < GETDATE()+20
以上只是一个示例，在生产中，此查询具有连接以从其他表中获取数据。
当我在分区表和非分区表分析器上运行此查询时，显示的持续时间几乎相同，性能没有差异。
选择查询执行计划的图像：-
上面的计划是针对分区表的，它显示击中分区，但正如我所说，分析器显示分区表和非分区表的持续时间没有变化。另外我不明白为什么它要访问 4 个分区来获取 40 天的数据。
现在，当我执行 UPDATE 或 DELETE 时，我的主要担忧就出现了。
当我在分区表上更新或删除时，它会在执行计划中显示急切的假脱机。
显示急切假脱机的更新查询执行计划的图像：-
我不明白为什么只有当我在分区表上更新或删除时它才在做急切的假脱机，当我在非分区表上运行相同的查询时它不做急切的假脱机。