一般架構為主從資料庫伺服器搭配，例如一臺Master(主伺服器)對應著十幾臺或者上百臺Slave(從伺服器)，如果沒有高可用的主從複製元件的話，當主伺服器遇到意外情況崩潰時，很難自動進行故障切換，必須由DBA手動從眾多從伺服器中選擇資料最新的提升為主伺服器，其他從伺服器再對這個新主伺服器進行同步，這個過程又耗時間有佔用大量主伺服器的網絡卡容量． 　　資料庫伺服器的效能指標：QPS & TPS,併發量，CPU使用率 　　併發量：同一時間處理請求的數量，注意和同時連線數(一般比資料庫併發量大得多，因為有的資料庫連線處於sleep狀態，不發出請求)區分開來 　　磁碟IO:fashion IO,吞吐量比普通磁碟大很多，注意：最好不要在主庫上資料庫備份，在大型活動前取消此類操作，會損耗伺服器效能 　　影響資料庫的因素： 　　１．sql查詢速度 　　２．伺服器硬體 　　３．網絡卡流量 　　４．磁碟IO 　詳細情況如下： 超高的QPS和TPS的風險是導致效率低下的SQL(當前mysql不支援多cpu併發運算)

附： 在mysql中 TPS -（Transactions Per Second） ：資料庫的每秒傳輸的事物處理個數，主要是對事務性儲存引擎（InnoDB）的一個性能指標。 計算方法：TPS = (COM_COMMIT + COM_ROLLBACK)/UPTIME SQL語句： USE information_schema; SELECT VARIABLE_VALUE INTO @com_commit FROM GLOBAL_STATUS WHERE VARIABLE_NAME =‘COM_COMMIT’; SELECT VARIABLE_VALUE INTO @com_rollback FROM GLOBAL_STATUS WHERE VARIABLE_NAME =‘COM_ROLLBACK’; SELECT VARIABLE_VALUE INTO @uptime FROM GLOBAL_STATUS WHERE VARIABLE_NAME =‘UPTIME’; SELECT (@

[email protected]_rollback)/@uptime;

QPS -（Queries Per Second） ：資料庫的每秒查詢處理量，同時適用InnoDB和MyISAM 等儲存引擎。 計算方法：QPS=QUESTIONS/UPTIME sql語句：USE information_schema; SELECT VARIABLE_VALUE INTO @questions FROM GLOBAL_STATUS WHERE VARIABLE_NAME =‘QUESTIONS’; SELECT VARIABLE_VALUE INTO @uptime FROM GLOBAL_STATUS WHERE VARIABLE_NAME =‘UPTIME’; SELECT @questions/@uptime; 可見sql優化是十分重要的

大量的併發和超高的CPU使用率 風險： 大量的併發導致資料庫連線數被佔滿(max_connections預設為100) 超高的CPU使用率導致因CPU資源的耗盡出現宕機情況

如果磁碟IO效能突然下降，後期只能使用更快的磁碟裝置

網絡卡流量：網絡卡IO被佔滿，可以通過減少從伺服器的數量，進行分級快取，避免使用"select *"此類查詢 ，分離業務網路和伺服器網路(避免資料庫備份影響效能)來解決

大表的影響： 大表的定義(相對)：記錄行數巨大，單表超過千萬行；表資料檔案巨大，超過10G 影響：查詢慢；對DDL來說，建立索引需要很長時間，引起鎖表或者主從延遲 解決辦法：分庫分表(難點:分表主鍵的選擇;分表後跨分割槽資料的查詢和統計)；大表的歷史資料歸檔(可以減少對前後端業務的影響，難點是歸檔時間點的選擇和如何進行歸檔操作)

大事務的影響： 事務：是一組具有原子性的SQL語句，或是一個獨立的工作單元；特點：ACID 原子性(atomicity)：要麼全部提交成功，要麼全部不執行或者失敗回滾，不能只執行一部分． 一致性(consistency):將資料庫從一種一致性狀態轉換到另一種一致性狀態，在事務開始之前和事務結束之後資料庫中的資料完整性沒有被破壞． 隔離性(isolation)：一個事務對資料庫中的資料的修改，在未提交完成前對於其他事務是不可見的． 永續性(durability):一旦事務提交，其所做的修改將永久儲存到資料庫中，此時即使系統崩潰，提交的修改資料也不會丟失． 大事務：執行時間比較長，操作資料比較多的事務 風險：鎖定太多的資料，造成大量的阻塞和鎖超時；回滾所需時間比較長；執行時間長，容易造成主從延遲． 如何處理大事務： １．避免一次處理太多資料 ２．移除不必要在事務中的select操作