背景：從兩張有關聯的表查詢資料，a表資料量1400萬，b表資料量8000萬。a與b通過id邏輯關聯，沒有實際的外來鍵。b表是後來擴充套件出來的.
問題：根據某個id查詢時超時，執行時跑不出結果。
原因：使用乙個or條件，條件裡面有乙個是a.id=b.id
簡單優化：將or條件拆開，使用union all；將之前使用表變數的部分換成了臨時表；對排序的字段加上了索引
結果：在50ms內能夠查詢出結果，這個與之前的超時簡直不能相比。
感想：感謝dba mm的幫助，讓我有了這樣的體驗，不實際的處理（哪怕很簡單的表關係）千萬級的資料量，真不知道sql語句的效能差異。
實際的體驗了使用or的效能居然能夠差到這個地步，以後盡量避免使用了。
我沒有描述清楚具體的問題，只是大致的說了下。我自己是明白了，記錄下來以備後面參考。也希望能夠給像我一樣的sql菜菜鳥有點啟發。
sql優化的實踐之路還很長，我要慢慢走。工作過程中的體驗隨時記錄下來，分享給大家。
記一次sql查詢
效果圖 要查詢出如上圖的效果 知識點.1.多表巢狀查詢.2.輸出查詢結果,group concat函式 3.關聯查詢 select t1.學校,case when t1.年級 2017 then 1年級 when t1.年級 2016 then 2年級 when t1.年級 2015 then 3年...
一次簡單SQL注入
一次簡單sql注入 id 遇見id 上去乙個單引號 報錯，回顯判斷是mysql資料庫 and 1 1正常 and 1 2 不正常 數字型注入點沒錯了，還沒有waf 開始下手 order by 判斷當前注入點有25個字段 回顯 2 和 10 用database 替換2 version 替換10 開始爆...
記錄一次查詢調優過程
調優過程中使用explain命令檢視執行過程，包括執行時間 掃瞄方式 是否用到索引等，explain 使用 timing on timing off 乙個查詢介面被頻繁呼叫，且查詢過程較慢 首先考慮優化sql語句 其次考慮優化業務 最後考慮是否需要新增快取機制 3.1 優化sql 原始sql，分組查...