一、資料庫性能瓶頸主要原因
1、資料庫連接配接
MySQL資料庫預設連接配接為100，我們可以通過配置initialSize、minIdle、maxActive等進行調優，但由于硬體資源的限制，資料庫連接配接不可能無限制的增加，對大型單體應用單執行個體資料庫可能會出現最大連接配接數不能滿足實際需求的情況，這時就會系統業務阻塞。
2、表資料量大（空間存儲問題）
普遍觀點認為單表資料量超過1000萬條時就是出現資料庫讀取性能瓶頸。從索引角度分析，如果索引未被命中，資料庫系統就會全表掃描，資料量越大，掃描全表的時間就會越長；即使索引被命中了，由于B+TREE索引是存放在硬碟上的，資料量越大B+TREE層次越深，IO次數也就越多。
3、硬體資源限制
硬體資源直接影響QPS每秒查詢數/TPS每秒事務數。
二、資料性能優化方案
常見的資料性能優化方案：SQL優化、緩存、建立索引、讀寫分離、分庫分表等。
解決大資料量性能優化，真正有效方案是采用分布式資料存儲，即上面所述讀寫分離和分庫分表。
1、讀寫分離
讀寫分離基于主從複制，采用差別讀、寫多資料源方式進行資料的存儲和加載。資料的存儲（增删改）指定寫資料源，資料的讀取查詢指定讀資料源。
通過讀寫分離複制與master相同的資料源（一主多從），多資料源可以部署到不同主機上，進而可以解決資料裡連接配接瓶頸和硬體資源限制問題。
2、分庫分表
對資料的庫表進行拆分，用分片的方式對資料進行管理。
垂直拆分
資料庫垂直拆分将單一庫拆分多個領域資料庫，使各領域資料庫移植性更好，功能劃分更清晰。同時也能解決資料庫連接配接、硬體資源限制問題。任何一種方案在解決問題的同時，也會帶來新的問題，分庫分表也不例外，比如關聯查詢變得複雜、分布式事務問題等。
水準拆分
水準拆分是将大表按照一定規則拆分成若幹個小表，比如将3000萬資料量的一張單表user拆分為3個小表user01、user02、user03。主要解決了單表資料量大問題，進而也就解決了存儲空間帶來的資料庫性能瓶頸。
3、優化查詢
經過對資料庫的了解後，我發現，資料庫查詢的最該優化的地方還是資料庫優化。首先就是
加索引
索引要加給需要查詢的列，對于執行的sql，我們要使用EXPLAIN進行查詢分析，看查詢是否走的索引。
如果查詢傳回的資料過多，會導緻cpu和記憶體占用過大，用show profile for query去檢視查詢狀态時，sending data過大時，就可能是傳回資料過多。sending data的耗時來源于sending和sort的時間之和，去掉排序，時間也能快很多。還要關注一下limit這裡，比如limit 2000,60它這裡實際會走一個掃描前2000個，如果有條件就比較好了，比如id>2000 limit 1,60這樣其實就好的很多。是以對于傳回結果比較大的查詢，引出了第二個政策
切分條件
切分條件就是查詢的時候将條件分的細一些，這樣查出的每段資料都很少一些，limit的時候，掃描也少一些。
4、多線程查詢
既然做了切分條件，那麼多線程查詢也是必不可少的。多線程查詢再聚合資料，這才能将時間效率提到最高，對與多線程，主要還是java背景做的
參考資料