隨著使用者的日益遞增，日活和峰值的暴漲，資料庫處理效能面臨著巨大的挑戰。下面分享下對實際10萬+峰值的平台的資料庫優化方案。與大家一起討論，互相學習提高！
案例：遊戲平台.
1、解決高併發
當客戶端連線數達到峰值的時候，服務端對連線的維護與處理這裡暫時不做討論。當多個寫請求到資料庫的時候，這時候需要對多張表進行插入，尤其一些表 達到每天千萬+的儲存，隨著時間的積累，傳統的同步寫入資料的方式顯然不可取，經過試驗，通過非同步插入的方式改善了許多，但與此同時，對讀取資料的實時性也需要做一定的犧牲。
非同步的方式有很多，目前採取的方式是通過作業每隔一段時間（5min、10min..看需求設定）將臨時表的資料轉到真實表。
1. 已有原始表a 也是在讀取的時候真正用到的表。
2. 建立與原始表a同結構的b和c,用來作資料的中轉處理，同步流程是c->b->a。
3. 建立同步資料的作業job1和記錄job1執行狀態的表，在同步的時候比較關鍵的是需要檢查job1的當前狀態，如果當前正在將b的資料同步到a，則把服務端過來的資料存到c，然後再把資料匯入到b，等到下一次job執行的時候再將這批資料轉到a。如圖1：
圖1同時，為保萬無一失和便於排查問題，應該用乙個記錄整個資料庫例項的儲存過程，在較短的時間檢查作業執行結果，如果遇到異常失敗的，應該及時通過其他方式通知到相關人員。如寫入到發郵件和簡訊表，讓乙個tcp的通知程式定時讀取傳送等等。
注：如果一天的資料達到幾十個g，如果又對這個表有查詢要求（分割槽下面會提到），下策之一：
可將b同時同步到多台伺服器分擔下查詢壓力，減少資源的競爭。因為整個資料庫的資源是有限的，如插入操作，會先獲得乙個共享鎖，然後通過聚集索引定位到某一行資料，再公升級為意向鎖，而sqlserver對鎖的維護根據資料的大小需要申請不同的記憶體，造成了資源的競爭。所以應該盡可能的將讀和寫分開，可根據業務模型分，可根據設定的規則分；在平台性的專案中應該優先保證資料能有效的插入。
在不可避免的查詢大資料肯定會耗用大量的資源，如遇到批量刪除的時候，可以換成以迴圈分批次（如一次2000條）的方式，這樣不至於這個程序導致整個庫掛掉，衍生出一些無法預計的bug。經實踐，有效可行，只是犧牲了儲存空間。也可根據查詢需求將表裡資料量大的字段拆分出來到新錶，當然這些也要根據每個業務場景結合需求來設定，設計出適合而並不需要華麗的方案即可。
2、解決儲存問題
如果每天單錶的資料都達到了幾十個g，改善儲存方案自然迫不及待了。現分享下自有的方案，在暴漲的資料摧殘之下，仍堅守在一線！現舉例對自有環境分享拙見：
現有資料表a，單錶每天新增資料30g，在儲存的時候採用非同步將資料同步的方式，有的不能清除資料的表，在分割槽後還可分檔案組，將檔案組分配到不同的磁碟中，減少io資源的競爭，保障現有資源的正常執行。現結合需求保留歷史資料5天：
1. 這時需要通過作業job根據分割槽函式去生成分割槽方案，如根據userid或者時間欄位來分割槽；
2. 將表分割槽後，查詢可以通過對應的索引，快速定位到某一段分割槽；
www.cppcns.com3. 通過作業合併分割槽將不要的分割槽資料轉移到相同結構和索引的表，然後清除這個表的資料。
如圖2：
圖2通過sql查詢跟蹤捕捉到查詢耗時長的，以及通過sql自帶的儲存過程sp_lock或檢視dm_tran_locks、dblockinfo檢視當前例項存在的鎖的型別和粒度。
定程式設計客棧位到具體的查詢語句或者儲存過程之後，對症下藥！藥到病除！
本文標題: sqlserver 高併發和大資料儲存方案
本文位址: /shujuku/mssql/176395.html
高併發和大資料的解決方式
現在，軟體架構變得越來越複雜了，好多技術層出不窮，令人眼花繚亂，解決這個問題呢，就是要把複雜問題簡單化，核心就是要把握本質。軟體剛開始的時候是為了實現功能，隨著資訊量和使用者的增多，大資料和高併發成了軟體設計必須考慮的問題，那麼大資料和高併發本質是什麼呢？本質很簡單，乙個是慢，乙個是等。兩者是相互關...
Redis高併發和高可用
如何保證 redis 的高併發和高可用？redis 的主從複製原理能介紹一下麼？redis 的哨兵原理能介紹一下麼？其實問這個問題，主要是考考你，redis 單機能承載多高併發？如果單機扛不住如何擴容扛更多的併發？redis 會不會掛？既然 redis 會掛那怎麼保證 redis 是高可用的？其實針...
關於SQL SERVER高併發解決方案
現在大家都比較關心的問題就是在多使用者高併發的情況下，如何開發系統，這對我們程式設計師來說，確實是值得研究，最近找工作面試時也經常被問到，其實我早有去關心和了解這類問題，但一直沒有總結一下，導致面試時無法很完整全面的回答，所以今天我專門總結概況了一下關於sql server高併發解決方案，希望能幫助...