摘要： 常常很多用戶對比測試自建資料庫和RDS的效能差異，其測試結果往往是RDS不如ECS自建，用戶往往懷疑難道我花了那麼多的錢買的RDS難道還不如自己在ECS上搭建嗎？

效能測試：自建資料庫對比RDS中應當注意的地方

幕後

常常很多用戶對比測試自建資料庫和RDS的效能差異，其測試結果往往是RDS不如ECS自建，用戶往往懷疑難道我花了那麼多的錢買的RDS難道還不如自己在ECS上搭建？

從資料庫測試的角度來看，測試首先必須是的公平的進行，其結果才具有說服力。RDS作為一個公共的關聯式資料庫服務，其必須要包括穩定高可用，高安全，然後才是高性能。沒有前面的兩者，我相信沒有多少人願意去使用即不穩定又不安全的服務。所以RDS在穩定性上必須上主備雙節點的，雙節點甚至是在不同機房，萬一其中一個機房異常還可以快速切換到另外一個機房。其次RDS必須要許諾資料的安全，如果你寫入提交的一條資料突然不見了，如果突然有一天你的資料庫被駭客SQL注入了，你還願意繼續使用RDS嗎。作為服務廠商RDS必須為用戶考慮資料安全，在資料的存取上RDS上線了中介層，所有的要求經過中介層後如果有SQL注入的要求都會被中介層攔截掉；在底層資料寫入上RDS採用了最高安全等級的寫入，許諾在主機異常掉電的情況下資料不會出現丟失。最後在效能上，RDS源碼團隊持續對MySQL源碼優化，在標準的基準測試中效能和穩定性上都是高於社群組建的。

下面我們來總結一下RDS和自建資料庫在效能測試中需要注意的地方：

一.網路差異

1.可用區

RDS有單可用區和多可用區之分，單可用區是的資料庫主備都在同一個機房，多可用區的資料庫主備在不同機房，所以在測試RDS的程序中需要許諾ECS和RDS是在同一個可用區的。

2.網路鏈路

從ECS到RDS的網路鏈路中有多個環節，包括了ECS-->DNS-->SLB-->Proxy-->DB，所以對比ECS自建資料庫（ECS-->ECS），RDS的網路鏈路比ECS自建資料庫多出了3個鏈路環節。

3.案例剖析

•1、某電商系統遷移上雲測試程序中發現效能較低

•2、套用代碼，資料庫設定完全一樣

RDS存取鏈路：

二.設定差異

1.規格設定

RDS的規格設定主要包括了記憶體和CPU，在測試RDS的程序中，需要許諾ECS的CPU核數和RDS的CPU核數保留一致

2.參數設定

  (1).安全設定：RDS的為了許諾資料的安全性，在參數設定上採用了交易提交和binlog刷新的最高保護等級。

 a.innodb_flush_log_at_trx_commit 參數指定了 InnoDB 在交易提交後的日誌寫入頻率，當取值為 1 時，每次交易提交時，log buffer 會被寫入到記錄檔並刷新到磁碟。這也是預設值。這是最安全的設定，但由於每次交易都需要進行磁碟I/O，所以有一定的效能損耗。

 b.sync_binlog 是MySQL 的binlog日誌同步到磁碟的頻率。MySQL在binlog每寫入sync_binlog次後，刷新到磁碟，設為1 最安全，在每個語句或交易後同步一次binary log，即使在崩潰時也最多丟失一個語句或交易的日誌，但因此也最慢。

  (2).效能設定：RDS開放了除規格設定以外的參數供用戶進行設定，絕大部分的參數都已經由官方團隊優化過，使用者不需要過多調整線上的參數就可以把資料庫比較好的執行起來。但這些參數只是適合大多數的套用場景，但針對一些特殊使用者場景，需要使用者進行特殊定制。

  tmp_table_size

  作用：該參數用於決定內部記憶體暫存資料表的最大值，每個執行緒都要配置（實際起節流作用的是tmp_table_size和max_heap_table_size的最小值），如果記憶體暫存資料表超出了節流，MySQL就會自動地把它轉化為基於磁碟的MyISAM表，優化查詢語句的時候，要避免使用暫存資料表，如果實在避免不了的話，要許諾這些暫存資料表是存在記憶體中的。

  現象：如果複雜的SQL語句中包含了groupby/distinct等不能通過索引進行優化而使用了暫存資料表，則會導致SQL執行時間加長。

  建議：如果套用中有很多groupby/distinct等語句，同時資料庫有足夠的記憶體，可以增大tmp_table_size(max_heap_table_size)的值，以此來升階查詢效能。

  query_cache_size

  作用：該參數用於控制MySQLquery cache的記憶體大小；如果MySQL開啟query cache，再執行每一個query的時候會先鎖住querycache，然後判斷是否存在querycache中，如果存在直接返回結果，如果不存在，則再進行引擎查詢等動作；同時insert、update和delete這樣的動作都會將querycahce失效掉，這種失效還包括結構或者索引的任何變化，cache失效的維修代價較高，會給MySQL帶來較大的壓力，所以當我們的資料庫不是那麼頻繁的更新的時候，querycache是個好東西，但是如果反過來，寫入非常頻繁，集合聯集中在某幾張表上的時候，那麼querycache lock的鎖機制會造成很頻繁的鎖衝突，對於這一張表的寫和讀會互相等待querycache lock解鎖，導致select的查詢效率下降。

  現象：資料庫中有大量的串連狀態為checkingquery cache for query、Waitingfor query cache lock、storingresult in query cache；

  建議：RDS預設是關閉querycache功能的，如果您的實例打開了querycache，當出現上述情況後可以關閉querycache；當然有些情況也可以打開querycache，比如：巧用querycache解決資料庫效能問題。

3.案例剖析

•1、 某客戶正在將本地的商務系統遷移上雲

•2、 在rds上已耗用時間明顯要比線下自建資料庫已耗用時間要慢1倍

用戶本地參數設定：

join_buffer_size = 128M

read_rnd_buffer_size = 128M

tmp_table_size = 128M

RDS參數設定

join_buffer_size = 1M

read_buffer_size = 1M

tmp_table_size =256K

三.架構差異

1.主從複製

RDS採用了主從複製的高可用圖樣，同時打開了半同步複製，半同步複製是MySQL非同步複製的改進，當主庫在執行完用戶端提交的交易後不是立刻返回給用戶端，而是等待從庫接收並寫到relaylog中才返回給用戶端。相對於非同步複製，半同步複製提高了資料的安全性，同時它也造成了一定程度的延遲，這個延遲最少是一個TCP/IP往返的時間。所以半同步複製增加了交易的回應時間。

備忘：SQLSERVER高可用採用mirror，同樣存在上述的問題。

相關產品：

1. 雲資料庫RDS