我們有一個大型的數據表，其中每天約有300000000行，目前每天增長100000行，這個數字會隨着時間的推移而增加。網絡上顯示的大表上的統計數字
今天我們產生直接從數據庫（MS-SQL 2012）不同的報告，並做大量的計算。
問題是這需要時間。我們有索引等，但今天的人們需要非常快速的報告。
我們也希望能夠改變timeperiods，不同的方式來看待數據等。
我們只需要看看這是一日齡，所以我們可以從昨天把所有的數據，並用它做什麼，以加快查詢和報告的數據。
所以，做任何你有一個解決方案的任何好的想法，這將是快速，仍然可以透過網路在Excel或者BI工具上。
今天所有的報告都是在asp.net C＃Web表單與querys對MS SQL 2012表..
你有一個OLTP系統。您通常希望在這樣的系統上最大化您的吞吐量。報告需要鎖存和鎖定來獲取數據。這會拖累OLTP的吞吐量，報告（附加索引）的好處將會對您的OLTP造成不利影響，因爲這會對性能產生負面影響。甚至不認爲拍掌WITH(NOLOCK)將減輕一些負擔。 ;）
正如其他人所指出的，你可能會想看看從報告數據中分離出有效的數據。
表進行分區可以做到這一點如果你有企業版。否則，您需要根據您的數據訪問方式進行一些駭客操作，如Paritioned Views，這些駭客可能會或可能不會爲您工作。
我會看看從系統中定期提取所需數據並將其推送到別處。無論其他位置是同一個數據庫中不同的一組表，還是同一臺服務器上的不同目錄或完全不同的服務器，都將取決於大量變量（成本，實施時間，數據複雜性，速度要求，存儲子系統等） ）。
因爲聽起來你沒有超級特定的報告要求（目前你看過昨天的數據，但很高興看到更多，等等），我會考慮在報告表中實施Columnstore Indexes。它爲查詢聚合提供了驚人的性能，即使在聚合表上也有優勢，您無需指定特定的粒度（WTD，MTD，YTD等）。但缺點是它是一個只讀數據結構（並且在創建索引時存儲內存&）。 SQL Server 2014將會引入可更新的列存儲索引，這些索引將會是非常突出的，但這是暫時的。
**從不**報告實時數據。創建一個單獨的報告數據庫，甚至更好的數據倉庫和OLAP多維數據集，您將在其中存儲報告數據。在討論報告時，30M記錄的數據量相對較少* –
如果您有多個人對相同的數據調用相同的報告，則可以對其進行緩存。 – Todoy
如果您不想使用BI解決方案，是否考慮過對錶進行分區，那麼如果您只查看日期數據並正確分區表，則查詢可能只需要評估一天值得一排。 – steoleary