[爬坑日誌1]寫查詢的mysql一些小注意事項

小煩發表於2020-08-18
MySql

自從做了技術負責人之後，能力的成長真的純靠摧殘啊。:joy:
也沒什麼心思來寫一些文章了，今天還有點時間稍微給大家理一理我曾經遇著過的小坑:alien:，有關 mysql 的查詢，也算是給自己整理記錄一下。（如果有哪裡說的不對的，歡迎指摘 ~）

  1. 第一個坑呢，要從 mysql 的【隱式轉換】說起：
    資料庫表結構：

【爬坑日誌】寫查詢的mysql一些小注意事項

先用字串引數直接帶入查詢：
   public function test1(){
        begin_sql();
        $a = '1855550';//字串型別
        $b = 1855550;//int 型別
        AcVideoLog::query()->where('user_id',$a)->get();
        dd_sql();
    }
輸出結果：

【爬坑日誌】寫查詢的mysql一些小注意事項

總時長：182左右ms

再用 int 引數直接帶入查詢：
   public function test2(){
        begin_sql();
        $a = '1855550';//字串型別
        $b = 1855550;//int 型別
        AcVideoLog::query()->where('user_id',$b)->get();
        dd_sql();
    }
輸出結果：

【爬坑日誌】寫查詢的mysql一些小注意事項

總時長：200左右ms

資料總量大概 23W 條資料
剛開始有個庫表查詢特別慢，才發現底下人寫了類似這個東西導致一個迴圈查詢直接超2分鐘。（庫表邏輯都是 ta 寫的）介面載入極其慢，然後我阿里雲查詢出，慢sql 提示我優化，於是我去表裡加索引。

加了索引之後，int 型別引數查詢：

【爬坑日誌】寫查詢的mysql一些小注意事項

更慢了 ~

加了索引之後，string 型別引數查詢：

【爬坑日誌】寫查詢的mysql一些小注意事項

這個索引有效果哈 快了70% ~

於是我又看了眼庫，這粗心的傢伙，使用者id 居然用的 vachar 【警告昂！關聯 ID 型別的直接 INT 好吧】,但是還有一個原因呢，就是隱式轉換。

當你查詢語句的 引數的型別 和你 庫表 資料型別 對應的時候，加了索引才會有效果。
這就是mysql 的隱式轉換，其實還有其它文章介紹的更仔細，有很多型別的隱式轉換介紹，希望大家還是可以多翻翻這些文章《mysql中的隱式轉換》www.jianshu.com/p/6f34e9708a80, 還是能獲益不少的~

其實呢，這種就是日常中的小細節，你一句底層的查詢，所帶的引數如果型別沒對上，後面的如果業務耦合的時候，需要迴圈查詢，就會導致介面變的非常非常慢，大家可以查一下自己的業務程式碼中，是不是存在這種程式碼，尤其是在寫 model 中的語句。另外建議大家在 model 中封裝查詢語句，這樣不至於全文搜哪裡出了這種細節問題，查起來真的是非常非常非常難受！

本作品採用《CC 協議》，轉載必須註明作者和本文連結

相關文章