2. 程式人生 > >警惕 MySql 更新 sql 的 WHERE 從句中的 IN() 子查詢時出現的效能陷阱

警惕 MySql 更新 sql 的 WHERE 從句中的 IN() 子查詢時出現的效能陷阱

阿新 • • 發佈：2019-01-02
mer_stage 表有 216423 條記錄，DDL：
CREATE TABLE `mer_stage` (
  `STAGE_ID` int(11) NOT NULL AUTO_INCREMENT,
  `MER_ID` int(11) NOT NULL,
  `MER_CODE` varchar(16) DEFAULT NULL,
  `MER_NAME` varchar(80) NOT NULL,
  `INS_CODE` varchar(16) NOT NULL,
  `INS_NAME` varchar(64) DEFAULT NULL,
  `AGENT_CODE` varchar(16) DEFAULT NULL,
  `AGENT_NAME` varchar(64) DEFAULT NULL,
  `BIG_CATEGORY_NAME` varchar(32) DEFAULT NULL,
  `SUB_CATEGORY_CODE` char(4) DEFAULT NULL,
  `SUB_CATEGORY_NAME` varchar(64) DEFAULT NULL,
  `LICENSE_CODE` varchar(64) DEFAULT NULL,
  `LICENSE_NAME` varchar(64) DEFAULT NULL,
  `SHORT_NAME` varchar(25) DEFAULT NULL,
  `MER_STATUS` tinyint(4) DEFAULT NULL,
  `PROVINCE_NAME` varchar(16) DEFAULT NULL,
  `CITY_CODE` char(4) DEFAULT NULL,
  `CITY_NAME` varchar(12) DEFAULT NULL,
  `REGISTER_ADDRESS` varchar(128) DEFAULT NULL,
  `BIZ_ADDRESS` varchar(128) DEFAULT NULL,
  `TAX_REGISTRATION` varchar(32) DEFAULT NULL,
  `INSTITUTION` varchar(16) DEFAULT NULL,
  `LEGAL_NAME` varchar(40) DEFAULT NULL,
  `LEGAL_CARD` varchar(32) DEFAULT NULL,
  `LEGAL_PHONE` varchar(16) DEFAULT NULL,
  `BIZ_SCOPE` varchar(128) DEFAULT NULL,
  `BIZ_CONTENT` varchar(64) DEFAULT NULL,
  `BIZ_TIME` varchar(32) DEFAULT NULL,
  `LICENSE_EXPIRED` varchar(16) DEFAULT NULL,
  `AVG_SINGLE_TRADE` int(11) DEFAULT NULL,
  `AVG_MONTH_TRADE` int(11) DEFAULT NULL,
  `BIZ_PLACE_OWNER` varchar(64) DEFAULT NULL,
  `REGISTERED_CAPITAL` decimal(11,0) DEFAULT NULL,
  `PAID_IN_CAPITAL` int(11) DEFAULT NULL,
  `BIZ_PERIOD` tinyint(4) DEFAULT NULL,
  `BIZ_AREA` int(11) DEFAULT NULL,
  `SETTLE_PERIOD` tinyint(4) DEFAULT NULL,
  `DELAY_TIME` varchar(50) DEFAULT NULL,
  `DELAY_TYPE` tinyint(4) DEFAULT '0',
  `BANK_CODE` varchar(40) DEFAULT NULL,
  `BRANCH_CODE` varchar(25) DEFAULT NULL,
  `BRANCH_CODE_ONE` varchar(25) DEFAULT NULL,
  `BRANCH_CODE_TWO` varchar(25) DEFAULT NULL,
  `BRANCH_NAME` varchar(128) DEFAULT NULL,
  `ACCOUNT_CODE` varchar(32) DEFAULT NULL,
  `ACCOUNT_NAME` varchar(80) DEFAULT NULL,
  `BRANCH_PROVINCE` varchar(32) DEFAULT NULL,
  `BRANCH_CITY_CODE` varchar(10) DEFAULT NULL,
  `BRANCH_CITY_NAME` varchar(50) DEFAULT NULL,
  `SETTLE_CURRENCY` varchar(16) DEFAULT NULL,
  `SETTLE_PARAM` char(1) DEFAULT NULL,
  `CUP_TYPE` tinyint(4) NOT NULL DEFAULT '1',
  `CUP_CD` varchar(6) DEFAULT NULL,
  `CUP_NM` varchar(80) DEFAULT NULL,
  `UPI_TYPE` tinyint(4) NOT NULL DEFAULT '1',
  `UPI_CD` varchar(6) DEFAULT NULL,
  `UPI_NM` varchar(80) DEFAULT NULL,
  `VISA_EDC_FEE` double DEFAULT NULL,
  `VISA_DCC_FEE` double DEFAULT NULL,
  `MASTERCARD_EDC_FEE` double DEFAULT NULL,
  `MASTERCARD_DCC_FEE` double DEFAULT NULL,
  `JCB_EDC_FEE` double DEFAULT NULL,
  `AE_EDC_FEE` double DEFAULT NULL,
  `DC_EDC_FEE` double DEFAULT NULL,
  `CONTACT_NAME` varchar(40) DEFAULT NULL,
  `CONTACT_FIXED` varchar(32) DEFAULT NULL,
  `CONTACT_MOBILE` varchar(32) DEFAULT NULL,
  `CONTACT_FAX` varchar(32) DEFAULT NULL,
  `CONTACT_EMAIL` varchar(80) DEFAULT NULL,
  `CONTACT_ADDRESS` varchar(128) DEFAULT NULL,
  `CONTACT_ZIP` varchar(8) DEFAULT NULL,
  `biz_license` text COMMENT '營業執照',
  `tax_register_cert` text COMMENT '稅務登記證',
  `ins_cert` text COMMENT '組織機構程式碼證',
  `legal_id_card` text COMMENT '法人身份證',
  `open_license` text COMMENT '開戶許可證',
  `auth_letter` text COMMENT '授權書',
  `portal_photo` text COMMENT '門頭照片',
  `cashier_photo` text COMMENT '收銀臺照片',
  `scene_photo` text COMMENT '經營場景照片',
  `mer_agreement` text COMMENT '商戶協議',
  `other_qualification` text COMMENT '其他特殊資質',
  `EXPECT_OPEN_TIME` datetime DEFAULT NULL,
  `IN_OUT_FLAG` varchar(32) DEFAULT NULL,
  `DCC_MODE` int(2) DEFAULT '0',
  `SPECIAL_FLAG` tinyint(4) DEFAULT NULL,
  `TRADING_CURRENCY` varchar(3) DEFAULT NULL,
  `STATUS` int(11) DEFAULT '0',
  `EDITABLE` tinyint(4) DEFAULT NULL,
  `MER_SINGLE_LIMIT` decimal(30,5) DEFAULT NULL,
  `MER_DAY_LIMIT` decimal(30,5) DEFAULT NULL,
  `MER_NATION` varchar(3) DEFAULT NULL,
  `ROUTE_SCHEME` varchar(13) DEFAULT NULL,
  `CREATOR_ID` int(11) DEFAULT NULL,
  `CREATOR_NAME` varchar(32) DEFAULT NULL,
  `create_time` datetime NOT NULL COMMENT '記錄建立時間',
  `modify_time` datetime NOT NULL COMMENT '最好修改時間',
  `TERM_CNT` int(11) DEFAULT NULL,
  `DATA_SRC` tinyint(4) NOT NULL DEFAULT '1',
  `CUP_CARD_PLAN` bit(1) DEFAULT NULL,
  `UPI_CARD_PLAN` bit(1) DEFAULT NULL,
  `RISK_DESC` varchar(50) DEFAULT NULL,
  `IS_FLAG` char(1) DEFAULT NULL,
  `ALP` decimal(22,3) DEFAULT NULL,
  `WXP` decimal(22,3) DEFAULT NULL,
  `dfs_edc_fee` decimal(22,3) DEFAULT NULL,
  `prp_edc_fee` decimal(22,3) DEFAULT NULL,
  `in_account_id_card` text COMMENT '入賬人身份證',
  `in_account_bank_card` text COMMENT '入賬銀行卡資訊',
  `ins_credit_card` text COMMENT '機構信用程式碼證',
  `ins_store_photo` text COMMENT '倉庫照片',
  `lease_agreement` text COMMENT '租賃協議',
  `sct` decimal(22,3) DEFAULT NULL COMMENT '掃碼支付（支付寶、微信整合）',
  `card_type` char(1) DEFAULT '1' COMMENT '法人證件型別(1:身份證,2:護照)',
  PRIMARY KEY (`STAGE_ID`),
  KEY `mer_stage_s_e_ms` (`STATUS`,`EDITABLE`,`MER_STATUS`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=216826 DEFAULT CHARSET=utf8;

proc 表有 6450 條記錄，DDL：
CREATE TABLE `proc` (
  `proc_id` int(11) NOT NULL AUTO_INCREMENT COMMENT '流程id',
  `proc_name` varchar(32) NOT NULL COMMENT '流程名稱，如 新增商戶全聚德審批流程',
  `proc_type` tinyint(4) NOT NULL COMMENT '流程型別：1－新增商戶，2-變更商戶，3-新增終端',
  `associated_id` int(11) NOT NULL COMMENT '流程關聯的商戶id或其他',
  `node_id` tinyint(4) NOT NULL COMMENT '流程進行到哪個節點',
  `associated_name` varchar(64) DEFAULT NULL COMMENT '流程關聯的商戶名稱',
  `proc_status` tinyint(4) NOT NULL DEFAULT '1' COMMENT '流程狀態：1-啟動流程，2-進行中，3-已完成',
  `starter_id` int(11) NOT NULL COMMENT '流程發起者使用者id',
  `starter_name` varchar(32) NOT NULL COMMENT '流程發起者使用者名稱',
  `node_name` varchar(64) NOT NULL COMMENT '節點名稱',
  `next_id` tinyint(4) NOT NULL COMMENT '下一節點id',
  `next_name` varchar(64) NOT NULL COMMENT '下一節點名稱',
  `create_time` datetime NOT NULL COMMENT '記錄建立時間',
  `ass_version` datetime NOT NULL COMMENT '關聯版本號',
  `node_remark` varchar(255) DEFAULT NULL COMMENT '備註',
  `modify_time` datetime DEFAULT NULL COMMENT '上一節點完成時間',
  `mer_id` int(11) NOT NULL,
  PRIMARY KEY (`proc_id`),
  KEY `proc_mer_id_index` (`mer_id`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=6451 DEFAULT CHARSET=utf8 COMMENT='流程';

關於這兩張表的一個慢查詢日誌如下：
# Time: 150703 15:13:33
# [email protected]: test[test] @ localhost [127.0.0.1]  Id:     1
# Query_time: 2.101248  Lock_time: 0.046034 Rows_sent: 0  Rows_examined: 865689
SET timestamp=1435907613;
update mer_stage set editable = 1 where stage_id in(
select associated_id from proc where proc_id in(6446 , 6447 , 6450));

日誌中可以看出該 sql 的執行時間是 2.101 s。
我們來檢視一下該 sql 的執行計劃：
我們來檢視一下該 sql 的執行計劃
注意：select_type 裡出現了 DEPENDENT SUBQUERY。
這意味著什麼？——子查詢取決於外面的查詢，MySql 先執行外查詢，內查詢根據這個查詢結果(如執行計劃裡所述，190102 rows)的每一條記錄組成新的查詢語句：
select associated_id from proc where proc_id in(6446 , 6447 , 6450) and associated_id = '外查詢結果.stage_id';

這就是個坑。我相信，每個寫出上面這種 sql 的程式設計師都不會想到 MySql 會對其這樣執行，這是大家不想看到的結果。
怎麼辦？
Uncorrelated subqueries treated as DEPENDENT by MySQL 提出了同樣的問題但是卻沒有給出解決方案。
MySql 官方給出的解決方案是：
If you have a slow 'correlated' subquery with IN, you can optimize it with a join to get around the bug described by Ryan and Stephen. After the optimization the execution time is no longer O(M×N).
於是我們的 update 語句改寫為：
update mer_stage m join proc p on m.stage_id = p.associated_id set m.editable = 1
		where p.proc_id =6446 or p.proc_id =6447 or p.proc_id =6450;
它的執行計劃是：
它的執行計劃是
執行這個 update，用時 0.047s，意料之中。搞定。
有趣的是，我們來做一個嘗試，把該 update 改為 select：
select * from mer_stage where stage_id in (select associated_id from proc where proc_id in (6446 , 6447 , 6450));

它的執行時間是 0.053 s，毫秒級。
該 sql 的執行計劃是：
update改為select後的執行計劃

同樣的寫法，唯一不同的是一個 update 另一個 select，差別咋就那麼大呢？看來優化器並不總是那麼靠譜的，它在這裡就對 update 那條 sql 的子查詢優化的很糟糕。

參考資料

相關推薦

警惕 MySql 更新 sql 的 WHERE 從句中的 IN() 子查詢時出現的效能陷阱

mer_stage 表有 216423 條記錄，DDL：CREATE TABLE `mer_stage` ( `STAGE_ID` int(11) NOT NULL AUTO_INCREMENT, `MER_ID` int(11) NOT NULL, `MER_C

Hive 不支援 where 子句中的子查詢， SQL 常用的 exist in 子句需要改寫。這一改寫相對簡單。考慮以下 SQL 查詢語句：

歡迎使用Markdown編輯器 你好！ 這是你第一次使用 Markdown編輯器 所展示的歡迎頁。如果你想學習如何使用Markdown編輯器, 可以仔細閱讀這篇文章，瞭解一下Markdown的基本語法知識。 新的改變 我們對Markdown編輯器進行了一些功能

封裝sql語句中in限制查詢個數的方法

sel rim () each tar blog and style months /* * 此方法用於每天淩晨取前一天的回滾用戶賬號 */ public function getRollBackAccount($startTime

mysql中IN，OR，BETWEEN效能比較

這裡的查詢條件有三種：between，or 和 in。這裡id列是索引列，如果不是的話，三個查詢都是全表掃描，效能差距應該不大。   1  準備環境  程式碼如下 複製程式碼 mysql> show create table tinG **********

SQL語句in中使用子查詢

SELECT ID, NAME FROM A WHERE ID IN ( ( SELECT RIGHT (ids, CHARINDEX('.', ids) - 1) FROM b WHERE ID = 1 ),

mysql更新數據，條件為實時查詢出來的數據

not 查詢 where class account nbsp reat tab sele --將更新條件保存到臨時表裏 CREATE TABLE tmp3 AS (SELECT username FROM oa_user WHERE username NOT I

對於MySQL中的子查詢的理解

每天記錄一下自己的心得體會,今天寫一下MySQL中的子查詢，個人感覺子查詢的難度比之前學的查詢都比較難，可能是語句太多吧，對於初學者的難度會有一點，反正我第一次接觸的時候是崩潰的，因為·程式碼有點多，因為內容比較多，所以小弟要是有講的不到位的，希望各位在下面給出

眼睜睜地踩到 MySQL in 子查詢的“坑”

前言 MySQL是專案中常用的資料庫，其中in查詢也是很常用。最近專案除錯過程中，遇到一個出乎意料的select查詢，竟然用了33秒！ 一、表結構 1. userinfo 表 2. article 表 二、問題SQL例項 select*fromuserinfowhereidin(selectau

sql語句中的子查詢

 一、子查詢分類： 1.獨立子查詢：子查詢語句可以獨立查詢 2.相關子查詢： 獨立子查詢：子查詢可以獨立執行。 相關子查詢： 子查詢中引用了父查詢的結果，不可以獨立執行。           所有查詢都可以用

[mysql] mysql 在update中實現子查詢的方式

mysql update中實現子查詢的方式 ---測試程式碼--------------- drop table if exists tb;create table IF NOT EXISTS tb (Name varchar(10),Time1 datetime,Time

Mysql中exists子查詢語句的使用，取出每組中最高的前n名的資訊

一、準備測試的表和資料 create table cat( id int not null auto_increment primary key, cat_id int, value int,

mysql in 子查詢 效率慢 優化（轉）

現在的CMS系統、部落格系統、BBS等都喜歡使用標籤tag作交叉連結，因此我也嚐鮮用了下。但用了後發現我想查詢某個tag的文章列表時速度很慢，達到5秒之久！百思不解(後來終於解決)，我的表結構是下面這樣的，文章只有690篇。 文章表article(id,title,content) 標籤表tag(tid,

SQL中的子查詢的使用

這篇文章講述了SQL中的子查詢，如有錯誤或者不妥之處，還請各位大佬批評指正。 什麼是子查詢？ 把一個查詢的結果在另一個查詢中使用就叫做子查詢 初始資料 有五個表：學生表，老師表，課程表，學院表，課程成績表。 表結構 初始資料 學生

MySQL IN子查詢

近日通過《mysql技術內幕：SQL程式設計》學習mysql子查詢，書中介紹了IN子查詢存在的問題，並且提供了一些優化方法。我在此書的基礎上進行了深入研究，總結幾點。 MySql優化器對IN子查詢優化時存在一個問題，MySql優化器對於IN語句的優化是“LAZY”的。對於I

【MySQL】基於MySQL的SQL優化（三）——對子查詢進行優化

通常情況下，需要把子查詢優化成JOIN查詢。 這是一個實現查詢演員名為“sandra”的表演影片片名的SQL，通過EXPLAIN關鍵字進行解析，這個查詢中包含三個子查詢，並且出現

SQL IN 子查詢返回多個值

下午遇到一個問題，IN子查詢返回多個值。 網上查了很多文件，資料，都沒收穫。 問了技術群的同僚，竟然還被嘲笑了。IN 怎麼可能匹配多個欄位呢！ 個人印象中曾經在哪裡見到過，所以就覺得不服氣。自己慢慢地去試，試出來了。 我們常用的IN 操作是這樣的: s

包含IN子查詢的SQL語句的優化

當SQL語句中包含in語句時,有時候會極大的影響效能,我們可以把in子查詢用exists子查詢或外連線替代 例子如下:    1.SQL語句中包含IN子查詢: Sql程式碼   SQL> select * from servers s     2   w

mysql not in子查詢返回結果為空

今天寫sql語句的時候，希望通過not in子查詢來限制查詢結果，實際SQL語句如下：  select  ID as id, TYPE_CODE as typeCode , TYPE_NAME as typeName , PARENT_ID as parentsId

MySQL Execution Plan--IN子查詢包含超多值引發的查詢異常1

pos cos table HERE lock code 5.1 pic key ======================================================================= SQL語句： SELECT wave_n

C#中StreamReader讀取中文時出現亂碼問題總結

utf8編碼 新的 conf window linu img utf8 enc ref 之前有一篇文章“ C#讀取及寫入配置文件教程”（http://blog.csdn.net/lisenyang/article/details/47291083）當中有一個問題就是在讀