資料庫出現效能瓶頸。用大白話來說就是資料庫快扛不住了。
資料庫出現效能瓶頸，對外表現有幾個方面：
從機器的角度看，效能瓶頸無非就是cpu、記憶體、磁碟、網路這些。
要解決效能瓶頸最簡單粗暴的辦法就是提公升機器效能，但是通過這種方法成本和收益投入比往往又太高了，不划算，所以重點還是要從軟體角度入手。
硬體層面：增加機器效能。比如：將機械硬碟換成固態硬碟。
軟體層面：sql 調優、表結構優化、讀寫分離、資料庫集群、分庫分表等。
以乙個場景舉例說明：
「user」表中有 user_id、nickname 等字段，「order」表中有order_id、user_id等字段，如果想拿到使用者暱稱怎麼辦？一般情況是通過 join 關聯表操作，在查詢訂單表時關聯查詢使用者表，從而獲取導使用者暱稱。
但是隨著業務量增加，訂單表和使用者表肯定也是暴增，這時候通過兩個表關聯資料就比較費力了，為了取乙個暱稱字段而不得不關聯查詢幾十上百萬的使用者表，其速度可想而知。
這個時候可以嘗試將 nickname 這個欄位加到 order 表中（order_id、user_id、nickname），這種做法通常叫做資料庫表冗餘字段。這樣做的好處展示訂單列表時不需要再關聯查詢使用者表了。
ps：冗餘欄位的做法也有乙個弊端，如果這個字段更新會同時涉及到多個表的更新，因此在選擇冗餘欄位時要盡量選擇不經常更新的字段。
當單臺資料庫例項扛不住，我們可以增加例項組成 集群 對外服務。
當發現讀請求明顯多於寫請求時，我們可以讓主例項負責寫，從例項對外提供讀的能力【讀寫分離】。
如果讀例項壓力依然很大，可以在資料庫前面加入快取如 redis，讓請求優先從緩訪問資料減少資料庫訪問【快取】。
1. 跨庫關聯查詢
在單庫未拆分表之前，我們可以很方便使用 join 操作關聯多張表查詢資料，但是經過分庫分表後兩張表可能都不在乙個資料庫中，如何使用 join 呢？
有幾種方案可以解決：
字段冗餘：把需要關聯的字段放入主表中，避免 join 操作；
資料抽象：通過etl等將資料匯合聚集，生成新的表；
全域性表：比如一些基礎表可以在每個資料庫中都放乙份；
應用層組裝：將基礎資料查出來，通過應用程式計算組裝；
2. 分布式事物
單資料庫可以用本地事務搞定，使用多資料庫就只能通過分布式事務解決了。
3. 分布式id
如果使用 mysql 資料庫在單庫單錶可以使用 id 自增作為主鍵，分庫分表了之後就不行了，會出現 id 重複。
常用的分布式 id 解決方案有：
3. 多資料來源
分庫分表之後可能會面臨從多個資料庫或多個子表中獲取資料。
一般的解決思路有：客戶端適配和**層適配。
業界常用的中介軟體有：
如果出現資料庫問題不要著急分庫分表，先看一下使用常規手段【sql調優、表結構優化、集群、快取】是否能夠解決。
6.2 分庫分表入門簡介
不分庫在早期階段想做乙個**系統，基本就是乙個系統包含多個基礎功能模組，最後打包成乙個 war 包部署，這就是典型的單體架構應用。
分庫該**系統在前期為了搶占市場，在部分庫這一套系統下不停地迭代更新，**量越來越大，架構也變得越來越臃腫，現在隨著系統訪問壓力逐漸增加，系統拆分就勢在必行了。
為了保證業務平滑，系統架構重構也是分了幾個階段進行。
不分表如果系統處於高速發展階段，拿**系統來說，一天下單量可能幾十萬，那資料庫中的訂單表增長就特別快，增長到一定階段資料庫查詢效率就會出現明顯下降。
一般來說：單錶超過500萬的資料量就要考慮分表了。當然500萬只是乙個經驗值，大家可以根據實際情況做出決策。
使用者在瀏覽商品列表時，只有對某商品感興趣時才會檢視該商品的詳細描述。
商品列表中商品名稱、商品、商品**等其他字段資料訪問頻次較高。
商品列表中商品描述字段往往訪問頻次較低，且該字段儲存占用空間較大，訪問時間也較長。
分表分表可劃分為：水平切分和垂直切分
垂直切分：
就拿商品表來說，表中有7個字段：id,name,url,money,address,phone,describe,size。如果 address,phone,describe,size 不常用，我們可以將其拆分為另外一張表：商品詳情表，這樣就由一張商品表拆分為了商品基本資訊表+商品詳情表，兩張表結構不一樣相互獨立。
好處：充分發揮熱門資料的操作效率，商品資訊的操作的高效率不會被商品描述的低效率所拖累。
水平切分：
從垂直拆分的角度來，其沒有從根本上解決單錶資料量過大的問題。因此我們可以做水平拆分。
比如：表中有一萬條資料，我們拆分為兩張表，id 為奇數的：1，3，5，7……放在 user1， id 為偶數的：2，4，6，8……放在 user2中，這樣的拆分辦法就是水平拆分了。
比如：按照時間維度取拆分，比如訂單表，可以按每日、每月等進行拆分。每日表：只儲存當天的資料。每月表：可以起乙個定時任務將前一天的資料全部遷移到當月表。
好處：6.3 分庫分表詳解實戰
參考：待定
「分庫分表」思想理解筆記
當一張表中的資料達到幾千萬條時，對錶進行一次查詢所花的時間將會變長。這時候，如果有聯合查詢的話，可能會卡死在那兒，甚至把系統給拖垮。而分庫分表的目的就在於此 減小資料庫的負擔，提高資料庫的效率，縮短查詢時間。另外，因為分庫分表這種改造是可控的，底層還是基於rdbms 關聯式資料庫管理系統 因此整個資...
mycat分庫分表簡單入門
本教程是在window環境下執行的，實際生產推薦在linux上執行。必備條件 自行安裝,如果不會裝請先打好基礎在來學習 在db02和db03中分別建立item表，sql指令碼如下 create database db02 create table item id int not null auto ...
mysql分庫分表入門教程
1 資料庫瓶頸 1 io瓶頸 第一種 磁碟讀io瓶頸，熱點資料太多，資料庫快取放不下，每次查詢時會產生大量的io，降低查詢速度 分庫 第二種 網路io瓶頸，請求的資料太多，網路頻寬不夠 分庫 2 cpu瓶頸 第一種 sql問題，如sql中包含join，group by，order by，非索引字段條...