一次去o索引建錯引起的血案

故事背景:公司之前的資料庫儲存使用的都是oracle,後面為了跟上時代步伐進行了一次浩浩蕩蕩的去o過程,首當其衝的就是將oracle換成mysql,在後期幫甲方開發專案我們都統一使用mysql,由於我們的程式是一套程式適配兩個資料庫型別,這樣就出問題了，問題點是突然某一天甲方反饋使用者在高峰期操作有點慢，對於這種情況，我們一般情況就是優化資料庫建立索引，我們查詢條件主要是前端傳入時間範圍條件,但是沒有做好充分準備(資料庫在甲方沒有做監控),用建立oracle索引方式來建立mysql導致 mysql優化器走錯索引，最終在上線第二天使用者高峰期導致系統基本處於癱瘓狀態，由於資料庫在甲方不好排查,後面要求甲方技術將改表匯出我們做了一次分析才發現是因為索引失效，重新建立索引後問題解決。

後面做了一次問題過程的回顧和分析現分析如下

mysql5.8和oracle11.2 表結構一模一樣欄位60個資料量66w

場景一:建立聯合索引 aa(a_date,a_id) 時間列在前查詢語句這是當時出問題的時候的索引

題外話，mysql分析優化器使用explain查詢 explain for select * from aa;

oracle分析優化器使用sql> explain plan for select * from aa;

sql>select plan_table_output from table(dbms_xplan.display('plan_table'))

mysql查詢結果

oralce查詢結果

場景二:建立聯合索引 aa(a_id,a_date) 時間列在後查詢語句

mysql查詢結果

oracle查詢結果

結論:根據場景一二，可以證明時間字段作為聯合索引首例容易導致mysql索引優化器異常甚至不會走改索引而全表掃瞄，而oracle不會走錯索引,後面我們在查詢oracle分析之前的索引，發現很多索引都是時間列在前，當時也沒怎麼想，也直接將oralce的建索引語句直接灌到mysql，導致mysql優化器失效。你以為問題就這麼結束了嗎，no，當我們將a1索引刪除建立a2索引發現查詢還是不理想，後面定位sql發現查詢語句sql會變，也就是如果我們聯合索引(列1 列2 列3) 而列1 後端程式會根據不同的條件時而不傳時而傳，這種查詢條件應該經常遇到，我們也做了一次驗證

場景一:我們建立聯合索引a3( a_id ,serial_number,a_task_id)，但是我們查詢條件 where a_id='401500000007' and serial_number='1042503619011674112' 兩個條件根據前導列查詢原則，mysql和oracle查詢均走a3索引

mysql查詢結果

oracle查詢結果：

場景二:我們還是建立聯合索引a3( a_id ,serial_number,a_task_id)，但是我們查詢條件 where serial_number='1042503619011674112' and a_task_id='401500000007' 查詢沒有前導列兩者結果如何呢

mysql查詢結果

oracle查詢結果

結論:如果聯合索引查詢條件沒有前導列都會導致資料庫不走索引，而只要保證前導列存在不管順序如何都會走索引，後面根據優化結果如果前端確實不想傳改條件我們重新根據業務條件將開聯合索引拆分建立兩個聯合索引問題得到完美解決

總結：在oracle轉mysql的過程中不僅要改造sql語法想對應的索引優化也需要根據不同的優化器去優化,oracle和mysql底層設計有很多不同，特別是針對索引這塊，程式開發指令碼編寫以及優化都需要小心再小心

我們平時在測試環境由於資料量不夠大所以建立索引感覺問題不大，但是線上資料量大建立索引需要結合當時場景否則不小心索引建立會鎖表導致線上查詢擁堵

在優化查詢的過程中一定要結合業務程式做優化不能脫離各個業務部門,要做好分析，提前做好預演，部門之間要做好銜接

一次去o索引建錯引起的血案

記一次控制項公升級引起的血案黑色清明

記一次轉義引發的血案

一次老闆發話引起的思考

一次去o索引建錯引起的血案

記一次控制項公升級引起的血案 黑色清明

記一次 轉義引發的血案

一次老闆發話引起的思考

相關推薦

記一次控制項公升級引起的血案黑色清明

記一次轉義引發的血案