讓天下沒有難用的資料庫 » MySQL 5.5版本注意大記憶體導致DDL變慢的問題
最近在協助使用者進行系統重構,RDS測試選型自然成為了本專案的一個重點,但是使用者在測試不同規格的時候發現大規格的例項效能居然不如小規格,4C32G規格效能比8C64G規格高出10%,其效能監控也是非常的正常,4C32G規格是8C64G規格資源消耗的一半,TPS也是相當,那問題到底出現在那裡?
CPU消耗對比:
TPS監控:
從監控上沒有看出端倪後,我們懷疑使用者的業務測試模型可能不一致,所以採取分析SQL審計日誌來分析問題,把top sql拿出來對比就可以一目瞭然問題的所在,所以重新開啟壓測,使用我們的專家分析系統來分析SQL日誌,結果讓人大吃所驚,一條truncate 語句映入眼:
可以看到truncate 語句在8C64G的規格中執行慢了30秒左右,這個時間恰好是整個測試相差的時間,為什麼規格越大反而DDL truncate越慢?這個問題其實在5.5版本存在的一個問題,可以參考在2015年雙11時候寫過的一篇文章:RDS彈性升級後效能反而下降的案例,所以解決方案只要把例項升級到5.6就可以了。在這次問題排查中使用了很重要的SQL審計日誌來發現兩個例項規格的效能差異,該功能已經整合到RDS的專家系統中,幫助使用者更好的分析使用資料庫。
相關推薦
讓天下沒有難用的資料庫 » MySQL 5.5版本注意大記憶體導致DDL變慢的問題
最近在協助使用者進行系統重構,RDS測試選型自然成為了本專案的一個重點,但是使用者在測試不同規格的時候發現大規格的例項效能居然不如小規格,4C32G規格效能比8C64G規格高出10%,其效能監控也是非常的正常,4C32G規格是8C64G規格資源消耗的一半,TPS也是相當,那問題到底出現在那裡? CP
讓天下沒有難用的資料庫 » MySQL鎖問題最佳實踐
最近一段時間處理了較多鎖的問題,包括鎖等待導致業務連線堆積或超時,死鎖導致業務失敗等,這類問題對業務可能會造成嚴重的影響,沒有處理經驗的使用者往往無從下手。下面將從整個資料庫設計,開發,運維階段介紹如何避免鎖問題的發生,提供一些最佳實踐供RDS的使用者參考。 一.設計階段:在資料庫設計階段,引擎選擇
讓天下沒有難用的資料庫 » RDS MySQL空間優化最佳實踐
在前三期介紹了RDS for MySQL引數優化,鎖問題以及延遲優化最佳實踐之後,本期將介紹儲存空間相關的最佳實踐。 儲存空間是RDS很重要的一個指標,在RDS的工單問題中,空間問題的諮詢可以排在top 5,當RDS的實際使用空間超過了購買的空間後,例項就會被鎖定了,這樣就會導致應用無法再寫入,更新
讓天下沒有難用的資料庫 » MySQL update use index merge(Using intersect) increase chances for deadlock
昨天一同事發現線上系統在併發更新的時候出現了死鎖,通過排查定位於update更新使用了兩個索引導致,死鎖資訊如下: *** (1) TRANSACTION: TRANSACTION 29285454235, ACTIVE 0.001 sec fetching rows mysql tables in
讓天下沒有難用的資料庫 » RDS MySQL引數調優最佳實踐
前言 很多時候,RDS使用者經常會問如何調優RDS MySQL的引數,為了回答這個問題,寫一篇blog來進行解釋: 哪一些引數不能修改,那一些引數可以修改; 這些提供修改的引數是不是已經是最佳設定,如何才能利用好這些引數; 哪些引數可以改 細心的使用者在購買RDS的時候都會看到,不同規格能夠提供
讓天下沒有難用的資料庫 » mysql主鍵的缺少導致備庫hang
最近線上頻繁的出現slave延時的情況,經排查發現為使用者在刪除資料的時候,由於表主鍵的主鍵的缺少,同時刪除條件沒有索引,或或者刪除的條件過濾性極差,導致slave出現hang住,嚴重的影響了生產環境的穩定性,也希望通過這篇部落格,來加深主鍵在innodb引擎中的重要性,希望使用者在使用RD
讓天下沒有難用的資料庫 » mysql的資料恢復
資料庫資料被誤刪除是經常看到的事情,資料的恢復也就自然成為了DBA很重要的一門基本功夫,比較笨拙的辦法是拉出歷史的備份到另外的一臺機器恢復出來,但是這種方法如果資料量比較大的話,往往會耗費較長的時間,以前在使用oracle的時候,提供了很多資料恢復的辦法,常用的辦法就是採用閃回flashback,或
讓天下沒有難用的資料庫 » mysql sql優化之straight_join
在oracle中可以指定的表連線的hint有很多:ordered hint 指示oracle按照from關鍵字後的表順序來進行連線;leading hint 指示查詢優化器使用指定的表作為連線的首表,即驅動表;use_nl hint指示查詢優化器使用nested loops方式連線指定表和其他行源,
讓天下沒有難用的資料庫 » MySql sql優化之order by desc/asc limit M
Order by desc/asc limit M是我在mysql sql優化中經常遇到的一種場景,其優化原理也非常的簡單,就是利用索引的有序性,優化器沿著索引的順序掃描,在掃描到符合條件的M行資料後,停止掃描;看起來非常的簡單,但是我經常看到很多效能較差的sql沒有利用這個優化規律,下面將結合一些
讓天下沒有難用的資料庫 » 淺談mysql的子查詢
mysql的子查詢的優化一直不是很友好,一直有受業界批評比較多,也是我在sql優化中遇到過最多的問題之一,你可以點選這裡 ,這裡來獲得一些資訊,mysql在處理子查詢的時候,會將子查詢改寫,通常情況下,我們希望由內到外,也就是先完成子查詢的結果,然後在用子查詢來驅動外查詢的表,完成查詢,但是恰恰相反
讓天下沒有難用的資料庫 » Mysql 中int[M]
我們在定義數字型別的資料型別的時候,往往考慮該數字型別的資料能否裝的下該欄位的最大值,如狀態位的欄位:tinyint,表的主鍵:int,或者bigint,今天在看到開發同學提交表結構設計文件中看到數值型別的欄位定義為int(255),int(20),int(2)當時一下還沒有反映過來,我們知道在my
讓天下沒有難用的資料庫 » 生產庫中遇到mysql的子查詢
使用過oracle或者其他關係資料庫的DBA或者開發人員都有這樣的經驗,在子查詢上都認為資料庫已經做過優化,能夠很好的選擇驅動表執行,然後在把該經驗移植到mysql資料庫上,但是不幸的是,mysql在子查詢的處理上有可能會讓你大失所望,在我們的生產系統上就由於碰到了這個問題: select i_i
讓天下沒有難用的資料庫 » open/close table on mysql
我們知道mysql是一個支援多執行緒的資料庫,尤其在innodb儲存引擎出現後,對mysql的事務,併發,鎖支援得到了極大提高。在高併發的訪問的應用場景中,應用端大量併發的程序發問資料庫,而資料庫中的資料表在磁碟上以資料檔案存放,在unix,linux的系統呼叫中,是依賴於檔案描述符的。不同的os對
讓天下沒有難用的資料庫 » mysql給同一個表新增多個索引的測試
分別給xc表新增ind_name和ind_status的索引: [email protected] 11:44:13>create index ind_name on xc(name); Query OK, 6815744 rows affected (1 min 43.75 sec
讓天下沒有難用的資料庫 » Mysql中對primary key一點選擇改變
在5.1.46中優化器在對primary key的選擇上做了一點改動: Performance: While looking for the shortest index for a covering index scan, the optimizer did not consider the fu
讓天下沒有難用的資料庫 » RDS MySql支援online ddl
在日常和客戶溝通的過程中發現,他們在做mysql ddl變更的時候由於MySql本身的缺陷不支援online ddl,導致他們的業務不得不hang住一會兒,表越大,時間影響越長,所以期待有更好的解決方法;有些使用者也想了一些方法,比如通過主備切換的方法,先在備庫進行ddl,然後在通過主備切換到原主庫
讓天下沒有難用的資料庫 » mysql中的Waiting for tables
接著上篇中遇到的mysql子查詢,在問題的診斷中,丹臣注意到一個較為嚴重的問題,就是我們生產庫中全部的資料庫訪問請求都處於Waiting for tables的狀態,在將大查詢kill掉後,所有的請求恢復正常;簡單的理解為大查詢阻塞了其他訪問請求,但是這個理論是不可信,如果阻塞該表的DML還可以理解
讓天下沒有難用的資料庫 » mysql explain 中key_len的計算
今天丁原問我mysql執行計劃中的key_len是怎麼計算得到的,當時還沒有注意,在高效能的那本書講到過這個值的計算,但是自己看執行計劃的時候一直都沒有太在意這個值,更不用說深討這個值的計算了: ken_len表示索引使用的位元組數,根據這個值,就可以判斷索引使用情況,特別是在組合索引的時候,判斷所
讓天下沒有難用的資料庫 » 檢視mysql實時執行sql的工具
該工具為我的同事朱旭開發的一款可以檢視mysql資料庫實時執行的sql狀況的工具,以前苦於通過show processlist/show full processlist抓取sql的同志們現在只要盯一盯螢幕就可以了,非常的方便,點選這裡進行下載,使用方法也很簡單,如下: [email pr
讓天下沒有難用的資料庫 » 一個價值“千萬”的秒殺場景引數優化
秒殺最早來自天貓雙11各種商品的促銷活動中,現在已經有很多業務場景在使用,比如搶紅包,搶票等。其特點有三高:瞬時併發高,資料一致性高,熱點更新頻度高。這樣三高的場景下往往給資料庫造成極大的壓力,大量更新資料庫中的同一行,這樣必然會產生鎖等待,導致資料庫的效能急劇下降的問題,很容易容易出現雪崩效應。筆