6中哪些定位DDL被堵塞的标题,7中怎样稳定DDL被打

在上一篇小说《MySQL 5.7中怎么着定位DDL被封堵的题目》中,对于DDL被封堵难题的定点,大家重视是基于MySQL 5.7新引进的performance_schema.metadata_locks表。建议的一定方法,颇负种"猛虎添翼"的表示,而且,也只适用于MySQL 5.7从头的版本。

在上篇文章《MySQL表结构改造,不可不知的Metadata Lock》中,我们介绍了MDL引进的背景,及基本概念,从“道”的范畴知道了怎么样是MDL。上边就从“术”的规模看看哪些定位MDL的连带难题。

一、难题呈报

但在事实上生产中,MySQL 5.6依旧占不用相当多。即使MySQL 8.0皆已经GA了,但鉴于数据库的特殊性,在对照晋级的这些事情上,特别一些人要么秉持着一种“不主动”的情态。

在MySQL 5.7中,针对MDL,引进了一张新表performance_schema.metadata_locks,该表可对外体现MDL的连锁音信,包含其功能对象,类型及具备等待状态。

大家平时会遇上这么的意况,有个别事务实施完了未提交,后续再来一个DDL和DML操作,导致前面包车型客车session要么处于waiting for metadata lock,要么是锁等待超时。那时大家一再只好找到这些未提交的事体的政工id和session id,可是日常都地处sleep状态,不佳分析事情内容到底是怎样,所以日常都以野蛮地kill那么些session后化解难点,可是应用层的研发职员一再找不到到底是哪个事务引起的,前面再冒出难题时还要再度kill。那这么些意况下,怎么办呢?

既然MySQL 5.6用者众多,有未有一种格局,来消除MySQL 5.6的这一个痛点呢?

 

上面小编先进轨范拟三种情状

 

开启MDL的instrument

图片 1

抑或此前的测量检验Demo

然则相关instrument并未展开(MySQL 8.0是暗中同意开启的),其可经过如下二种艺术张开,

这里作者特意在开启session后实行一条update,又进行了一条insert语句。

会话1敞开了工作并执行了多个操作,但未提交,此时,会话2实践了alter table操作,被堵塞。

有时生效

图片 2

session1> begin;
Query OK, 0 rows affected (0.00 sec)

session1> delete from slowtech.t1 where id=2;
Query OK, 1 row affected (0.00 sec)

session1> select * from slowtech.t1;
 ------ ------ 
| id   | name |
 ------ ------ 
|    1 | a    |
 ------ ------ 
row in set (0.00 sec)

session1> update slowtech.t1 set name='c' where id=1;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

session2> alter table slowtech.t1 add c1 int; ##被阻塞

session3> show processlist;
 ---- ------ ----------- ------ --------- ------ --------------------------------- ------------------------------------ 
| Id | User | Host      | db   | Command | Time | State                           | Info                               |
 ---- ------ ----------- ------ --------- ------ --------------------------------- ------------------------------------ 
|  2 | root | localhost | NULL | Sleep   |   51 |                                 | NULL                               |
|  3 | root | localhost | NULL | Query   |    0 | starting                        | show processlist                   |
|  4 | root | localhost | NULL | Query   |    9 | Waiting for table metadata lock | alter table slowtech.t1 add c1 int |
 ---- ------ ----------- ------ --------- ------ --------------------------------- ------------------------------------ 
rows in set (0.00 sec)

修改performance_schema.setup_instrume nts表,但实例重启后,又会过来为暗许值。

那时session2一贯不通

 

UPDATE performance_schema.setup_instruments SET ENABLED = 'YES', TIMED = 'YES'
WHERE NAME = 'wait/lock/metadata/sql/mdl';

大家再开多个窗口session3。

6中哪些定位DDL被堵塞的标题,7中怎样稳定DDL被打断的难点。实际,导致DDL阻塞的操作,无非两类: 

 

mysql> show processlist;

  1. 慢查询  

  2. 表上有事务未提交

千古生效

---- ------ ----------- ------ --------- ------ --------------------------------- ----------------------------------------------------

其间,第一类相比较好定点,通过show processlist即能发掘。而第二类基本无法定位,因为未提交业务的连年在show processlist中的输出同空闲连接相同。

在布置文件中装置

| Id | User | Host      | db  | Command | Time | State                          | Info                                              |

如上边Id为2的连日,尽管Command显示为“Sleep”,其实是业务未提交。

[mysqld]
performance-schema-instrument='wait/lock/metadata/sql/mdl=ON'

---- ------ ----------- ------ --------- ------ --------------------------------- ----------------------------------------------------

mysql> show processlist;
 ---- ------ ----------- ------ --------- ------ --------------------------------- ------------------------------------ 
| Id | User | Host      | db   | Command | Time | State                           | Info                               |
 ---- ------ ----------- ------ --------- ------ --------------------------------- ------------------------------------ 
|  2 | root | localhost | NULL | Sleep   |   77 |                                 | NULL                               |
|  3 | root | localhost | NULL | Query   |    0 | starting                        | show processlist                   |
|  4 | root | localhost | NULL | Query   |   44 | Waiting for table metadata lock | alter table slowtech.t1 add c1 int |
 ---- ------ ----------- ------ --------- ------ --------------------------------- ------------------------------------ 
3 rows in set (0.00 sec)

 

|  4 | root | localhost | test | Sleep  |  841 |                                | NULL                                              |

 

测量检验场景

上边结合一个粗略的德姆o,来探视在MySQL 5.7中怎么着牢固DDL操作的梗塞难点。

session1> begin;
Query OK, 0 rows affected (0.00 sec)

session1> delete from slowtech.t1 where id=2;
Query OK, 1 row affected (0.00 sec)

session1> select * from slowtech.t1;
 ------ ------ 
| id   | name |
 ------ ------ 
|    1 | a    |
 ------ ------ 
1 row in set (0.00 sec)

session1> update slowtech.t1 set name='c' where id=1;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

session2> alter table slowtech.t1 add c1 int; ##被阻塞

session3> show processlist;
 ---- ------ ----------- ------ --------- ------ --------------------------------- ------------------------------------ 
| Id | User | Host      | db   | Command | Time | State                           | Info                               |
 ---- ------ ----------- ------ --------- ------ --------------------------------- ------------------------------------ 
|  2 | root | localhost | NULL | Sleep   |   51 |                                 | NULL                               |
|  3 | root | localhost | NULL | Query   |    0 | starting                        | show processlist                   |
|  4 | root | localhost | NULL | Query   |    9 | Waiting for table metadata lock | alter table slowtech.t1 add c1 int |
 ---- ------ ----------- ------ --------- ------ --------------------------------- ------------------------------------ 
3 rows in set (0.00 sec)

session3> select object_type,object_schema,object_name,lock_type,lock_duration,lock_status,owner_thread_id from performance_schema.metadata_locks;
 ------------- -------------------- ---------------- --------------------- --------------- ------------- ----------------- 
| object_type | object_schema      | object_name    | lock_type           | lock_duration | lock_status | owner_thread_id |
 ------------- -------------------- ---------------- --------------------- --------------- ------------- ----------------- 
| TABLE       | slowtech           | t1             | SHARED_WRITE        | TRANSACTION   | GRANTED     |              27 |
| GLOBAL      | NULL               | NULL           | INTENTION_EXCLUSIVE | STATEMENT     | GRANTED     |              29 |
| SCHEMA      | slowtech           | NULL           | INTENTION_EXCLUSIVE | TRANSACTION   | GRANTED     |              29 |
| TABLE       | slowtech           | t1             | SHARED_UPGRADABLE   | TRANSACTION   | GRANTED     |              29 |
| TABLE       | slowtech           | t1             | EXCLUSIVE           | TRANSACTION   | PENDING     |              29 |
| TABLE       | performance_schema | metadata_locks | SHARED_READ         | TRANSACTION   | GRANTED     |              28 |
 ------------- -------------------- ---------------- --------------------- --------------- ------------- ----------------- 
6 rows in set (0.00 sec)

此处,珍视关心lock_status,"PENDING"代表线程在等候MDL,而"GRANTED"则象征线程持有MDL。

 

什么寻觅引起短路的对话

结合owner_thread_id,可以可到,是29号线程在伺机27号线程的MDL,此时,可kill掉52号线程。

但须要留意的是,owner_thread_id给出的只是线程ID,实际不是show processlist中的ID。固然要物色线程对应的processlist id,需询问performance_schema.threads表。

session3> select * from performance_schema.threads where thread_id in (27,29)G
*************************** 1. row ***************************
          THREAD_ID: 27
               NAME: thread/sql/one_connection
               TYPE: FOREGROUND
     PROCESSLIST_ID: 2
   PROCESSLIST_USER: root
   PROCESSLIST_HOST: localhost
     PROCESSLIST_DB: NULL
PROCESSLIST_COMMAND: Sleep
   PROCESSLIST_TIME: 214
  PROCESSLIST_STATE: NULL
   PROCESSLIST_INFO: NULL
   PARENT_THREAD_ID: 1
               ROLE: NULL
       INSTRUMENTED: YES
            HISTORY: YES
    CONNECTION_TYPE: Socket
       THREAD_OS_ID: 9800
*************************** 2. row ***************************
          THREAD_ID: 29
               NAME: thread/sql/one_connection
               TYPE: FOREGROUND
     PROCESSLIST_ID: 4
   PROCESSLIST_USER: root
   PROCESSLIST_HOST: localhost
     PROCESSLIST_DB: NULL
PROCESSLIST_COMMAND: Query
   PROCESSLIST_TIME: 172
  PROCESSLIST_STATE: Waiting for table metadata lock
   PROCESSLIST_INFO: alter table slowtech.t1 add c1 int
   PARENT_THREAD_ID: 1
               ROLE: NULL
       INSTRUMENTED: YES
            HISTORY: YES
    CONNECTION_TYPE: Socket
       THREAD_OS_ID: 9907
2 rows in set (0.00 sec)

将这两张表组成,借鉴sys.innodb_lock _waits的出口,实际上大家也足以直观地呈现MDL的等候关系。

SELECT
    a.OBJECT_SCHEMA AS locked_schema,
    a.OBJECT_NAME AS locked_table,
    "Metadata Lock" AS locked_type,
    c.PROCESSLIST_ID AS waiting_processlist_id,
    c.PROCESSLIST_TIME AS waiting_age,
    c.PROCESSLIST_INFO AS waiting_query,
    c.PROCESSLIST_STATE AS waiting_state,
    d.PROCESSLIST_ID AS blocking_processlist_id,
    d.PROCESSLIST_TIME AS blocking_age,
    d.PROCESSLIST_INFO AS blocking_query,
    concat('KILL ', d.PROCESSLIST_ID) AS sql_kill_blocking_connection
FROM
    performance_schema.metadata_locks a
JOIN performance_schema.metadata_locks b ON a.OBJECT_SCHEMA = b.OBJECT_SCHEMA
AND a.OBJECT_NAME = b.OBJECT_NAME
AND a.lock_status = 'PENDING'
AND b.lock_status = 'GRANTED'
AND a.OWNER_THREAD_ID <> b.OWNER_THREAD_ID
AND a.lock_type = 'EXCLUSIVE'
JOIN performance_schema.threads c ON a.OWNER_THREAD_ID = c.THREAD_ID
JOIN performance_schema.threads d ON b.OWNER_THREAD_ID = d.THREAD_IDG

*************************** 1. row ***************************
               locked_schema: slowtech
                locked_table: t1
                 locked_type: Metadata Lock
      waiting_processlist_id: 4
                 waiting_age: 259
               waiting_query: alter table slowtech.t1 add c1 int
               waiting_state: Waiting for table metadata lock
     blocking_processlist_id: 2
                blocking_age: 301
              blocking_query: NULL
sql_kill_blocking_connection: KILL 2
1 row in set (0.00 sec)

输出可想而知,DDL操作假如要博得MDL,施行kill 2就可以。

 

|  5 | root | localhost | test | Query  |  709 | Waiting for table metadata lock | alter table test_lock add column name2 varchar(50) |

之所以,网络有kill空闲(Command为Sleep)连接的说法,其实也客观,但这样做就太简单狂暴了,难免会误杀。

官方的sys.schematablelock_waits

其实,MySQL 5.7在sys库中也合併了近乎功效,一样的情景,其出口如下,

mysql> select * from sys.schema_table_lock_waitsG
*************************** 1. row ***************************
               object_schema: slowtech
                 object_name: t1
           waiting_thread_id: 29
                 waiting_pid: 4
             waiting_account: root@localhost
           waiting_lock_type: EXCLUSIVE
       waiting_lock_duration: TRANSACTION
               waiting_query: alter table slowtech.t1 add c1 int
          waiting_query_secs: 446
 waiting_query_rows_affected: 0
 waiting_query_rows_examined: 0
          blocking_thread_id: 27
                blocking_pid: 2
            blocking_account: root@localhost
          blocking_lock_type: SHARED_READ
      blocking_lock_duration: TRANSACTION
     sql_kill_blocking_query: KILL QUERY 2
sql_kill_blocking_connection: KILL 2
*************************** 2. row ***************************
               object_schema: slowtech
                 object_name: t1
           waiting_thread_id: 29
                 waiting_pid: 4
             waiting_account: root@localhost
           waiting_lock_type: EXCLUSIVE
       waiting_lock_duration: TRANSACTION
               waiting_query: alter table slowtech.t1 add c1 int
          waiting_query_secs: 446
 waiting_query_rows_affected: 0
 waiting_query_rows_examined: 0
          blocking_thread_id: 29
                blocking_pid: 4
            blocking_account: root@localhost
          blocking_lock_type: SHARED_UPGRADABLE
      blocking_lock_duration: TRANSACTION
     sql_kill_blocking_query: KILL QUERY 4
sql_kill_blocking_connection: KILL 4
2 rows in set (0.00 sec)

具体分析下官方的输出,

只有二个alter table操作,却产生了两条记下,何况两条记下的kill对象竟是还不雷同,对表结构不熟识及不留心看记录内容的话,难免会kill错对象。

不仅仅如此,借使有N个查询被DDL操作堵塞,则会发生N*2条记下。在堵塞操作相当多的事态下,那N*2条记下完全部都以个噪音。

而以前的SQL,无论有多少操作被堵塞,一个alter table操作,就只会输出一条记下。

 

|  6 | root | localhost | NULL | Query  |    0 | starting                        | show processlist                                  |

实际,既然是专门的学问,在information_schema. innodb_trx中一定会有记录,如会话第11中学的事务,在表中的笔录如下,

如何查看阻塞会话已经实行过的操作

但下边那些SQL也是有缺憾,其blocking_query为NULL,而在对话1中,其刚毅一度实行了四个SQL。

这个与performance_schema.threads(类似于show processlist)有关,其只会输出当前正值运营的SQL,对于曾经施行过的,实际上是不能够来看。

但在线上,kill是三个亟待诚惶诚惧的操作,究竟你很难驾驭kill的是或不是事情主要操作?又只怕,是个批量update操作?那么,有未有艺术抓到该事情此前的操作呢?

答案,有。

即Performance Schema中著录Statement Event(操作事件)的表,具体富含events_statements_current,events_statements_history,events_statements_history_long,prepared_statements_instances。

常用的是后面多少个。

图片 3

三者的表结构完全一致,此中,events_statements_history又带有了events_statements_current的操作,所以大家这里会选择events_statements_history。

终极SQL如下,

SELECT
    locked_schema,
    locked_table,
    locked_type,
    waiting_processlist_id,
    waiting_age,
    waiting_query,
    waiting_state,
    blocking_processlist_id,
    blocking_age,
    substring_index(sql_text,"transaction_begin;" ,-1) AS blocking_query,
    sql_kill_blocking_connection
FROM
    (
        SELECT
            b.OWNER_THREAD_ID AS granted_thread_id,
            a.OBJECT_SCHEMA AS locked_schema,
            a.OBJECT_NAME AS locked_table,
            "Metadata Lock" AS locked_type,
            c.PROCESSLIST_ID AS waiting_processlist_id,
            c.PROCESSLIST_TIME AS waiting_age,
            c.PROCESSLIST_INFO AS waiting_query,
            c.PROCESSLIST_STATE AS waiting_state,
            d.PROCESSLIST_ID AS blocking_processlist_id,
            d.PROCESSLIST_TIME AS blocking_age,
            d.PROCESSLIST_INFO AS blocking_query,
            concat('KILL ', d.PROCESSLIST_ID) AS sql_kill_blocking_connection
        FROM
            performance_schema.metadata_locks a
        JOIN performance_schema.metadata_locks b ON a.OBJECT_SCHEMA = b.OBJECT_SCHEMA
        AND a.OBJECT_NAME = b.OBJECT_NAME
        AND a.lock_status = 'PENDING'
        AND b.lock_status = 'GRANTED'
        AND a.OWNER_THREAD_ID <> b.OWNER_THREAD_ID
        AND a.lock_type = 'EXCLUSIVE'
        JOIN performance_schema.threads c ON a.OWNER_THREAD_ID = c.THREAD_ID
        JOIN performance_schema.threads d ON b.OWNER_THREAD_ID = d.THREAD_ID
    ) t1,
    (
        SELECT
            thread_id,
            group_concat(   CASE WHEN EVENT_NAME = 'statement/sql/begin' THEN "transaction_begin" ELSE sql_text END ORDER BY event_id SEPARATOR ";" ) AS sql_text
        FROM
            performance_schema.events_statements_history
        GROUP BY thread_id
    ) t2
WHERE
    t1.granted_thread_id = t2.thread_id G

*************************** 1. row ***************************
               locked_schema: slowtech
                locked_table: t1
                 locked_type: Metadata Lock
      waiting_processlist_id: 4
                 waiting_age: 294
               waiting_query: alter table slowtech.t1 add c1 int
               waiting_state: Waiting for table metadata lock
     blocking_processlist_id: 2
                blocking_age: 336
              blocking_query: delete from slowtech.t1 where id=2;select * from slowtech.t1;update slowtech.t1 set name='c' where id=1
sql_kill_blocking_connection: KILL 2
1 row in set, 1 warning (0.00 sec)

从上边的出口能够见到,blocking_query中满含了会话第11中学当前事情的享有操作,按推行的先后顺序输出。

亟待专一的是,暗中同意情状下,events_statements_history只会保留种种线程方今的十三个操作,假设工作中举行的操作比较多,实际上也是不可能抓全的。

Anyway, it is better than nothing!

 

---- ------ ----------- ------ --------- ------ --------------------------------- ----------------------------------------------------

mysql> select * from information_schema.innodb_trxG
*************************** 1. row ***************************
                    trx_id: 1050390
                 trx_state: RUNNING
               trx_started: 2018-07-17 08:55:32
     trx_requested_lock_id: NULL
          trx_wait_started: NULL
                trx_weight: 4
       trx_mysql_thread_id: 2
                 trx_query: NULL
       trx_operation_state: NULL
         trx_tables_in_use: 0
         trx_tables_locked: 1
          trx_lock_structs: 2
     trx_lock_memory_bytes: 1136
           trx_rows_locked: 3
         trx_rows_modified: 2
   trx_concurrency_tickets: 0
       trx_isolation_level: REPEATABLE READ
         trx_unique_checks: 1
    trx_foreign_key_checks: 1
trx_last_foreign_key_error: NULL
 trx_adaptive_hash_latched: 0
 trx_adaptive_hash_timeout: 0
          trx_is_read_only: 0
trx_autocommit_non_locking: 0
1 row in set (0.00 sec)

可看出ddl操作也被卡住了,从前的事务1也处于sleep状态,十分的小概获悉它毕竟实践了怎么样。

 

此刻我们询问innodb_trx表可看到事务1也看不到sql音信。

其中trx_mysql_thread_id是线程id,结合performance_schema.threads,能够明白当前什么连接上设有着活跃事务,那样就更加的收缩了可被kill的线程范围。

二、应用方案

 但从事电影工作响程度上,和kill全部Command为Sleep的三番五次没太大差异,毕竟,kill真正的空闲连接对作业的熏陶相当小。

方案一

 此时,如故能够依附performance_schema. events_statements_history表。

本身想开的首先种格局是接纳performance_schema中的相关消息查询

 在上篇MySQL 5.7的剖判中,大家是首先知道引发短路的线程ID,然后利用events_statements_history表,查看该线程的连带SQL。

mysql> show variables like 'performance_schema';

 而在MySQL 5.6中,大家并不知道引发拥挤堵塞的线程ID,不过,我们得以违背,利用穷举法,首先总计出富有线程在当前事情实行过的装有SQL,然后再剖断这么些SQL中是还是不是含有指标表。

-------------------- -------

 

|Variable_name      | Value |

具体SQL如下,

-------------------- -------

SELECT
    processlist_id,
    sql_text 
FROM
    (
    SELECT
        c.processlist_id,
        substring_index( sql_text, "transaction_begin;",-1 ) sql_text 
    FROM
        information_schema.innodb_trx a,
        (
        SELECT
            thread_id,
            group_concat( CASE WHEN EVENT_NAME = 'statement/sql/begin' THEN "transaction_begin" ELSE sql_text END ORDER BY event_id SEPARATOR ";" ) AS sql_text 
        FROM
            performance_schema.events_statements_history 
        GROUP BY
            thread_id 
        ) b,
        performance_schema.threads c 
    WHERE
        a.trx_mysql_thread_id = c.processlist_id 
        AND b.thread_id = c.thread_id 
    ) t 
WHERE
    sql_text LIKE '%t1%';

 ---------------- --------------------------------------------------------------------------------------------------------- 
| processlist_id | sql_text                                                                                                |
 ---------------- --------------------------------------------------------------------------------------------------------- 
|              2 | delete from slowtech.t1 where id=2;select * from slowtech.t1;update slowtech.t1 set name='c' where id=1 |
 ---------------- --------------------------------------------------------------------------------------------------------- 
1 row in set (0.01 sec)

|performance_schema  | ON    |

从出口来看,确实也抵达了预期效果。

-------------------- -------

 

1 row in set(0.00 sec)

急需小心的是,在MySQL5.6中,events_statements_history默许是从未有过开启的。

透过查看events_statements_current表可见到每叁个session正在实行的sql,哪怕它依旧实践到位了,只是未有交到。这里可观看事务1最终实行的难为insert into test_lock values(4,'andy');

mysql> SELECT * FROM performance_schema.setup_consumers WHERE NAME LIKE '%statements%';
 -------------------------------- --------- 
| NAME                           | ENABLED |
 -------------------------------- --------- 
| events_statements_current      | YES     |
| events_statements_history      | NO      |
| events_statements_history_long | NO      |
| statements_digest              | YES     |
 -------------------------------- --------- 
4 rows in set (0.00 sec)

mysql> select * from performance_schema.events_statements_currentG

 

唯独方案1有个破绽,三个业务恐怕有一组sql组成,那一个法子只好来看这几个业务最终奉行的是何许SQL,无法看见任何。也正是说,关于information_schema.processlist和events_statements_current怎么样一一对应起来,能够因而performance_schema.threads表来波及,语句如下:

mysql> select * from performance_schema.events_statements_current where THREAD_ID in (select THREAD_ID from performance_schema.threads where PROCESSLIST_ID=4)G

假设你是MySQL 5.7版本,能够经过查阅sys.session视图和sys.processlist视图得到终极三次进行的SQL语句。

方案二

下一场自个儿想到了是还是不是足以用general_log的不二秘籍,日常境况下general_log不大也许张开,所以我们先开发general_log等着难题复现的主意来恒定,经测量试验,尽管专业未有付诸,同样会写到general_log。

mysql> show variables like '%general%';

------------------ -------------------------------------------

| Variable_name    | Value                                     |

------------------ -------------------------------------------

| general_log      | OFF                                       |

| general_log_file | /data/mysql/3306/data/qs-ops-db-01.log |

------------------ -------------------------------------------

2 rows in set (0.00 sec)

mysql> set global general_log=1;

Query OK, 0 rowsaffected (0.00 sec)

敞开general日志后,只要明白了未提交业务的经过号就足以周密找到相应的SQL语句了。

$ cat /data/mysql/3306/data/qs-ops-db-01.log | grep 4

mysqld, Version: 5.7.17-log (MySQL Community Server (GPL)). started with:

Tcp port: 3306  Unix socket: /data/mysql/3306/mysql.sock

Time                 Id Command    Argument

2017-03-29T07:22:00.949233Z 4 Query begin

2017-03-29T07:22:11.090712Z 4 Query update test_lock set id=123 where id=1

2017-03-29T07:22:18.347311Z 4 Query insert into test_lock values(4,'andy')

这么一旦继续能还是不能够复现的话,就可以找到全体的SQL了,便是若是此会话是长连接,那么确定实践的SQL语句相当多,那时候就必要稳步排查了。

方案三

一旦前面应用层最后commit了,那么会在binlog里记录,可以依靠那时的session id去binlog里面查看完整事务。

图片 4

本文由星彩网app下载发布于星彩彩票app下载,转载请注明出处:6中哪些定位DDL被堵塞的标题,7中怎样稳定DDL被打

TAG标签:
Ctrl+D 将本页面保存为书签,全面了解最新资讯,方便快捷。