首先我們來說一說數據庫架構：
對於大多數數據庫架構，大家都是主從結構的，Master —–>Slave
影響數據庫性能:
1.sql查詢速度
2. 服務器硬件
3.網卡流量
4.磁盤IO
這些因素造成的影響:
1.超高的QPS和TPS
QPS：每秒鐘處理的查詢量
10ms 處理 1個sql
1s 處理 100個sql
QPS <=100
也就是我們的慢查詢
2.大量的併發和超高的CPU使用率：
風險：
大量的併發：
數據庫連接數被佔滿（MAX_CONNTECTION:100）
超高的CPU使用率：
因CPU資源耗盡出現宕機
3.磁盤IO性能突然下降：
風險：磁盤IO性能突然下降（使用更快的磁盤設備）
其它大量消耗磁盤性能的計劃任務（調整計劃任務，做好磁盤
維護）
4：網卡流量：
分險：網卡IO被沾滿（1000Mb/8≈100MB）
如何避免無法連接數據庫的情況：
1.減少從服務器的數量，因爲從服務器要在主服務器複製日誌，消耗網絡流量
2.進行分級緩存
3.避免使用“select *”進行查詢
4.分離業務網絡和服務網絡
大表帶來的問題：
什麼樣的表可以稱爲大表：
▶ 記錄行數巨大，單表超過千萬行
▶ 表數據文件巨大，表數據文件超過10G
大表的影響：
慢查詢：很難再一定時間內過濾出所需要的數據
建立索引需要很長時間
Mysql<5.5建立索引會引起鎖表
Mysql>=5.5 雖然不會鎖表但會引起主從延遲
修改表結構需要長時間鎖表
影響正常的數據操作
如何處理數據庫中的大表
▶分庫分表：把一張大表分成多個小表（要消耗大量的人力物力）
難點：
分表主鍵的選擇
分表後跨分區數據的查詢和統計
▶大表的歷史數據歸檔減少對前端業務的影響
難點：
歸檔時間點的選擇（歸檔數據：很少使用的數據）
如：訂單列表 可以歸檔一年前的數據，也可以選擇一個月前的數據
日誌：歸檔前一週的數據
如何進行歸檔操作
大事務帶來的問題：
定義：運行時間比較長，操作的數據比較多的事物
風險：
鎖定太多的數據，造成大量的阻塞和鎖超時
回滾時間所需時間比較長
執行時間長，容易造成主從延遲
如何處理大事物：
♢避免一次處理太多的數據
♢移出不必要在事務中的select操作
未完，待續……