《數據庫上云經典案例分析(35頁).pdf》由會員分享,可在線閱讀,更多相關《數據庫上云經典案例分析(35頁).pdf(35頁珍藏版)》請在三個皮匠報告上搜索。
1、玄慚阿里云技術專家數據庫上云經典案例分析自我介紹玄慚花名出自天龍八部2012年加入阿里云RDS負責RDS線上的穩定歷年RDS雙11的負責人目前負責RDS專家服務案例一:一個參數引發的“血案”案例二:上云版本升級帶來性能下降案例三:數據庫上云后性能下降緊急救援案例四:去“O”上云的護航的故事案例五:網絡延遲造成的性能下降目 錄content背景介紹1、某客戶正在將本地的業務系統遷移上云2、在RDS上運行時間明顯要比線下自建數據庫運行時間要慢 1 倍3、導致客戶系統割接延期的風險經驗分析1、數據庫跨平臺遷移(PG-MySQL、ORALCE-MySQL)2、跨版本升級(MySQL:5.1-5.5、5
2、.5-5.6)3、執行計劃,優化器,參數配置,硬件配置4、網絡延遲(跨可用區訪問,公網延遲,網卡跑滿)優化器版本OPTIMIZER_SWITCH:index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,engine_condition_pushdown=on,index_condition_pushdown=on,mrr=on,mrr_cost_based=on,block_nested_loop=on,batched_key_access=off,materializa
3、tion=on,semijoin=on,loosescan=on,firstmatch=on,subquery_materialization_cost_based=on,use_index_extensions=on用戶5.6.25,RDS的版本5.6.1.xxSQL執行計劃rows=39900*1*1*140*285*1*1*1*1*1*1*1參數配置用戶配置:join_buffer_size=128Mread_rnd_buffer_size=128Mtmp_table_size=128MRDS配置join_buffer_size=1Mread_buffer_size=1Mtmp_tabl
4、e_size=256K測試驗證tmp_table_size由256K調整至128MB 查看SQL執行計劃;查看數據庫版本和優化器規則;對比參數,硬件設置;查看網絡延遲;排查思路:保持數據庫參數配置一致最佳實踐:案例一:一個參數引發的“血案”案例二:上云版本升級帶來性能下降案例三:數據庫上云后性能下降緊急救援案例四:去“O”上云的護航的故事案例五:網絡延遲造成的性能下降目 錄content背景介紹1、某手機客戶端上云2、第一次系統切割失敗,數據庫CPU 100%3、需要在第二次割接前排除原因問題排除-跨版本升級(MySQL:5.5-5.6)用戶本地的mysql版本是5.5,而RDS的版本是5.6
5、,用戶的一條sql在本地5.5執行只需要零點幾秒,而在RDS上需要10多秒。1)5.5的優化器策略:index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,engine_condition_pushdown=on2)5.6的優化器策略:index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,engine_condition_pushdown=on,b
6、lock_nested_loop=on.optimizer_switch:block_nested_loop=onmysql explain SELECT*-FROM t1 this_ -LEFT OUTER JOIN t2 item2_ ON this_.itemId=gameitem2_.id-LEFT OUTER JOIN t3 group3_ ON gameitem2_.groupId=gamegroup3_.id.-LEFT OUTER JOIN t8 leagueitem10_ ON leagueinfo7_.itemId=leagueitem10_.id-ORDER BY thi
7、s_.id ASC LIMIT 20;+-+-+-+-+-+-+-+-+-+-+|id|select_type|table|type|possible_keys|key|key_len|ref|rows|Extra|+-+-+-+-+-+-+-+-+-+-+|1|SIMPLE|this_|ALL|NULL|NULL|NULL|NULL|257312|Using temporary;Using filesort|1|SIMPLE|item2_|eq_ref|PRIMARY|PRIMARY|4|this_.itemId|1|NULL|1|SIMPLE|group3_|ALL|PRIMARY|NUL
8、L|NULL|NULL|6|Using where;Using join buffer(Block Nested Loop)optimizer_switch:block_nested_loop=offmysql set optimizer_switch=.block_nested_loop=off.;+-+-+-+-+-+-+-+-+-+-+|id|select_type|table|type|possible_keys|key|key_len|ref|rows|Extra|+-+-+-+-+-+-+-+-+-+-+|1|SIMPLE|this_|index|NULL|PRIMARY|4|NU
9、LL|20|NULL|1|SIMPLE|item2_|eq_ref|PRIMARY|PRIMARY|4|this_.itemId|1|NULL|1|SIMPLE|group3_|eq_ref|PRIMARY|PRIMARY|4|item2_.groupId|1|NULL|問題排除 字符串存儲時間導致隱士轉換CREATE TABLE test_date(id int(11)DEFAULT NULL,gmt_create varchar(100)DEFAULT NULL,KEY ind_gmt_create(gmt_create)ENGINE=InnoDB AUTO_INCREMENT=52427
10、2;5.5版本版本mysql explain select*from test_date where gmt_create BETWEEN DATE_ADD(NOW(),INTERVAL-1 MINUTE)AND DATE_ADD(NOW(),INTERVAL 15 MINUTE);+-+-+-+-+-+-+-+-+-+-+|id|select_type|table|type|possible_keys|key|key_len|ref|rows|Extra|+-+-+-+-+-+-+-+-+-+-+|1|SIMPLE|test_date|range|ind_gmt_create|ind_gmt
11、_create|303|NULL|1|Using where|問題排除 字符串存儲時間導致隱士轉換CREATE TABLE test_date(id int(11)DEFAULT NULL,gmt_create varchar(100)DEFAULT NULL,KEY ind_gmt_create(gmt_create)ENGINE=InnoDB AUTO_INCREMENT=524272;5.6版本版本mysql explain select*from test_date where gmt_create BETWEEN DATE_ADD(NOW(),INTERVAL-1 MINUTE)AN
12、D DATE_ADD(NOW(),INTERVAL 15 MINUTE);+-+-+-+-+-+-+-+-+-+-+|id|select_type|table|type|possible_keys|key|key_len|ref|rows|Extra|+-+-+-+-+-+-+-+-+-+-+|1|SIMPLE|test_date|ALL|ind_gmt_create|NULL|NULL|NULL|2849555|Using where|+-+-+-+-+-+-+-+-+-+-+|Warning|1739|Cannot use range access on index ind_gmt_cre
13、ate due to type on field gmt_create 分析SQL執行計劃;對比數據庫版本和優化器規則排查思路:保持數據庫版本一致 功能和性能測試缺一不可最佳實踐:案例一:一個參數引發的“血案”案例二:上云版本升級帶來性能下降案例三:數據庫上云后性能下降緊急救援案例四:去“O”上云的護航的故事案例五:網絡延遲造成的性能下降目 錄content背景介紹1、某APP應用上云后數據庫CPU 100%,系統回滾會出現數據丟失2、彈性升級需要時間較長,要在白天業務高峰來臨之際消除故障問題排除規格配置較小用戶本地物理機的配置是云上RDS的規格兩倍,導致慢SQL出現堆積1本地物理機配置:2U
14、機箱,2*Intel E5-2609 v2 4核,內存:64G;磁盤ssd,Raid5;2RDS的配置:邏輯cpu8核,內存32G,最大IOPS:12000緊急救援-優化SQLmysql explain SELECT id FROM test WHERE status=30 and delStatus=0 and publicStatus=2 and audit=1 ORDER BY finishTime desc LIMIT 20id:1select_type:SIMPLEtable:test type:index_mergepossible_keys:Index_public,idx_de
15、lStatuskey:Index_public,idx_delStatuskey_len:4,4rows:30137696Extra:Using intersect(Index_public,idx_delStatus);Using where;Using filesort索引情況:PRIMARY KEY(id),KEY Index_public(publicStatus),KEY index_finishTime(finishTime),KEY idx_delStatus(delStatus),緊急救援-優化SQL1.SQL的執行計劃性能較低,走了兩個索引的intersect,需要計算大量的
16、數據rows:30137696。2.第一種解決辦法是控制優化器的策略;第二種辦法讓表走index_finishTime(finishTime).3.采取第二種辦法將idx_delStatus索引刪除,索引刪除后執行計劃恢復正常,性能急速提升:緊急救援-優化SQLmysqlexplain SELECT id FROM test WHERE status=30 and delStatus=0 and publicStatus=2 and audit=1 ORDER BY finishTime desc LIMIT 20id:1select_type:SIMPLEtable:test type:in
17、dexpossible_keys:Index_publickey:index_finishTimekey_len:8rows:40Extra:Using where;對比數據庫資源配置;分析SQL執行計劃排查思路:保持數據庫資源配置一致 功能和性能測試缺一不可最佳實踐:案例一:一個參數引發的“血案”案例二:上云版本升級帶來性能下降案例三:數據庫上云后性能下降緊急救援案例四:去“O”上云的護航的故事案例五:網絡延遲造成的性能下降目 錄content背景介紹1、某大型系統從Oracle遷移到RDS MySQL2、遷移到RDS后出現 CPU 100%,需要緊急解決原因分析-子查詢SELECT fir
18、st_nameFROM employeesWHERE emp_no IN(SELECT emp_no FROM salaries_2000 WHERE salary=5000);MySQL的處理邏輯是遍歷employees表中的每一條記錄,代入到子查詢中中去執行時間:1200S0.1S改寫子查詢SELECT first_name FROM employees emp,(SELECT emp_no FROM salaries_2000 WHERE salary=5000)salWHERE emp.emp_no=sal.emp_no;子查詢在5.1,5.5版本中都存在較大風險,將子查詢改為關聯 使用Mysql 5.6的版本,可以避免子查詢的問題最佳實踐:案例一:一個參數引發的“血案”案例二:上云版本升級帶來性能下降案例三:數據庫上云后性能下降緊急救援案例四:去“O”上云的護航的故事案例五:網絡延遲造成的性能下降目 錄content背景介紹1、某電商系統遷移上云測試過程中發現性能較低2、應用代碼,數據庫配置完全一樣原因分析-網絡延遲放大局域網、同一臺主機A機房B機房C機房 需要考慮上云后網絡延遲對性能的影響,優化應用與數據庫的訪問 應用和數據庫盡量保持在同一個可用區內訪問最佳實踐:總結配置保持一致:版本,參數,規格等考慮網絡延遲:帶寬,跨機房等