![]() |
1
3
确保在这些列上有一个聚集索引。 在这些日期列上对表进行分区,并将数据文件放在不同的磁盘驱动器上 我相信保持低指数是你最好的选择。 我也相信,用理想的选择来观察物体并不是一个好主意, 因为它增加了插入/更新开销。 平均每分钟插入3,5次。 或者每次插入之间大约17秒(如果我错了,请平均纠正我) 问题是你是不是每17秒就要选择一次? 这是关键的想法。 希望有帮助。 |
![]() |
2
12
在所需的列(年和月)上使用简单索引应该 大大提高 要么是 独特的 或 小组通过 查询。 我不会使用辅助表,因为这会增加维护辅助表的额外开销(插入/更新删除需要验证辅助表) 编辑: 你甚至可以考虑使用 Improving Performance with SQL Server 2005 Indexed Views |
![]() |
3
3
使用“物化视图”(也称为“带架构绑定的索引视图”),然后索引此视图。执行此操作时,SQL Server将在后台创建和维护辅助表中的数据,并在适当时选择使用此表上的索引。 这与同事的建议类似,优点是不需要向查询中添加逻辑就可以利用它,SQL Server将在创建查询计划时执行此操作,SQL Server也将自动在索引视图中维护数据。 以下是实现此目标的方法:创建一个返回不同[月][年]值的视图,然后在该视图上索引[年][月]。同样,sql server将在视图上使用小索引,避免在大表上扫描表。 由于SQL Server不允许您使用DISTINCT关键字为视图编制索引,因此请使用GROUP BY[年]、[月],并在“选择”中使用大计数(*)。它看起来像这样:
现在,当您在大表上选择distinct[year]、[month]时,查询优化器将扫描视图上的小索引,而不是扫描大表上的数百万条记录。
这项技术使我从500万次读取(估计I/O为10.9)到36次读取(估计I/O为0.003)。这方面的开销是维护一个额外的索引,因此每次更新大表时,视图上的索引也将更新。 如果你发现这个指数大大减缓了你的加载时间。删除索引,执行数据加载,然后重新创建它。 完整工作示例:
|
![]() |
4
1
创建的物化索引视图:
现在,您可以访问预先计算的不同值,而不必每次都完成工作。 |
![]() |
5
1
将日期设为表的聚集索引键中的第一列。这对于历史数据来说是非常典型的,因为大多数查询(如果不是全部的话)都对特定的范围感兴趣,而一个及时的聚集索引可以解决这个问题。“五月”等所有查询都需要作为范围处理,例如:
虽然这对程序员来说似乎很复杂,但这是处理数据库设计问题的最佳方法。 |
![]() |
S. Jacson · 任意两台发电机的速度差(内置功能) 2 年前 |
![]() |
Sadeq Dousti · 相当于“嵌套删除”的执行性能SQL查询 2 年前 |
![]() |
Prince · 复制大型文件需要更多时间 2 年前 |
![]() |
Sagar · 为什么在循环之外声明变量会更快? 2 年前 |
![]() |
seco · 如何在不挂起页面的情况下加载JS 2 年前 |