對一個26萬數據MYSQL表的Yii2程序優化實戰之二 【開刀數據表】

上一節咱們對訂餐系統後臺歡迎頁面的統計圖表進行了處理，在本節咱們將對訂單列表和詳細訂單列表進行優化。

這節咱們將涉及到的東西以下

• 數據表加索引後的對比

下文會設計的表有order_box和order，我先放個圖，方便你們瞭解。

表關係

• order_box:訂單表，裏面會有不少子訂單order
• order:子訂單表 每一個子訂單表明選擇了一種菜品

訂單列表頁

這是個訂單列表頁，每一個訂單裏面有關聯的菜品等，咱們先看看優化前的樣子，分頁爲每頁10個。

訂單列表頁

對應action的代碼

$query = OrderBox::find()->where(['store_id'=>Yii::$app->admin->identity->store_id])->orderBy(['create_time'=>SORT_DESC]);

// 這裏有一些搜索項，對應的數據表字段有（serial_number、bank_number、pay_type）

$dataProvider = new ActiveDataProvider([
    'query' => $query,
    'pagination' => ['pagesize' => 10]
]);複製代碼

多麼簡單的邏輯，那先看一看yii2-debug給咱們的結果。

好慢

從頁面分析緣由可能出如今兩個方面

• 數據表沒有索引
• 視圖層過多的關聯致使

既然本章叫作開刀數據表，那咱們先給數據表加下索引，先不考慮搜索的狀況，我對order_box的store_id和create_time加下索引。

結果未達到預期

彷佛不是主要問題

爲order_box增長索引後並無減小多少時間。這是爲何那？

從新審視

還記得上一篇（傳送門）咱們的order_box有8萬多數據，而order有26萬多數據，再看咱們的訂單頁面。

每一個order_box都1對N了不少個order表數據，而order表有26w數據，若是這個關聯字段沒有索引，就可能致使慢。

果真

果真，如今的order表索引空空如也，咱們先爲其關聯order_box的字段box_id加上索引。

加上它

看看yii2-debug的反饋

哇哦

很高興咱們找到了這個頁面的詬病所在，經過對order的box_id加索引將數據庫執行時間降到了76毫秒，而以前是3000多毫秒，事實上對於這種數量級的數據，經過數據庫索引的添加能夠解決大部分性能問題。

可是這還沒完事，由於我想盡可能減小數據庫的檢索次數，一點一點來吧，我要先解決訂單列表頁搜索的優化。

搜索

固然我也知道，「索引」是把雙刃劍，帶來速遞提高同會帶來損耗，因此這要辯證的看，接下來就會遇到。

當我來測試針對 訂單ID、序號、銀行號碼的時候，是否加索引並無帶來太大影響（起碼當前是這樣），可是當我對支付方式增長索引的時候，運行時間居然變慢了一倍。

固然爲何慢了這裏將不進行講解，之後會有專門講MYSQL高性能索引的文章。

咱們只須要記住，對於添加索引，必定要測試，有可能它帶來反作用，切記切記。

減小查詢次數???

上面說到我想減小數據庫查詢次數，使用yii2-debug我看到這個頁面sql語句的增長來源於Yii2的AR關聯行爲致使。

緣由

在這裏我並不打算對其進行所謂的優化，具體緣由能夠看 北哥工兵連 引的一篇文章《Web應用的緩存設計模式》，若是有一天它真的影響了，咱們能夠在關聯層加一個緩存來解決。

所以雖然60屢次看着挺礙眼，可是我決定不作出來，它的存在並無帶來性能過多損耗而且大幅度簡化了邏輯。

那麼這個頁面就這樣，咱們再總結一下

• 加索引，加索引，對比着加索引
• 對於AR關聯若是性能影響不大，暫時忽略。

這個頁面比較簡單，就是一個表的檢索加一些AR關聯，接下來我要處理訂單詳情頁面，這個頁面是order表的列表。

咱們先看下頁面和yii2-debug的反饋。

更簡單

連個關聯都沒有，就是order表的分頁，看看結果。

個人天呀

到底問題出在哪裏？？？

原來是這樣

就是他們致使的，子查詢、sum、group by等等，知道了緣由，那就想辦法解決吧，好，等待阿北下一篇

對一個26萬數據MYSQL表的Yii2程序優化實戰之三 【數據表再優化】，給你們講講針對子查詢、group by以及關聯的優化行爲。

（完）

本文原創發佈於微信公衆號 北哥小報 , 嚴謹的原創技術文，Q羣：171277552。

微信掃碼能夠關注