本文目錄一覽：
扛得住的MySQL數據庫架構
數據庫優化是系統工程，性能的提升靠整體。本課程將面面俱到的講解提升數據庫性能的各種因素，讓你在最短的時間從小白到資深，將數據庫整體架構瞭然於胸
第1章 實例和故事 試看7 節 | 50分鐘
決定電商11大促成敗的各個關鍵因素。
收起列表
視頻：1-1 什麼決定了電商雙11大促的成敗 (04:04)試看
視頻：1-2 在雙11大促中的數據庫服務器 (06:03)
視頻：1-3 在大促中什麼影響了數據庫性能 (07:55)
視頻：1-4 大錶帶來的問題 (14:13)
視頻：1-5 大事務帶來的問題 (17:27)
作業：1-6 【討論題】在日常工作中如何應對高並發大數據量對數據庫性能挑戰
作業：1-7 【討論題】在MySQL中事務的作用是什麼？
第2章 什麼影響了MySQL性能 試看30 節 | 210分鐘
詳細介紹影響性能各個因素，包括硬件、操作系統等等。
收起列表
視頻：2-1 影響性能的幾個方面 (04:08)試看
視頻：2-2 CPU資源和可用內存大小 (10:54)
視頻：2-3 磁盤的配置和選擇 (04:44)
視頻：2-4 使用RAID增加傳統機器硬盤的性能 (11:30)
視頻：2-5 使用固態存儲SSD或PCIe卡 (08:35)
視頻：2-6 使用網絡存儲SAN和NAS (07:16)
視頻：2-7 總結：服務器硬件對性能的影響 (03:27)
視頻：2-8 操作系統對性能的影響-MySQL適合的操作系統 (03:50)
視頻：2-9 CentOS系統參數優化 (11:43)
視頻：2-10 文件系統對性能的影響 (03:29)
視頻：2-11 MySQL體系結構 (05:29)
視頻：2-12 MySQL常用存儲引擎之MyISAM (13:23)
視頻：2-13 MySQL常用存儲引擎之Innodb (10:44)
視頻：2-14 Innodb存儲引擎的特性(1) (15:24)
視頻：2-15 Innodb存儲引擎的特性(2) (08:44)
視頻：2-16 MySQL常用存儲引擎之CSV (09:19)
視頻：2-17 MySQL常用存儲引擎之Archive (06:08)
視頻：2-18 MySQL常用存儲引擎之Memory (10:40)
視頻：2-19 MySQL常用存儲引擎之Federated (11:21)
視頻：2-20 如何選擇存儲引擎 (04:33)
視頻：2-21 MySQL服務器參數介紹 (08:04)
視頻：2-22 內存配置相關參數 (09:24)
視頻：2-23 IO相關配置參數 (10:01)
視頻：2-24 安全相關配置參數 (06:13)
視頻：2-25 其它常用配置參數 (03:41)
視頻：2-26 數據庫設計對性能的影響 (04:36)
視頻：2-27 總結 (01:32)
作業：2-28 【討論題】你會如何配置公司的數據庫服務器硬件？
作業：2-29 【討論題】你認為對數據庫性能影響最大的因素是什麼
作業：2-30 【討論題】做為電商的DBA，建議開發選哪種MySQL存儲引擎
第3章 MySQL基準測試8 節 | 65分鐘
了解基準測試,MySQL基準測試工具介紹及實例演示。
收起列表
視頻：3-1 什麼是基準測試 (02:20)
視頻：3-2 如何進行基準測試 (09:00)
視頻：3-3 基準測試演示實例 (11:18)
視頻：3-4 Mysql基準測試工具之mysqlslap (13:30)
視頻：3-5 Mysql基準測試工具之sysbench (11:07)
視頻：3-6 sysbench基準測試演示實例 (17:11)
作業：3-7 【討論題】MySQL基準測試是否可以體現出業務系統的真實性能
作業：3-8 【實操題】參數不同取值對性能的影響
第4章 MySQL數據庫結構優化14 節 | 85分鐘
詳細介紹數據庫結構設計、範式和反範式設計、物理設計等等。
收起列表
視頻：4-1 數據庫結構優化介紹 (06:52)
視頻：4-2 數據庫結構設計 (14:49)
視頻：4-3 需求分析及邏輯設計 (11:00)
視頻：4-4 需求分析及邏輯設計-反範式化設計 (06:44)
視頻：4-5 範式化設計和反範式化設計優缺點 (04:06)
視頻：4-6 物理設計介紹 (05:17)
視頻：4-7 物理設計-數據類型的選擇 (18:59)
視頻：4-8 物理設計-如何存儲日期類型 (13:37)
視頻：4-9 物理設計-總結 (02:37)
圖文：4-10 說明MyISAM和Innodb存儲引擎的5點不同
作業：4-11 【討論題】判斷表結構是否符合第三範式要求?如不滿足要如何修改
作業：4-12 【實操題】請設計一個電商訂單系統的數據庫結構
作業：4-13 【討論題】以下那個字段適合作為Innodb表的主建使用
作業：4-14 【討論題】請為下表中的字段選擇合適的數據類型
第5章 MySQL高可用架構設計 試看24 節 | 249分鐘
詳細介紹二進制日誌及其對複製的影響、GTID的複製、MMM、MHA等等。
收起列表
視頻：5-1 mysql複製功能介紹 (04:58)
視頻：5-2 mysql二進制日誌 (22:05)
視頻：5-3 mysql二進制日誌格式對複製的影響 (09:37)
視頻：5-4 mysql複製工作方式 (03:08)
視頻：5-5 基於日誌點的複製 (20:06)
視頻：5-6 基於GTID的複製 (22:32)
視頻：5-7 MySQL複製拓撲 (13:58)
視頻：5-8 MySQL複製性能優化 (09:23)
視頻：5-9 MySQL複製常見問題處理 (08:31)
視頻：5-10 什麼是高可用架構 (14:09)
視頻：5-11 MMM架構介紹 (08:09)
視頻：5-12 MMM架構實例演示（上） (09:16)試看
視頻：5-13 MMM架構實例演示（下） (18:55)
視頻：5-14 MMM架構的優缺點 (08:01)
視頻：5-15 MHA架構介紹 (10:02)
視頻：5-16 MHA架構實例演示(1) (13:11)
視頻：5-17 MHA架構實例演示(2) (16:54)
視頻：5-18 MHA架構優缺點 (05:14)
視頻：5-19 讀寫分離和負載均衡介紹 (11:42)
視頻：5-20 MaxScale實例演示 (18:25)
作業：5-21 【討論題】MySQL主從複製為什麼會有延遲，延遲又是如何產生
作業：5-22 【實操題】請為某互聯網項目設計99.99%MySQL架構
作業：5-23 【討論題】如何給一個已經存在的主從複製集群新增一個從節點
作業：5-24 【討論題】給你三台數據庫服務器，你如何設計它的高可用架構
第6章 數據庫索引優化8 節 | 65分鐘
介紹BTree索引和Hash索引，詳細介紹索引的優化策略等等。
收起列表
視頻：6-1 Btree索引和Hash索引 (20:09)
視頻：6-2 安裝演示數據庫 (01:19)
視頻：6-3 索引優化策略（上） (17:33)
視頻：6-4 索引優化策略（中） (13:02)
視頻：6-5 索引優化策略（下） (12:30)
作業：6-6 【討論題】一列上建立了索引，查詢時就一定會用到這個索引嗎
作業：6-7 【討論題】在定義聯合索引時為什麼需要注意聯合索引中的順序
作業：6-8 【實操題】SQL建立索引，你會考慮那些因素
第7章 SQL查詢優化9 節 | 62分鐘
詳細介紹慢查詢日誌及示例演示,MySQL查詢優化器介紹及特定SQL的查詢優化等。
收起列表
視頻：7-1 獲取有性能問題SQL的三種方法 (05:14)
視頻：7-2 慢查詢日誌介紹 (08:57)
視頻：7-3 慢查詢日誌實例 (08:27)
視頻：7-4 實時獲取性能問題SQL (02:21)
視頻：7-5 SQL的解析預處理及生成執行計劃 (16:02)
視頻：7-6 如何確定查詢處理各個階段所消耗的時間 (09:35)
視頻：7-7 特定SQL的查詢優化 (10:34)
作業：7-8 【討論題】如何跟據需要對一個大表中的數據進行刪除或更新
作業：7-9 【討論題】如何獲取需要優化的SQL查詢
第8章 數據庫的分庫分表5 節 | 48分鐘
詳細介紹數據庫分庫分表的實現原理及演示案例等。
收起列表
視頻：8-1 數據庫分庫分表的幾種方式 (04:34)
視頻：8-2 數據庫分片前的準備 (13:53)
視頻：8-3 數據庫分片演示(上) (11:40)
視頻：8-4 數據庫分片演示(下) (17:02)
作業：8-5 【討論題】對於大表來說我們一定要進行分庫分表嗎
第9章 數據庫監控7 節 | 29分鐘
介紹數據庫可用性監控、性能監控、MySQL主從複製監控等
收起列表
視頻：9-1 數據庫監控介紹 (04:46)
視頻：9-2 數據庫可用性監控 (07:20)
視頻：9-3 數據庫性能監控 (09:39)
視頻：9-4 MySQL主從複製監控 (06:16)
作業：9-5 【討論題】QPS是否可以真實的反映出數據庫的負載情況
作業：9-6 【討論題】如何正確評估數據庫的當前負載狀況
作業：9-7 【實操題】開發一個簡單監控腳本，監控mySQL數據庫阻塞情況
mysql中哪些因素會影響到查詢性能
影響到查詢性能：
1、表存儲量，超過百萬，查詢效率會明顯降低。
2、索引類型。雖然增加索引可以增加查詢效率，可是過多，會略影響性能，而且索引字段的類型，也影響查詢性能，int性能是最好的，字符類型的索引查詢性能略差
3、表存儲類型影響性能，有innodb myisam 等類型，區別和用途百度下就會知道。
至少以上這3點。
影響數據庫性能的因素
影響數據庫性能的因素
對於數據庫愛好者們，數據庫底層的各種細節，內幕，等待事件，隱藏參數等津津樂道，對於調整好一條SQL語句使之在查詢優化器/查詢引擎下能高性能運轉具有巨大的滿足感成功感，彷彿自己掌握了天下最有價值的真理，駕馭了天下最有難度的技術。但對於設計和開發出這個數據庫系統的人來說，他們看到此情此景，只好躲在一邊偷偷的笑了。那麼問題來了，使用別人數據庫的人被稱為大師（如：OCM），那麼自己寫出一個數據庫來的人又該稱為什麼呢？到底誰才是真正的高手呢？
數據庫系統優化中的一些觀點：
“系統性能出現問題進行優化，一定要深入了解數據庫內部參數、等待事件、Latch、緩衝池、trace文件、查詢/優化引擎等底層細節。”
這種觀點往往出自數據庫“高手”，這部分人以了解數據庫底層實現細節而感到非常驕傲。但是從優化角度講數據庫的等待事件、Latch等指標高等等都只是問題的表象，懂得底層細節和內幕固然是好。但是解決問題的關鍵往往是在應用層進行優化。
“只要系統參數調整了，性能就能提高。系統優化應該調整那些參數…”
這種觀點往往出自於一些偏運維和應用層的DBA，迷戀參數配置來調優。
調整系統參數是非常重要的，但不一定能解決性能問題，否則就不會有去IOE了，問題可能性最大的還是應用設計和開發問題。
同理，很多運維人員和系統架構師比較迷戀“Linux系統調優”。認為對“文件句柄數、磁盤子系統…”那些做了優化，就能提升整個應用系統的性能。其實不然。有些場景下，針對業務特點和應用類型做操作系統調優是能取到立竿見影的效果，但是大多數時候往往提升並不明顯。所以最關鍵的還是找出瓶頸所在，對症下藥。*/
“系統性能問題需要從架構上解決，與應用開發關係不大。”
系統性能與各個層面都有關，架構很重要，但應用開發也是非常重要的一環。
影響數據庫性能的因素
1.業務需求和技術選型
2.應用系統的開發及架構
3.數據庫自身
3.1表結構的設計
3.2查詢語句
3.3索引設計
3.4Mysql服務（安裝、配置等）
3.5操作系統調優
3.6硬件升級（SSD、更強的CPU、更大的內存）
4.數據架構（讀寫分離、分庫分表等）
在很多情況下，數據庫可能是互聯網應用系統的瓶頸。但是單純從數據庫角度去做優化，可能未必能達到理想的效果。
說點題外話，最近看到很多公司使用中間件或者分布式數據訪問層來做數據庫分片，說明也許該公司業務發展很快。但另一個方面，也令人擔憂，他們的數據庫壓力真的已經到了必須切分不可的程度了嗎？分庫分表真的像科普的那麼簡單嗎？他們能搞定分庫分錶帶來的成本和問題嗎？有沒有更合適的優化方法呢？
當然是有的。其實“過度設計”和“提前優化”就是系統萬惡之源。
影響數據庫性能的主要因素有哪些？
1、1、調整數據結構的設計。這一部分在開發信息系統之前完成，程序員需要考慮是否使用ORACLE數據庫的分區功能，對於經常訪問的數據庫表是否需要建立索引等。
2、2、調整應用程序結構設計。這一部分也是在開發信息系統之前完成，程序員在這一步需要考慮應用程序使用什麼樣的體系結構，是使用傳統的Client/Server兩層體系結構，還是使用Browser/Web/Database的三層體系結構。不同的應用程序體系結構要求的數據庫資源是不同的。
3、3、調整數據庫SQL語句。應用程序的執行最終將歸結為數據庫中的SQL語句執行，因此SQL語句的執行效率最終決定了ORACLE數據庫的性能。ORACLE公司推薦使用ORACLE語句優化器（Oracle Optimizer）和行鎖管理器（row-level manager）來調整優化SQL語句。
4、4、調整服務器內存分配。內存分配是在信息系統運行過程中優化配置的，數據庫管理員可以根據數據庫運行狀況調整數據庫系統全局區（SGA區）的數據緩衝區、日誌緩衝區和共享池的大小；還可以調整程序全局區（PGA區）的大小。需要注意的是，SGA區不是越大越好，SGA區過大會佔用操作系統使用的內存而引起虛擬內存的頁面交換，這樣反而會降低系統。
5、5、調整硬盤I/O，這一步是在信息系統開發之前完成的。數據庫管理員可以將組成同一個表空間的數據文件放在不同的硬盤上，做到硬盤之間I/O負載均衡。
6、6、調整操作系統參數，例如：運行在UNIX操作系統上的ORACLE數據庫，可以調整UNIX數據緩衝池的大小，每個進程所能使用的內存大小等參數。
實際上，上述數據庫優化措施之間是相互聯繫的。ORACLE數據庫性能惡化表現基本上都是用戶響應時間比較長，需要用戶長時間的等待。但性能惡化的原因卻是多種多樣的，有時是多個因素共同造成了性能惡化的結果，這就需要數據庫管理員有比較全面的計算機知識，能夠敏感地察覺到影響數據庫性能的主要原因所在。另外，良好的數據庫管理工具對於優化數據庫性能也是很重要的。
ORACLE數據庫性能優化工具
常用的數據庫性能優化工具有：
1、1、ORACLE數據庫在線數據字典，ORACLE在線數據字典能夠反映出ORACLE動態運行情況，對於調整數據庫性能是很有幫助的。
2、2、操作系統工具，例如UNIX操作系統的vmstat，iostat等命令可以查看到系統系統級內存和硬盤I/O的使用情況，這些工具對於管理員弄清出系統瓶頸出現在什麼地方有時候很有用。
3、3、SQL語言跟蹤工具（SQL TRACE FACILITY），SQL語言跟蹤工具可以記錄SQL語句的執行情況，管理員可以使用虛擬表來調整實例，使用SQL語句跟蹤文件調整應用程序性能。SQL語言跟蹤工具將結果輸出成一個操作系統的文件，管理員可以使用TKPROF工具查看這些文件。
4、4、ORACLE Enterprise Manager（OEM），這是一個圖形的用戶管理界面，用戶可以使用它方便地進行數據庫管理而不必記住複雜的ORACLE數據庫管理的命令。
5、5、EXPLAIN PLAN——SQL語言優化命令，使用這個命令可以幫助程序員寫出高效的SQL語言。
ORACLE數據庫的系統性能評估
信息系統的類型不同，需要關注的數據庫參數也是不同的。數據庫管理員需要根據自己的信息系統的類型着重考慮不同的數據庫參數。
1、1、在線事務處理信息系統（OLTP），這種類型的信息系統一般需要有大量的Insert、Update操作，典型的系統包括民航機票發售系統、銀行儲蓄系統等。OLTP系統需要保證數據庫的並發性、可靠性和最終用戶的速度，這類系統使用的ORACLE數據庫需要主要考慮下述參數：
l l 數據庫回滾段是否足夠？
l l 是否需要建立ORACLE數據庫索引、聚集、散列？
l l 系統全局區（SGA）大小是否足夠？
l l SQL語句是否高效？
2、2、數據倉庫系統（Data Warehousing），這種信息系統的主要任務是從ORACLE的海量數據中進行查詢，得到數據之間的某些規律。數據庫管理員需要為這種類型的ORACLE數據庫着重考慮下述參數：
l l 是否採用B*-索引或者bitmap索引？
l l 是否採用並行SQL查詢以提高查詢效率？
l l 是否採用PL/SQL函數編寫存儲過程？
l l 有必要的話，需要建立並行數據庫提高數據庫的查詢效率
SQL語句的調整原則
SQL語言是一種靈活的語言，相同的功能可以使用不同的語句來實現，但是語句的執行效率是很不相同的。程序員可以使用EXPLAIN PLAN語句來比較各種實現方案，並選出最優的實現方案。總得來講，程序員寫SQL語句需要滿足考慮如下規則：
1、1、盡量使用索引。試比較下面兩條SQL語句：
語句A：SELECT dname, deptno FROM dept WHERE deptno NOT IN
(SELECT deptno FROM emp);
語句B：SELECT dname, deptno FROM dept WHERE NOT EXISTS
(SELECT deptno FROM emp WHERE dept.deptno = emp.deptno);
這兩條查詢語句實現的結果是相同的，但是執行語句A的時候，ORACLE會對整個emp表進行掃描，沒有使用建立在emp表上的deptno索引，執行語句B的時候，由於在子查詢中使用了聯合查詢，ORACLE只是對emp表進行的部分數據掃描，並利用了deptno列的索引，所以語句B的效率要比語句A的效率高一些。
2、2、選擇聯合查詢的聯合次序。考慮下面的例子：
SELECT stuff FROM taba a, tabb b, tabc c
WHERE a.acol between :alow and :ahigh
AND b.bcol between :blow and :bhigh
AND c.ccol between :clow and :chigh
AND a.key1 = b.key1
AMD a.key2 = c.key2;
這個SQL例子中，程序員首先需要選擇要查詢的主表，因為主表要進行整個表數據的掃描，所以主表應該數據量最小，所以例子中表A的acol列的範圍應該比表B和表C相應列的範圍小。
3、3、在子查詢中慎重使用IN或者NOT IN語句，使用where (NOT) exists的效果要好的多。
4、4、慎重使用視圖的聯合查詢，尤其是比較複雜的視圖之間的聯合查詢。一般對視圖的查詢最好都分解為對數據表的直接查詢效果要好一些。
5、5、可以在參數文件中設置SHARED_POOL_RESERVED_SIZE參數，這個參數在SGA共享池中保留一個連續的內存空間，連續的內存空間有益於存放大的SQL程序包。
6、6、ORACLE公司提供的DBMS_SHARED_POOL程序可以幫助程序員將某些經常使用的存儲過程“釘”在SQL區中而不被換出內存，程序員對於經常使用並且佔用內存很多的存儲過程“釘”到內存中有利於提高最終用戶的響應時間。
CPU參數的調整
CPU是服務器的一項重要資源，服務器良好的工作狀態是在工作高峰時CPU的使用率在90％以上。如果空閑時間CPU使用率就在90％以上，說明服務器缺乏CPU資源，如果工作高峰時CPU使用率仍然很低，說明服務器CPU資源還比較富餘。
使用操作相同命令可以看到CPU的使用情況，一般UNIX操作系統的服務器，可以使用sar –u命令查看CPU的使用率，NT操作系統的服務器，可以使用NT的性能管理器來查看CPU的使用率。
數據庫管理員可以通過查看v$sysstat數據字典中“CPU used by this session”統計項得知ORACLE數據庫使用的CPU時間，查看“OS User level CPU time”統計項得知操作系統用戶態下的CPU時間，查看“OS System call CPU time”統計項得知操作系統系統態下的CPU時間，操作系統總的CPU時間就是用戶態和系統態時間之和，如果ORACLE數據庫使用的CPU時間占操作系統總的CPU時間90％以上，說明服務器CPU基本上被ORACLE數據庫使用着，這是合理，反之，說明服務器CPU被其它程序佔用過多，ORACLE數據庫無法得到更多的CPU時間。
數據庫管理員還可以通過查看v$sesstat數據字典來獲得當前連接ORACLE數據庫各個會話佔用的CPU時間，從而得知什麼會話耗用服務器CPU比較多。
出現CPU資源不足的情況是很多的：SQL語句的重解析、低效率的SQL語句、鎖衝突都會引起CPU資源不足。
1、數據庫管理員可以執行下述語句來查看SQL語句的解析情況：
SELECT * FROM V$SYSSTAT
WHERE NAME IN
(‘parse time cpu’, ‘parse time elapsed’, ‘parse count (hard)’);
這裡parse time cpu是系統服務時間，parse time elapsed是響應時間，用戶等待時間
waite time = parse time elapsed – parse time cpu
由此可以得到用戶SQL語句平均解析等待時間＝waite time / parse count。這個平均等待時間應該接近於0，如果平均解析等待時間過長，數據庫管理員可以通過下述語句
SELECT SQL_TEXT, PARSE_CALLS, EXECUTIONS FROM V$SQLAREA
ORDER BY PARSE_CALLS;
來發現是什麼SQL語句解析效率比較低。程序員可以優化這些語句，或者增加ORACLE參數SESSION_CACHED_CURSORS的值。
2、數據庫管理員還可以通過下述語句：
SELECT BUFFER_GETS, EXECUTIONS, SQL_TEXT FROM V$SQLAREA;
查看低效率的SQL語句，優化這些語句也有助於提高CPU的利用率。
3、3、數據庫管理員可以通過v$system_event數據字典中的“latch free”統計項查看ORACLE數據庫的衝突情況，如果沒有衝突的話，latch free查詢出來沒有結果。如果衝突太大的話，數據庫管理員可以降低spin_count參數值，來消除高的CPU使用率。
內存參數的調整
內存參數的調整主要是指ORACLE數據庫的系統全局區（SGA）的調整。SGA主要由三部分構成：共享池、數據緩衝區、日誌緩衝區。
1、 1、 共享池由兩部分構成：共享SQL區和數據字典緩衝區，共享SQL區是存放用戶SQL命令的區域，數據字典緩衝區存放數據庫運行的動態信息。數據庫管理員通過執行下述語句：
select (sum(pins – reloads)) / sum(pins) “Lib Cache” from v$librarycache;
來查看共享SQL區的使用率。這個使用率應該在90％以上，否則需要增加共享池的大小。數據庫管理員還可以執行下述語句：
select (sum(gets – getmisses – usage – fixed)) / sum(gets) “Row Cache” from v$rowcache;
查看數據字典緩衝區的使用率，這個使用率也應該在90％以上，否則需要增加共享池的大小。
2、 2、 數據緩衝區。數據庫管理員可以通過下述語句：
SELECT name, value FROM v$sysstat WHERE name IN (‘db block gets’, ‘consistent gets’,’physical reads’);
來查看數據庫數據緩衝區的使用情況。查詢出來的結果可以計算出來數據緩衝區的使用命中率＝1 – ( physical reads / (db block gets + consistent gets) )。
這個命中率應該在90％以上，否則需要增加數據緩衝區的大小。
3、 3、 日誌緩衝區。數據庫管理員可以通過執行下述語句：
select name,value from v$sysstat where name in (‘redo entries’,’redo log space requests’);查看日誌緩衝區的使用情況。查詢出的結果可以計算出日誌緩衝區的申請失敗率：
申請失敗率＝requests/entries，申請失敗率應該接近於0，否則說明日誌緩衝區開設太小，需要增加ORACLE數據庫的日誌緩衝區。
MySQL數據庫性能優化之分區分表分庫
分表是分散數據庫壓力的好方法。
分表，最直白的意思，就是將一個表結構分為多個表，然後，可以再同一個庫里，也可以放到不同的庫。
當然，首先要知道什麼情況下，才需要分表。個人覺得單表記錄條數達到百萬到千萬級別時就要使用分表了。
分表的分類
**1、縱向分表**
將本來可以在同一個表的內容，人為劃分為多個表。（所謂的本來，是指按照關係型數據庫的第三範式要求，是應該在同一個表的。）
分表理由：根據數據的活躍度進行分離，（因為不同活躍的數據，處理方式是不同的）
案例：
對於一個博客系統，文章標題，作者，分類，創建時間等，是變化頻率慢，查詢次數多，而且最好有很好的實時性的數據，我們把它叫做冷數據。而博客的瀏覽量，回複數等，類似的統計信息，或者別的變化頻率比較高的數據，我們把它叫做活躍數據。所以，在進行數據庫結構設計的時候，就應該考慮分表，首先是縱向分表的處理。
這樣縱向分表後：
首先存儲引擎的使用不同，冷數據使用MyIsam 可以有更好的查詢數據。活躍數據，可以使用Innodb ,可以有更好的更新速度。
其次，對冷數據進行更多的從庫配置，因為更多的操作時查詢，這樣來加快查詢速度。對熱數據，可以相對有更多的主庫的橫向分表處理。
其實，對於一些特殊的活躍數據，也可以考慮使用memcache ,redis之類的緩存，等累計到一定量再去更新數據庫。或者mongodb 一類的nosql 數據庫，這裡只是舉例，就先不說這個。
**2、橫向分表**
字面意思，就可以看出來，是把大的表結構，橫向切割為同樣結構的不同表，如，用戶信息表，user_1,user_2等。表結構是完全一樣，但是，根據某些特定的規則來劃分的表，如根據用戶ID來取模劃分。
分表理由：根據數據量的規模來劃分，保證單表的容量不會太大，從而來保證單表的查詢等處理能力。
案例：同上面的例子，博客系統。當博客的量達到很大時候，就應該採取橫向分割來降低每個單表的壓力，來提升性能。例如博客的冷數據表，假如分為100個表，當同時有100萬個用戶在瀏覽時，如果是單表的話，會進行100萬次請求，而現在分表後，就可能是每個表進行1萬個數據的請求（因為，不可能絕對的平均，只是假設），這樣壓力就降低了很多很多。
延伸：為什麼要分表和分區？
日常開發中我們經常會遇到大表的情況，所謂的大表是指存儲了百萬級乃至千萬級條記錄的表。這樣的表過於龐大，導致數據庫在查詢和插入的時候耗時太長，性能低下，如果涉及聯合查詢的情況，性能會更加糟糕。分表和表分區的目的就是減少數據庫的負擔，提高數據庫的效率，通常點來講就是提高表的增刪改查效率。
什麼是分表？
分表是將一個大表按照一定的規則分解成多張具有獨立存儲空間的實體表，我們可以稱為子表，每個表都對應三個文件，MYD數據文件，.MYI索引文件，.frm表結構文件。這些子表可以分布在同一塊磁盤上，也可以在不同的機器上。app讀寫的時候根據事先定義好的規則得到對應的子表名，然後去操作它。
什麼是分區？
分區和分表相似，都是按照規則分解表。不同在於分表將大表分解為若干個獨立的實體表，而分區是將數據分段劃分在多個位置存放，可以是同一塊磁盤也可以在不同的機器。分區後，表面上還是一張表，但數據散列到多個位置了。app讀寫的時候操作的還是大表名字，db自動去組織分區的數據。
**MySQL分表和分區有什麼聯繫呢？**
1、都能提高mysql的性高，在高並髮狀態下都有一個良好的表現。
2、分表和分區不矛盾，可以相互配合的，對於那些大訪問量，並且表數據比較多的表，我們可以採取分表和分區結合的方式（如果merge這種分表方式，不能和分區配合的話，可以用其他的分表試），訪問量不大，但是表數據很多的表，我們可以採取分區的方式等。
3、分表技術是比較麻煩的，需要手動去創建子表，app服務端讀寫時候需要計算子表名。採用merge好一些，但也要創建子表和配置子表間的union關係。
4、表分區相對於分表，操作方便，不需要創建子表。
我們知道對於大型的互聯網應用，數據庫單表的數據量可能達到千萬甚至上億級別，同時面臨這高並發的壓力。Master-Slave結構只能對數據庫的讀能力進行擴展，寫操作還是集中在Master中，Master並不能無限制的掛接Slave庫，如果需要對數據庫的吞吐能力進行進一步的擴展，可以考慮採用分庫分表的策略。
**1、分表**
在分表之前，首先要選中合適的分表策略（以哪個字典為分表字段，需要將數據分為多少張表），使數據能夠均衡的分布在多張表中，並且不影響正常的查詢。在企業級應用中，往往使用org_id(組織主鍵)做為分表字段，在互聯網應用中往往是userid。在確定分表策略後，當數據進行存儲及查詢時，需要確定到哪張表裡去查找數據，
數據存放的數據表 = 分表字段的內容 % 分表數量
**2、分庫**
分表能夠解決單表數據量過大帶來的查詢效率下降的問題，但是不能給數據庫的並發訪問帶來質的提升，面對高並發的寫訪問，當Master無法承擔高並發的寫入請求時，不管如何擴展Slave服務器，都沒有意義了。我們通過對數據庫進行拆分，來提高數據庫的寫入能力，即所謂的分庫。分庫採用對關鍵字取模的方式，對數據庫進行路由。
數據存放的數據庫=分庫字段的內容%數據庫的數量
**3、即分表又分庫**
數據庫分表可以解決單表海量數據的查詢性能問題，分庫可以解決單台數據庫的並發訪問壓力問題。
當數據庫同時面臨海量數據存儲和高並發訪問的時候，需要同時採取分表和分庫策略。一般分表分庫策略如下：
中間變量 = 關鍵字%（數據庫數量*單庫數據表數量）
庫 = 取整（中間變量/單庫數據表數量）
表 = （中間變量%單庫數據表數量）
實例：
1、分庫分表
很明顯，一個主表（也就是很重要的表，例如用戶表）無限制的增長勢必嚴重影響性能，分庫與分表是一個很不錯的解決途徑，也就是性能優化途徑，現在的案例是我們有一個1000多萬條記錄的用戶表members,查詢起來非常之慢，同事的做法是將其散列到100個表中，分別從members0到members99，然後根據mid分發記錄到這些表中，牛逼的代碼大概是這樣子：
複製代碼 代碼如下:
?php
for($i=0;$i 100; $i++ ){
//echo “CREATE TABLE db2.members{$i} LIKE db1.members
“;
echo “INSERT INTO members{$i} SELECT * FROM members WHERE mid%100={$i}
“;
}
?
2、不停機修改mysql表結構
同樣還是members表，前期設計的表結構不盡合理，隨着數據庫不斷運行，其冗餘數據也是增長巨大，同事使用了下面的方法來處理：
先創建一個臨時表：
/*創建臨時表*/
CREATE TABLE members_tmp LIKE members
然後修改members_tmp的表結構為新結構，接着使用上面那個for循環來導出數據，因為1000萬的數據一次性導出是不對的，mid是主鍵，一個區間一個區間的導，基本是一次導出5萬條吧，這裡略去了
接着重命名將新表替換上去：
/*這是個頗為經典的語句哈*/
RENAME TABLE members TO members_bak,members_tmp TO members;
就是這樣，基本可以做到無損失，無需停機更新表結構，但實際上RENAME期間表是被鎖死的，所以選擇在線少的時候操作是一個技巧。經過這個操作，使得原先8G多的表，一下子變成了2G多。
原創文章，作者：GISV，如若轉載，請註明出處：https://www.506064.com/zh-hant/n/146010.html
微信掃一掃 
支付寶掃一掃 