数据行的粒度答案

【问题标题】：Granularity of data rows数据行的粒度
【发布时间】：2013-06-05 05:04:53
【问题描述】：

我们正在开发一个应用程序，该应用程序具有一项管理向人们付款的功能。付款将写入表中的一行，包含以下字段：

PersonId (INT)
TransactionDate (DATETIME)
Amount (MONEY)
PaymentTypeId (INT)
...
...
...

看起来我们与大约 8000 人打交道，我们向他们发送付款，并且每天每人增加一笔新交易（每天大约 8000 次插入）。这意味着 7 年后（我们需要存储数据的时间），我们将拥有超过 20,000,000 行。

我们每年增加大约 10% 的人，所以这个数字略有上升。

最常见的查询是获取每个人的 SUM(Amount)，其中 Transaction Date 介于开始日期和结束日期之间。

SELECT PersonId, SUM(Amount)
FROM Table
WHERE PaymentTypeId = x
AND TransactionDate BETWEEN StartDate AND EndDate
GROUP BY PersonId

我的问题是，这是否会成为 SQL Server 2012 的性能问题？还是 20,000,000 行还不错？

我会假设PersonID 上有一个聚集索引？（将它们分组），但这会导致插入/更新非常慢？

TransactionDate上的索引？

【问题讨论】：

可能与问题没有真正的关系，但 MONEY 数据类型不被视为危险且无用吗？
很有可能...我会使用更好的数据类型。
实际上，拥有聚集索引确实不必然意味着插入速度较慢 - 恰恰相反！ 请参阅Kimberly Tripp's excellent blog post discussing the benefits of a good clustered index - 她提出的第一点是: 插入速度更快 !

【解决方案1】：

如果您的查询基于TransactionDate 和PaymentTypeId 进行选择，同时还需要PersonId 和Amount，我建议在TransactionDate 和PaymentTypeId 上放置一个非聚集索引，并包括其他两个索引中的列：

CREATE NONCLUSTERED INDEX IX_Table_TransactionDate
ON dbo.Table (TransactionDate, PaymentTypeId)
INCLUDE (PersonId, Amount)

这样，您的查询就可以从这个索引中得到满足 - 无需返回到实际完整的数据页面。

另外：如果您有可以“最终确定”的年份（没有更多更改），您可以预先计算并存储其中的某些总和，例如每天、每月等。使用这种方法，某些查询可能只是从表中提取预先计算的总和，而不必再次计算数千行的总和。

【讨论】：