欢迎投稿

今日深度:

查看一个正在执行的sql的执行计划(explain for connection processlist_id),

查看一个正在执行的sql的执行计划(explain for connection processlist_id),


线上往往会出现如下这种情况

一条sql很慢,但是写的太长了,没办法复制出来,但是想看他的执行计划,怎么办呢?幸好MySQL5.7提供了额外的explain方法

| 25977372 | ashe   | 111.111.1.111:41102  | ashe     | Query            |    2448 | updating                                                      | delete from ashe
     WHERE CUSTOMER_ID IN
      (
        2656596635
      ,
        26565 |

可以通过explain for connection来看这个线程的执行计划

mysql> explain for connection 25977372\G
*************************** 1. row ***************************
           id: 1
  select_type: DELETE
        table: ashe
   partitions: NULL
         type: ALL
possible_keys: NULL
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 106665797
     filtered: 100.00
        Extra: Using where
1 row in set (0.00 sec)

这个表的CUSTOMER_ID字段是有索引的,可以看到,由于条件中的in条件太多,导致MySQL走全表扫描了。

mysql> show create table ashe\G
*************************** 1. row ***************************
       Table: ashe
Create Table: CREATE TABLE `ashe` (
  `CUSTOMER_ID` bigint(18) NOT NULL AUTO_INCREMENT,
  `ACCT_ID` varchar(40) DEFAULT NULL   ,
  `NAME` varchar(255) DEFAULT NULL ,
  `STATUS` int(2) DEFAULT NULL  ,
  `SCORE` int(6) DEFAULT NULL  ,
  `COMMENTS` varchar(400) DEFAULT NULL ,
  `READONLY` int(1) DEFAULT NULL ,
  `CHECK_TIME` timestamp NULL DEFAULT NULL ,
  `CREATE_TIME` timestamp NULL DEFAULT '0000-00-00 00:00:00'  ,
  `UPDATE_TIME` timestamp NULL DEFAULT '0000-00-00 00:00:00'  ,
  `VALUE` longtext COMMENT 'JSON',
  `MODIFIER` int(8) DEFAULT NULL ,
  `GROUP_TYPE` int(1) DEFAULT NULL ,
  `CERTIFICATE_NO` varchar(128) DEFAULT NULL ,
  `PHONE` varchar(128) DEFAULT NULL ,
  `DSNAME` varchar(100) DEFAULT NULL ,
  `AUDIT_STATUS` int(1) DEFAULT '0'  ,
  PRIMARY KEY (`CUSTOMER_ID`),
  KEY `index_accout` (`ACCT_ID`) USING BTREE,
  KEY `index_cer` (`CERTIFICATE_NO`) USING BTREE,
  KEY `index_phone` (`PHONE`) USING BTREE,
  KEY `index_name` (`DSNAME`) USING BTREE,
  KEY `index_time` (`CHECK_TIME`) USING BTREE,
  KEY `index_time_score` (`CHECK_TIME`,`SCORE`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=2808276116 DEFAULT CHARSET=utf8 KEY_BLOCK_SIZE=8
1 row in set (0.00 sec)

RD也是个人才,大概看了下in中的条件,如下,为毛要写成in呢?

PROCESSLIST_INFO: delete from ashe
     WHERE CUSTOMER_ID IN
      (
        2656596635
      ,
        2656596636
      ,
        2656596637
      ,
        2656596639
      ,
        2656596640
      ,
        2656596641
      ,
        2656596642
      ,
        2656596643
      ,
        2656596644
      ,
        2656596645
      ,
        2656596646
      ,
        2656596647
      ,
        2656596649
      ,
        2656596650
      ,
        2656596651
      ,
        2656596652
      ,
        2656596653

优化

可以将in的个数降低到100以内,或者直接单条删除吧,不会很慢。
可以参照这篇 https://blog.csdn.net/sun_ashe/article/details/83378728

www.htsjk.Com true http://www.htsjk.com/teradata/37427.html NewsArticle 查看一个正在执行的sql的执行计划(explain for connection processlist_id), 线上往往会出现如下这种情况 一条sql很慢,但是写的太长了,没办法复制出来,但是想看他的执行计划,怎么办呢?...
相关文章
    暂无相关文章
评论暂时关闭