我正在使用SQL 2005（標準版）數據庫的數據驅動的Web應用程序。SQL 2005數據庫中的大量表需要更好的性能！
其中一個表格是相當大的（800萬+行大約30列）。表的大小明顯影響網站的性能，即通過存儲的特效選擇表中的項目。該表已編入索引，但由於表中的行數很大，性能仍然很差 - 這是問題的一部分 - 該表與已更新的表相同，因此無法添加/刪除索引操作更糟糕。
我在這裏的目標是在從表格中選擇項目時提高性能。該表具有「當前」數據和舊/未觸摸的數據。我們現階段能夠想到的最有效的解決方案是將表格分成2份，即一份用於舊商品（在某個日期之前，即2005年1月1日之前），另一份用於新商品（等於或在2005年1月1日之前） 。
我們知道分佈式分區視圖這樣的事情 - 但所有這些功能都需要企業版，客戶端不會購買（並且不會拋出硬件也不會發生）。
即使它沒有聞起來像正確的方式去做，你總是可以推出自己的「窮人的分區/ DPV」。這僅僅是一個廣泛的概念方法：
本年度的數據創建一個新表 - 相同的結構，相同的指標。調整寫入主大表的寫入兩個表的存儲過程（暫時）。我建議在存儲過程中使用IF CURRENT_TIMESTAMP> ='[一些沒有時間的整個日期]'這樣的邏輯 - 這可以很容易地回填表中的數據，該表中的數據會在開始記錄的過程之前進行更新。
使用主表中的SELECT INTO爲歷史中的每一年創建一個新表。您可以在同一實例的不同數據庫中執行此操作，以避免當前數據庫中的開銷。我假設歷史數據不會改變，所以在其他數據庫中，您甚至可以在完成後才能讀取它（這會顯着提高讀取性能）。
一旦您擁有整個表的副本，就可以創建僅引用當前年份的視圖，將當前年份引用2005的另一個視圖（通過在當前表與其他數據庫之間使用UNION ALL > = 2005），另一個引用所有三組表格（提到的那些，以及2005年之前的表格）。當然，你可以打破這個更多，但我只是想保持最小的概念。
將讀取數據的存儲過程更改爲「更智能」 - 如果請求的日期範圍在當前日曆年內，則使用僅爲本地的最小視圖;如果日期範圍> = 2005，則使用第二個視圖，否則使用第三個視圖。如果您所做的不僅僅是插入僅與當年相關的新數據，您還可以使用存儲過程編寫類似的邏輯。
在這一點上，你應該能夠停止插入到大量的表中，並且一旦一切都被證明是有效的，放下它並回收一些磁盤空間（我的意思是釋放數據文件中的空間（ s）重複使用，不執行收縮數據庫 - 因爲您將再次使用該空間）。
我沒有關於您情況的所有詳細信息，但如果您有任何問題或疑慮，請繼續跟進。我已經在幾個移植項目中使用了這種方法，包括現在正在進行的項目。
對於像重建/重組這樣的索引維護任務，您應該使用這些實用程序之一幫助您將猜測從哪個索引重建以及重新組織哪些索引。 Michelle Ufford的劇本在這裏（請注意她的博客中即將推出新版本）：http://sqlfool.com/2009/06/index-defrag-script-v30/和Ola Hallengren的劇本在這裏：http：// ola。 hallengren.com/ –
我們經常重新組織和重建索引，作爲日常維護的一部分。索引儘可能優化。 驅動器已經過整理，因爲它會得到 - 系統是一個24小時系統，沒有負載平衡，所以我們不能讓系統脫機足夠長的時間來對驅動器進行完整的碎片整理。我知道這並不理想，但他們是一個不理想的世界。 – Scozzard
文件上的自動增長設置是什麼？文件系統碎片不應該真的成爲性能問題，除非您的自動增長設置非常小或磁盤佈局設計不當。 –
性能差，由於行的表中的絕對數量
800萬行不健全所有的瘋狂。你有沒有檢查你的查詢計劃？
表作爲同樣讀作更新
你實際更新索引列，或者它同樣讀取和插入來？
（不，它扔硬件是不會發生任何）
這是一個遺憾，因爲RAM是便宜。
你的權利，800萬行不瘋狂。但是，表格是系統中最常用的表格，經常遇到讀寫操作。由於試圖優化另一個讀取和寫入的查詢計劃是悲慘的 - 換句話說，我們處於僵局。 – Scozzard
回覆：閱讀/更新 是的，我的不好，我的意思是寫（插入） - 我們對該表的寫操作造成系統中30％的SQL超時。不幸的是，由於這是一個同步的Web應用程序，我們沒有延長超時的好處，因爲性能已經是一個普遍的抱怨，而這隻會讓情況變得更糟。我們意識到目前的結構不會繼續「運轉」，並且正在尋找最佳的替代結構，而不會從頭開始重建應用程序（雖然這是理想的，不會發生的）。 – Scozzard
回覆：RAM - 是的，你是對的。不幸的是，在簽約的世界裏，我們可以盡我們所願地提出建議，但最終的決定是客戶。他們只是爲它購買了新的硬件，而新的更新（甚至升級）則需要3年的時間。在某些情況下，數據庫結構需要根據舊數據和當前數據的數量進行校正，這是多餘的 - 我們想要嘗試修復而不是修補。 – Scozzard
感謝您的回答，我們最初的印象是，歷史數據仍然是可更新的，但最近發現我們可以只讀。所以你的答案聽起來像是一個不錯的選擇，歡呼:) – Scozzard