1.合理增加索引
表索引可以加快對錶中資料的檢索速度，但是會降低表中資料的更新速度，所以增加表的索引一定控制在合理範圍內，過多的索引不但不會降低資料庫的壓力，反而可能增大資料庫的壓力，表索引的建立一般要從具體業務場景出發，對於讀多寫少的場景，可以通過適當的增加索引來提高效率，對錶的那些列建立索引？建立單獨索引還是建立復合索引？要根據具體的業務場景來決定，建立索引之後可以針對索引對業務邏輯中使用的sql進行優化，建立索引是最基礎的手段，這裡不錯過多的介紹。
2.資料截轉
一般情況下，業務中所處理的資料的都具有一定的時間間隔，所以可以通過對業務進行梳理，將當前時間間隔之外的資料進行截轉，截轉到歷史資料庫中，通過對業務進行拆分，當需要歷史資料時，可以轉到歷史資料庫中進行查詢，或者修改，通過減少當前資料庫的資料量，來減輕當前業務資料的壓力。資料截轉一般情況下是按照時間來進行，所以在業務員資料庫設計的時候就要考慮到時間這個因素。
資料截轉可以進行間隔一段時間做一次手工的資料截轉，也可以啟動乙個定時器，每個一段時間進行一次資料截轉，推薦的方式是準實時截轉，及每天在業務量較小的時間，啟動任務實時截轉。
資料截轉需要注意的幾個問題：（1）外來鍵關聯關係（特別是有主鍵id的關聯的）注意在截轉的歷史資料庫中的關聯關係是否正確。(2)保證生產庫和歷史庫的業務關聯關係，從而避免歷史庫的資料需要關聯生產庫中的資料。
3.增加快取
快取是降低資料壓力乙個強有力的手段，基本是所有系統大型web系統中都會使用到，所以現代的大型web系統的架構一般如圖。
現代web架構
請求1到達webserver之後，首先執行2訪問快取，如果hit則返回，miss則執行3訪問資料庫，在執行4同步到快取中，再返回。但是不是快取並不是萬能的，快取也有其使用的業務場景，一般在讀多寫少，資料重複查詢比較集中的場景下，快取可以大大提高效能，快取操作順序非常重要，不合理的操作順序，在併發場景下常常會導致資料的不一致，快取的具體操作可以參考快取架構設計細節二三事這邊文章。
4.生成寬表，冗餘資料
有些業務例如報表、資料彙總等需要資料量較多，此時可能需要進行多表聯合查詢，聯合查詢操作非常消耗資料庫的效能，所以在這種業務場景下為了避免過大的效能消耗，往往需要將查詢時的多個表按照關聯條件進行關聯，生成一張含有冗餘資訊的包含所有表的多個欄位的大寬表，這樣在進行查詢時，只在一張表中進行查詢，效能明顯得到提公升。大寬表的生成是在業務流程中生成還是通過非同步化任務來生成，根據具體的業務邏輯來定。
5.修改關係型資料庫為非關係性資料庫
非關係型資料庫，也就是我們通常說的nosql資料，最常見就是key/value型別的資料庫，這類資料庫不強調表的關係，但是查詢速度非常快，所在某些具體場景下，我們應該優先選擇nosql資料庫，例如字典資訊表的查詢。
6.讀寫分離
如果採用單點資料資料庫，就算對資料進行上述的相關優化，但是由於其本身的單點性，所以隨著流量的激增，資料庫仍然會成為系統的瓶頸，如何對資料進行拆分來解決這個問題了，讀寫分離就是最常用的方法，讀寫分離的原理如下圖。
讀寫分離
讀寫分離技術現在已經應用的很成熟，通過將資料拆分為兩個例項，讀寫分離操作改善了資料單點的瓶頸，分攤了資料庫壓力，而且當主資料庫宕機之後可以迅速的切換到從庫，而不會導致業務不可用，同時也起到資料備份的作用，由於存在兩個資料例項，所以資料怎麼由主庫同步到從庫、主從之間延遲引發的資料不一致問題，以及怎麼來分離業務中讀和寫操作成為要解決的問題成為要解決的問題。主從同步可以參考mysql主從架構的複製原理及配置這篇文章，從主資料一致可以參考db主從一致性的幾種解決方法這篇文章。
7.資料庫拆分
採用讀寫分離之後，資料庫已經變為兩份例項，資料庫的壓力已經得到分攤，如果資料庫的壓力還是過大時，這是就要從業務方面著手，將具體業務細分，將業務對應的表分拆到不同的資料庫當中，如下圖。
拆庫業務變動較大，同時要對系統內部之間的相互呼叫提供介面，呼叫方式可以選用rpc、restful、jmq訊息等方式。一般情況下，資料庫垂直拆分做的足夠細分的話，加上讀寫分離技術，加上適當的資料截轉就可以滿足一般的大型業務系統對效能的需求。
8.表的垂直拆分
資料庫可以進行垂直拆分，當然也可以對資料庫中的表進行垂直拆分，對錶進行拆分就是對資料拆分的再拆分，如圖。種解決方法只適用於一些特定的場景，例如對錶進行垂直拆分，通過非同步化呼叫將所有任務非同步化，前提是總的任務可以進行分布的非同步化操作，在實際應用比較少，因為設計的表只要復合三正規化的要求，一般是很難在進行拆分的，應用較多是對錶進行水平拆分。
9.表的水平拆分
如果已經做了資料庫拆分，並且進行了讀寫分離，資料壓力還是過大，主要原因就是資料庫表中的記錄太多，或者對資料進行了截轉，但是對歷史資料的操作還是比較頻繁的，且隨著截轉的歷史資料越來越多，歷史資料庫的壓力也邊的也變的越來越大，這時有兩種解決方案：第一種方案就是對資料庫中的表進行垂直拆分，從而不用在截轉資料，通過不斷對錶進行水平拆分，保證資料資料庫中單錶的記錄數保持在乙個高效能合理的範圍之類，通過擴容將不同分配到不同的資料中（分庫分表）來保證資料庫的壓力，應用在訪問時，通過分庫分表的條件進行路由，就可以取到資料。第二種就是仍舊對資料進行截轉，當歷史資料資訊過多從而導致資料庫壓力過大時，採用搜尋引擎的方式來解決。相比於第一種操作第二種方案適用於讀操作上，對與寫操作，具有一定的侷限性，第一種方案具有一定的通用性。對錶進行水平拆分的過程如圖所示。
資料庫壓力
update造成壓力大的很重要的因素，因為它 在where條件 後面加函式後無視索引，select from tablename where function table 欄位 這條語句會查詢整個表，即便是這個表有索引。所以如果涉及到select，update的情況，資料量少點還好，如果資料量大的話...
資料庫壓力測試方法小結
在前面的壓力測試過程中，主要關注的是對介面以及伺服器硬體效能進行壓力測試，評估請求介面和硬體效能對服務的影響。但是對於多數web應用來說，整個系統的瓶頸在於資料庫。原因很簡單 web應用中的其他因素，例如網路頻寬 負載均衡節點 應用伺服器 包括cpu 記憶體 硬碟 連線數等 快取，都很容易通過水平的...
資料庫壓力測試方法總結
一 前言 在前面的壓力測試過程中，主要關注的是對介面以及伺服器硬體效能進行壓力測試，評估請求介面和硬體效能對服務的影響。但是對於多數web應用來說，整個系統的瓶頸在於資料庫。原因很簡單 web應用中的其他因素，例如網路頻寬 負載均衡節點 應用伺服器 包括cpu 記憶體 硬碟 連線數等 快取，都很容易...