重現一條簡單SQL的優化過程

来源:https://www.cnblogs.com/greatsql/archive/2023/03/31/17275418.html
-Advertisement-
Play Games

GreatSQL社區原創內容未經授權不得隨意使用，轉載請聯繫小編並註明來源。 GreatSQL是MySQL的國產分支版本，使用上與MySQL一致。 作者： JennyYu 文章來源：GreatSQL社區投稿 背景 接到客戶訴求說一條SQL長時間運行不出結果，讓給看看怎麼回事，SQL不複雜，優化措施也 ...


  • GreatSQL社區原創內容未經授權不得隨意使用，轉載請聯繫小編並註明來源。
  • GreatSQL是MySQL的國產分支版本，使用上與MySQL一致。
  • 作者： JennyYu
  • 文章來源：GreatSQL社區投稿

背景

接到客戶訴求說一條SQL長時間運行不出結果，讓給看看怎麼回事，SQL不複雜，優化措施也不複雜，但是要想SQL達到最優狀態，也是需要經過一番考量並做出選擇的。下麵借實驗還原一下此SQL優化過程。

實驗：

資料庫環境：MySQL5.7.39

測試表結構如下：

mysql> show create table t_1\G
*************************** 1. row ***************************
       Table: t_1
Create Table: CREATE TABLE `t_1` (
  `w_id` int(11) DEFAULT NULL,
  `w_name` varchar(10) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4
1 row in set (0.00 sec)


mysql> show create table t_2\G
*************************** 1. row ***************************
       Table: t_2
Create Table: CREATE TABLE `t_2` (
  `i_id` int(11) NOT NULL,
  `i_name` varchar(24) DEFAULT NULL,
  `i_price` decimal(5,2) DEFAULT NULL,
  `i_data` varchar(50) DEFAULT NULL,
  `i_im_id` int(11) NOT NULL,
  PRIMARY KEY (`i_im_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4
1 row in set (0.00 sec)

mysql> show create table t_3\G
*************************** 1. row ***************************
       Table: t_3
Create Table: CREATE TABLE `t_3` (
  `s_w_id` int(11) NOT NULL,
  `s_i_id` int(11) NOT NULL,
  `s_quantity` int(11) DEFAULT NULL,
  `s_ytd` int(11) DEFAULT NULL,
  `s_order_cnt` int(11) DEFAULT NULL,
  `s_remote_cnt` int(11) DEFAULT NULL,
  `s_data` varchar(50) DEFAULT NULL,
  `s_dist_01` char(24) DEFAULT NULL,
  `s_dist_02` char(24) DEFAULT NULL,
  `s_dist_03` char(24) DEFAULT NULL,
  `s_dist_04` char(24) DEFAULT NULL,
  `s_dist_05` char(24) DEFAULT NULL,
  `s_dist_06` char(24) DEFAULT NULL,
  `s_dist_07` char(24) DEFAULT NULL,
  `s_dist_08` char(24) DEFAULT NULL,
  `s_dist_09` char(24) DEFAULT NULL,
  `s_dist_10` char(24) DEFAULT NULL,
  `t_2_id` int(11) DEFAULT NULL,
  `t_1_id` int(11) DEFAULT NULL,
  PRIMARY KEY (`s_w_id`,`s_i_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4
1 row in set (0.00 sec)

Create Table: CREATE TABLE `t_4` (
  `w_name` varchar(10) DEFAULT NULL,
  `s_i_id` int(11) NOT NULL,
  `s_quantity` int(11) DEFAULT NULL,
  `s_ytd` int(11) DEFAULT NULL,
  `s_order_cnt` int(11) DEFAULT NULL,
  `s_remote_cnt` int(11) DEFAULT NULL,
  `s_data` varchar(50) DEFAULT NULL,
  `t_2_id` int(11) DEFAULT NULL,
  `i_name` varchar(24) DEFAULT NULL,
  `i_price` decimal(5,2) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4

其中t_1表25條記錄，t_2表100條記錄，t_3表500萬條數據。我這裡實驗數據量少些，客戶實際業務表數據量分別是（30，150，2700萬）。t_4表為一個歷史數據歸檔表，用於插入數據。

SQL文本展示如下：

insert into t_4
SELECT
  c.w_name,
  a.s_i_id,
  a.s_quantity,
  a.s_ytd,
  a.s_order_cnt,
  a.s_remote_cnt,
  a.s_data,
  a.t_2_id,
  b.i_name,
  b.i_price
FROM
 t_3 a,
 t_2 b,
 t_1 c
WHERE
 a.t_2_id = b.i_id
and a.t_1_id = c.w_id
and a.s_ytd = 0;

查看語句中select部分的執行計劃如下圖所示：

圖片

看到這個計劃，就想對資料庫說一句："您辛苦了!"。

優化器選擇先對兩個小表c，b進行關聯，然後得到的結果集再與大表a進行關聯，因為語句中c，b兩個表沒有欄位進行直接關聯，所以這兩個表連接後的結果集是一個笛卡爾積25 *100=2500，因為大表的關聯欄位上沒有索引，所以需要對最內層的大表全表掃描2500次。

這是不是一個大工程呢？資料庫任勞任怨，你讓它乾，它就乾，只要你等得起就可以。事實上我們是沒有耐心等的。我本來還想看看資料庫到底用多久才能給出結果，等了10分鐘，實在沒有耐心繼續等下去了。

這條SQL不複雜吧，就是三張表進行關聯，但是關聯欄位上都沒有索引，都進行了全表掃描。那麼解決措施就是加索引，但是索引怎麼加就需要做出選擇了。

有同事就提出這個SQL在大表上全表掃描2500次，在大表的關聯欄位上加上索引就可以了，看到這裡，你有沒有認同這個見解呢？我想應該有很多小伙伴是認同的。

不錯，給大表加上索引就不用全表掃描了，首先大表加索引，會鎖表很長時間，這個索引在客戶的生產環境須等到變更視窗才能加，客戶等不及，其次你有考慮過這真的是最好的辦法嗎？

因為我這是實驗環境，可以隨時給大表加索引，那接下來我們就給大表加上索引試試效果。

mysql> alter table t_3 add key(t_1_id,t_2_id);
Query OK, 0 rows affected (28.35 sec)
Records: 0  Duplicates: 0  Warnings: 0

索引加好之後，執行計劃如下：

圖片

可以看出優化器並沒有選擇走索引，依然是使用BNL優化策略，進行全表掃描，為什麼不走索引呢？應該是優化器認為索引掃描的成本高於全表掃描的成本，因為這條語句最終結果要返回大表的90%以上的數據，走索引後回表代價是很高的。這一點我們是不認同優化器的，怎麼著2500次全表掃描也比每次通過索引範圍掃描的代價要高呀，好吧，既然不認同，那麼使用force index來干涉優化器決策，讓它使用索引。

執行計劃如下圖所示：

圖片

執行計劃中顯示索引用上了，那實際執行效果如何呢？

mysql> insert into t_4
    -> SELECT
    ->   c.w_name,
    ->   a.s_i_id,
    ->   a.s_quantity,
    ->   a.s_ytd,
    ->   a.s_order_cnt,
    ->   a.s_remote_cnt,
    ->   a.s_data,
    ->   a.t_2_id,
    ->   b.i_name,
    ->   b.i_price
    -> FROM
    ->  t_3 a force index(t_1_id),
    ->  t_2 b,
    ->  t_1 c
    -> WHERE
    ->  a.t_2_id = b.i_id
    -> and a.t_1_id = c.w_id
    -> and a.s_ytd = 0;
Query OK, 4800000 rows affected (4 min 43.57 sec)
Records: 4800000  Duplicates: 0  Warnings: 0

確實效率不錯，500萬數據需要4 min 43.57 sec，生產環境的2700萬數據大概需要半個小時左右。

但這是不是效率最高的辦法呢，因為最終結果集會返回大表的90%以上的數據，所以需要對大量的索引數據回表，因為回表是會產生隨機IO的，這個回表代價確實比較高，優化器預設也沒有選擇這種執行計劃。如果我們給小表的關聯欄位上加索引會是什麼效果呢？

接下來我給兩個小表的關聯欄位上加了索引。

mysql> alter table t_2 add key(i_id);
Query OK, 0 rows affected (0.05 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql> alter table t_1 add key(w_id);
Query OK, 0 rows affected (0.03 sec)
Records: 0  Duplicates: 0  Warnings: 0

我們去掉大表的force index，不幹涉優化器，讓優化器自己做決策。執行計劃如下：

圖片

上圖的執行計劃顯示，優化器選擇了對大表全表掃描，大表做驅動表，驅動兩個小表。那這樣的實際效果如何呢？

mysql> insert into t_4
    -> SELECT
    ->   c.w_name,
    ->   a.s_i_id,
    ->   a.s_quantity,
    ->   a.s_ytd,
    ->   a.s_order_cnt,
    ->   a.s_remote_cnt,
    ->   a.s_data,
    ->   a.t_2_id,
    ->   b.i_name,
    ->   b.i_price
    -> FROM
    ->  t_3 a,
    ->  t_2 b,
    ->  t_1 c
    -> WHERE
    ->  a.t_2_id = b.i_id
    -> and a.t_1_id = c.w_id
    -> and a.s_ytd = 0;
Query OK, 4800000 rows affected (1 min 59.06 sec)
Records: 4800000  Duplicates: 0  Warnings: 0

這種方式耗時1min 59.06sec ，效率提高1倍多，生產環境的大數據量，效率提升應該更明顯。果然採用大表驅動小表這種方式效率提高了，優化器的選擇是對的。

選擇這種方式的好處：

1.SQL的執行效率高一倍

2.節省空間，因為大表的索引會占用很大的磁碟空間。

3.響應及時，避免了必須等到變更視窗才能加索引的麻煩。

4.不用修改SQL語句

該如何選擇是不是很清楚了呢？

到這裡似乎優化就結束了，但是如果想要精益求精，追求極致的話，小表上的索引可以建成覆蓋索引，防止小表回表取數據。

mysql> alter table t_1 drop key w_id;
Query OK, 0 rows affected (0.02 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql> alter table t_2 drop key i_id;
Query OK, 0 rows affected (0.02 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql> alter table t_2 add key(i_id,i_name,i_price);
Query OK, 0 rows affected (0.02 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql> alter table t_1 add key(w_id,w_name);
Query OK, 0 rows affected (0.02 sec)
Records: 0  Duplicates: 0  Warnings: 0

執行效果如下：

mysql> insert into t_4
    -> SELECT
    ->   c.w_name,
    ->   a.s_i_id,
    ->   a.s_quantity,
    ->   a.s_ytd,
    ->   a.s_order_cnt,
    ->   a.s_remote_cnt,
    ->   a.s_data,
    ->   a.t_2_id,
    ->   b.i_name,
    ->   b.i_price
    -> FROM
    ->  t_3 a,
    ->  t_2 b,
    ->  t_1 c
    -> WHERE
    ->  a.t_2_id = b.i_id
    -> and a.t_1_id = c.w_id
    -> and a.s_ytd = 0;
Query OK, 4800000 rows affected (1 min 38.99 sec)
Records: 4800000  Duplicates: 0  Warnings: 0

可以看出，小表上的索引建成覆蓋索引，耗時又縮短了20秒，執行效率更高了。

至此該條SQL的優化結束。

總結

1.本條SQL的最終執行計劃是大表驅動小表，這也算是給上篇文章《NL連接一定是小表驅動大表效率高嗎》提供了一個案例。

2.優化措施可能有很多不同的選擇，要根據實際情況選擇最優的，不要草率做出決定。

3.精益求精是優化的極致，但是有時候也是需要做出折中選擇的，達到業務運行的要求是目的，這點以後遇到案例再說。

Enjoy GreatSQL

您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • linux文件許可權解讀
    Linux 文件許可權 文件許可權和文件類型共有10個字元組成，這10個字元可以分成三部分 $$ d+rwx+rwx+rw-\d:表示文件類型\2-4位（第一組rwx）：表示文件所有者的對文件的許可權\5-7位（第二組rwx）：表示文件所有者所在組的用戶對文件的許可權\8-10位（rw-）：表示其他用戶對文 ...
  • CentOS7-自動化部署web集群
    一、項目要求 1、創建role，通過role完成項目（可能需要多個role） 2、部署nginx調度器（node2主機） 3、部署2台lnmp伺服器（node3，node4主機） 4、部署mariadb資料庫（node5主機） 主要用的ansible實現自動化部署，ansible的安裝教程省略，控制 ...
  • 為什麼建議主鍵整型自增？
    昨天看到一個MySQL資料庫設計原則：強烈建議表的主鍵使用整型自增主鍵。為啥呢？ 要弄明白這個問題首先需要瞭解MySQL是如何維護數據的，你需要知道以下幾點： MySQL的InnoDB存儲引擎是在B+樹上維護表數據的 B+樹是一種平衡樹 在這棵樹上，每個節點在電腦中叫做數據頁，預設16k 樹的葉子 ...
  • Mysql之SQL語句基礎1
    一、基本概念 ——後續的內容將會記錄作者在計科學習內容 DB(資料庫)：存儲數據的倉庫，數據是有組織進行存儲 DBMS（資料庫管理系統）：操縱和管理資料庫的大型軟體 SQL：操縱關係資料庫的編程語言，是一套標準 有Mysql,Oracle,SQLSever,PostgreSQl RDBMS(關係型數 ...
  • CloudCanal 落地 DB2 數據遷移同步功能
    簡述 Db2 是一款具有悠久歷史的關係型資料庫，由 IBM 公司開發和維護，廣泛應用於金融級業務場景。 CloudCanal 近期提供了 Db2 為源端的數據遷移同步 功能，用戶可以便利地將 Db2 中數據實時同步到其他資料庫，實現數據更廣泛、更實時的應用。 功能介紹 目標資料庫和能力 | 目標端數 ...
  • 過億雲資源運維管控難？華為雲CloudMap帶你喝著咖啡做運維
    摘要：華為雲站點數字化平臺CloudMap攜手華為雲圖引擎GES打造雲服務全棧拓撲，網路流量路徑和雲服務動態依賴等空間關係數據，支撐現網運行態風險識別和分鐘級定位定界，構建業界領先的數字化能力。 本文分享自華為雲社區《構建站點數字孿生，支撐確定性運維：華為雲九洲雲圖CloudMap》，作者：HWCl ...
  • DTALK直播預約 | 數據資產管理：金融機構數據價值釋放的必經之路
    當前，數據對金融機構業務和發展的重要性日益凸顯，釋放數據生產力已經成為金融機構進行全面數字化轉型的核心，這就要求金融機構以數據資產為綱不斷提升自身數據資產管理能力。 本期DTALK我們邀請到雅拓信息解決方案專家 尹曉中，為大家帶來《數據資產管理——金融機構數據價值釋放的必經之路》。 分享大綱劇透： ...
  • FlinkSQL自定義函數開發
    本次需求場景主要為實現將flinksql中collect()函數輸出的Mutiset(VARCHAR<100>)多行結果轉換為字元串。 一、FlinkSQL自定義函數分類 Flink SQL 的自定義函數是用戶可以自行編寫的一種函數，用於擴展 Flink SQL 的功能。自定義函數可以在 SQL 查 ...
一周排行
    -Advertisement-
    Play Games
  • 移動開發（一）：使用.NET MAUI開發第一個安卓APP
    移動開發（一）：使用.NET MAUI開發第一個安卓APP 對於工作多年的C#程式員來說，近來想嘗試開發一款安卓APP，考慮了很久最終選擇使用.NET MAUI這個微軟官方的框架來嘗試體驗開發安卓APP，畢竟是使用Visual Studio開發工具，使用起來也比較的順手，結合微軟官方的教程進行了安卓 ...
  • wpf ToggleButton選中效果和一個登錄界面
    前言 QuestPDF 是一個開源 .NET 庫，用於生成 PDF 文檔。使用了C# Fluent API方式可簡化開發、減少錯誤並提高工作效率。利用它可以輕鬆生成 PDF 報告、發票、導出文件等。 項目介紹 QuestPDF 是一個革命性的開源 .NET 庫，它徹底改變了我們生成 PDF 文檔的方 ...
  • 彈幕樹洞項目功能新增篇
    項目地址 項目後端地址： https://github.com/ZyPLJ/ZYTteeHole 項目前端頁面地址： ZyPLJ/TreeHoleVue (github.com) https://github.com/ZyPLJ/TreeHoleVue 目前項目測試訪問地址： http://tree ...
  • 第27篇 sqlserver2022詳細安裝步驟
    話不多說，直接開乾 一.下載 1.官方鏈接下載： https://www.microsoft.com/zh-cn/sql-server/sql-server-downloads 2.在下載目錄中找到下麵這個小的安裝包 SQL2022-SSEI-Dev.exe，運行開始下載SQL server； 二. ...
  • .NET 開源高性能 MQTT 類庫
    前言 隨著物聯網（IoT）技術的迅猛發展，MQTT（消息隊列遙測傳輸）協議憑藉其輕量級和高效性，已成為眾多物聯網應用的首選通信標準。 MQTTnet 作為一個高性能的 .NET 開源庫，為 .NET 平臺上的 MQTT 客戶端與伺服器開發提供了強大的支持。 本文將全面介紹 MQTTnet 的核心功能 ...
  • Serilog文檔翻譯系列（六） - 可用的接收器、增強器、格式化輸出
    Serilog支持多種接收器用於日誌存儲，增強器用於添加屬性，LogContext管理動態屬性，支持多種輸出格式包括純文本、JSON及ExpressionTemplate。還提供了自定義格式化選項，適用於不同需求。 ...
  • 警惕 Visual Studio 屬性求值副作用導致邏輯不符合預期
    目錄簡介獲取 HTML 文檔解析 HTML 文檔測試參考文章 簡介 動態內容網站使用 JavaScript 腳本動態檢索和渲染數據，爬取信息時需要模擬瀏覽器行為，否則獲取到的源碼基本是空的。 本文使用的爬取步驟如下： 使用 Selenium 獲取渲染後的 HTML 文檔 使用 HtmlAgility ...
  • [使用目前最新版]HybridCLR6.9.0+YooAsset2.2.4實現純C# Unity熱更新方案 (一)
    1.前言 什麼是熱更新 游戲或者軟體更新時，無需重新下載客戶端進行安裝，而是在應用程式啟動的情況下，在內部進行資源或者代碼更新 Unity目前常用熱更新解決方案 HybridCLR，Xlua，ILRuntime等 Unity目前常用資源管理解決方案 AssetBundles，Addressable， ...
  • 在 ASP.NET Core Web API 中使用操作篩選器統一處理通用操作
    本文章主要是在C# ASP.NET Core Web API框架實現向手機發送驗證碼簡訊功能。這裡我選擇是一個互億無線簡訊驗證碼平臺，其實像阿裡雲，騰訊雲上面也可以。 首先我們先去 互億無線 https://www.ihuyi.com/api/sms.html 去註冊一個賬號 註冊完成賬號後，它會送 ...
  • 第28篇 如何.net中實現高效可靠數據同步api
    通過以下方式可以高效，並保證數據同步的可靠性 1.API設計 使用RESTful設計，確保API端點明確，並使用適當的HTTP方法（如POST用於創建，PUT用於更新）。 設計清晰的請求和響應模型，以確保客戶端能夠理解預期格式。 2.數據驗證 在伺服器端進行嚴格的數據驗證，確保接收到的數據符合預期格 ...
所有分類