主从从库MTS HANG死一列

一、故障介绍

最近遇到一个案例，以前从来没遇到过，环境为5.7，从库在执行optimize table语句的时候，出现了MTS hang死的情况，并且无法自动解锁，只能是重启整个数据库(kill -9)，然后才可能恢复。模拟的截图如下，


19df8442819b2c360f120ad73d7e17a.png

当然线上MTS线程堵塞的比较多，但是模拟我只需要2个worker线程堵塞就可以了。这种堵塞状态视乎没有遇到过。因此有必要分析一下其可能的成因。相关参数，

  • binlog_transaction_dependency_tracking :COMMIT_ORDER
  • slave_parallel_type:LOGICAL_CLOCK

二、堵塞可能的分析

从红色部分我们可以看到worker线程有这些现象，

  • 某个worker线程正在执行optimize table操作，处于表级别的MDL LOCK堵塞下，也就是Waiting for table metadata lock。
  • 某个worker线程执行完了自己的工作，但是无法获取提交序列，也就是等待Waiting for preceding transaction to commit

并且2个worker线程无法自动解锁了，因此MTS整体处于hang死状态下。那么需要达到这个状态需要满足几个条件，

  1. Waiting for table metadata lock状态是table级别的MDL LOCK，那么必须要有前置的session 获取了testuuu表上的某种MDL LOCK，（需要注意的是optimize table和DML语句操作的是同一个表，这也是这个问题中比较难以理解的地方，因为MDL LOCK的存在很难说它们能够并发）因为optimize table类似DDL操作因此它一定会获取X MDL LOCK，因此只要session获取testuuu表上的某种MDL LOCK都会堵塞
  2. Waiting for preceding transaction to commit状态，是并发的下的一个等待，那么说明这个时候有相关的操作和optimize table操作进行了并发，并且了解到这个操作是DML 同表的操作，并且这个DML 操作提前来到了提交阶段，但是不是自己的提交序列因此不能提交。

那么同时满足这两个条件的那必须是，

  1. optimize table操作和DML 操作操作了同一表。
  2. optimize table操作和DML 操作的last commit必须相同，这样才可能并发。
  3. DML 操作的seq number必须要在optimize table操作之后，这样才能因为seq number原因DML 语句不能提交堵塞。
  4. DML 操作和optimize table操作虽然并发了，但是DML 必须要先执行完成，如果optimize table操作先完成则不会出堵塞。

但是这里有个明显的问题，DDL操作在提交时刻是上了X锁的，他会堵塞DML 操作，那么这种情况下last commit不可能相同，而第3点来讲这个是可以在从库进行控制的，主要是前面2点必须要达到。

三、主库侧分析

还是接着上面的问题，那我们猜测一下optimize table是否会出现提前解锁的情况，也就是提交没有包裹在MDL LOCK X 下面那么，就可能出现上面的状态，为了验证这个问题我们需要debug获取last commit的点也就是Transaction_ctx::store_commit_parent函数，同时打印出release MDL LOCK的信息，optimize table 如下，

Breakpoint 2, MDL_context::release_lock (this=0x7ffedc000c08, duration=MDL_TRANSACTION, ticket=0x7ffedc032e90) at /opt/percona-server-locks-detail-5.7.22/sql/mdl.cc:4350
4350      MDL_lock *lock= ticket->m_lock;
4: ticket->m_lock->key.mdl_namespace() = MDL_key::SCHEMA
3: ticket->m_lock->key.db_name() = 0x7ffedc032bd5 "testslave0912"
2: ticket->m_lock->key.name() = 0x7ffedc032be3 ""
1: ticket->m_type = MDL_INTENTION_EXCLUSIVE
--- 释放表的X锁
Breakpoint 2, MDL_context::release_lock (this=0x7ffedc000c08, duration=MDL_TRANSACTION, ticket=0x7ffedc032e90) at /opt/percona-server-locks-detail-5.7.22/sql/mdl.cc:4350
4350      MDL_lock *lock= ticket->m_lock;
4: ticket->m_lock->key.mdl_namespace() = MDL_key::TABLE
3: ticket->m_lock->key.db_name() = 0x7ffedc0248d5 "testslave0912"
2: ticket->m_lock->key.name() = 0x7ffedc0248e3 "testuuu"
1: ticket->m_type = MDL_SHARED_READ
--- 释放表上的SR锁
Breakpoint 3, Transaction_ctx::store_commit_parent (this=0x7ffedc004880, last_arg=2) at /opt/percona-server-locks-detail-5.7.22/sql/transaction_info.h:370
370         last_committed= last_arg;
--- 注意这里释放了table级别的MDL LOCK才获取了last commit,那么这个时候DML是可以执行的并且获取last commit的。
Breakpoint 2, MDL_context::release_lock (this=0x7ffedc000c08, duration=MDL_EXPLICIT, ticket=0x7ffedc032e90) at /opt/percona-server-locks-detail-5.7.22/sql/mdl.cc:4350
4350      MDL_lock *lock= ticket->m_lock;
4: ticket->m_lock->key.mdl_namespace() = MDL_key::BINLOG
3: ticket->m_lock->key.db_name() = 0x2f9ae75 ""
2: ticket->m_lock->key.name() = 0x2f9ae76 ""
1: ticket->m_type = MDL_INTENTION_EXCLUSIVE
(gdb) c
Continuing.

看起来确实如此，optimize table语句在释放了MDL LOCK后才获取的last commit信息，并且这个时候DML语句也可以正常的获取last commit信息，那么就给并发创造了条件，接下来是我模拟出来的optimize table和delete 语句相同last commit的binlog片段，大概的过程如下，

断点 session1 session2
Transaction_ctx::store_commit_parent
optimize table testuuu;触发断点
delete from testuuu limit 1 触发断点
session1 继续语句执行成功生成binlog
session2 继续语句执行成功生成binlog
image.png
image.png

这样主库生成binlog的问题就解决了，接下来就是MTS并发了。

四、从库侧并发限制

对于这种DDL和DML语句混合并发的场景，需要考虑在MTS下是否有特殊的代码控制流程，也就是不并发，但是翻看SQL线程分发流程，并没有找到限制，因此我们可以将断点放到GTID event的应用上Gtid_log_event::do_apply_event，并且分析SQL线程分发流程函数Mts_submode_logical_clock::schedule_next_event，因为在GTID event执行的时候是一个事物的开始，这个时候并没有MDL LOCK，也可以控制到底哪个事务先执行。
这里主要就是让delete操作的event先执行，然后因为它的seq number比optimize table大，因此必然堵塞在Waiting for preceding transaction to commit状态下，并且因为没有提交，那么delete语句的MDL LOCK还持有，然后放开执行optimize table操作的worker线程，这个时候optimize table因为获取不到MDL LOCK因此就出现了堵塞，并且无法解决，也就是我们开始看到的问题。

五、optimize table和alter table engine=innodb

从我们上面的分析可以看到optimize table语句在5.7至少是有可能导致MTS从库hang死的情况，原因是optimize table在正式提交写binlog之前放开了MDL LOCK。
optimize table 在innodb引擎中实际上是重建整个表，这个和alter table engine=innodb达到的目的是一样的，那么alter table engine=innodb语句会不会有同样的问题，使用上面的分析方法，发现alter table engine=innodb语句在获取last commit的时候是在MDL LOCK X下面的，因此就会堵塞DML 语句不会出现问题，如下

Breakpoint 3, Transaction_ctx::store_commit_parent (this=0x7ffedc004880, last_arg=7) at /opt/percona-server-locks-detail-5.7.22/sql/transaction_info.h:370
370         last_committed= last_arg;
--- 这里获取last commit
...
Breakpoint 2, MDL_context::release_lock (this=0x7ffedc000c08, duration=MDL_TRANSACTION, ticket=0x7ffedc030a30) at /opt/percona-server-locks-detail-5.7.22/sql/mdl.cc:4350
4350      MDL_lock *lock= ticket->m_lock;
4: ticket->m_lock->key.mdl_namespace() = MDL_key::TABLE
3: ticket->m_lock->key.db_name() = 0x7ffedc0248d5 "testslave0912"
2: ticket->m_lock->key.name() = 0x7ffedc0248e3 "testuuu"
1: ticket->m_type = MDL_EXCLUSIVE
--- 这里释放MDL LOCK X锁

既然提交堵塞同表的DML，那么就不可能模拟出last commit相同的情况，那么从库自然不可能并发，那么如果使用5.7的MTS 最好少执行optimize table语句。 后续需要分析8.0是否可能有这种问题，但是感觉可能性不大。

六、其他


1、制造主库last commit一致的情况，并且DML的seq number大于DDL，目的在于DML在从库先执行的情况下，不能获取到提交序列
2、从库先启动IO thread，目的在于积累一下主库过来的binlog计入relay log中，让并行回放能够发挥作用。
3、观察relay log已经传过来了同样last commit的DDL和MDL 并且MDL的seq number小于DDL。
4、断点open table，确认从库先执行的是DML语句先执行，这个时候会等待提交队列到来，但是这个时候MDL LOCK没有释放
5、执行DDL语句，DDL语句必然等待在meta lock上。

#0  Logical_clock::get_timestamp (this=0x7fff992dc480) at /opt/mysql-5.7.40/sql/rpl_trx_tracking.cc:40
#1  0x00000000014571dc in Transaction_dependency_tracker::get_max_committed_timestamp (this=0x2cebeb0 <mysql_bin_log+5232>) at /opt/mysql-5.7.40/sql/rpl_trx_tracking.cc:406
#2  0x00000000017d8650 in MYSQL_BIN_LOG::commit (this=0x2ceaa40 <mysql_bin_log>, thd=0x7fff7c0010c0, all=false) at /opt/mysql-5.7.40/sql/binlog.cc:8751
#3  0x0000000001627632 in trans_commit_stmt (thd=0x7fff7c0010c0) at /opt/mysql-5.7.40/sql/transaction.cc:470
#4  0x000000000152c318 in mysql_execute_command (thd=0x7fff7c0010c0, first_level=true) at /opt/mysql-5.7.40/sql/sql_parse.cc:4994
#5  0x000000000152dace in mysql_parse (thd=0x7fff7c0010c0, parser_state=0x7fff992de580) at /opt/mysql-5.7.40/sql/sql_parse.cc:5589
#6  0x00000000015232cd in dispatch_command (thd=0x7fff7c0010c0, com_data=0x7fff992dece0, command=COM_QUERY) at /opt/mysql-5.7.40/sql/sql_parse.cc:1492
#7  0x0000000001522134 in do_command (thd=0x7fff7c0010c0) at /opt/mysql-5.7.40/sql/sql_parse.cc:1031
#8  0x0000000001655dfa in handle_connection (arg=0x6db36e0) at /opt/mysql-5.7.40/sql/conn_handler/connection_handler_per_thread.cc:313
#9  0x0000000001ce8ce0 in pfs_spawn_thread (arg=0x6cdbee0) at /opt/mysql-5.7.40/storage/perfschema/pfs.cc:2197
#10 0x00007ffff7bbb764 in start_thread (arg=<optimized out>) at pthread_create.c:477
#11 0x00007ffff60ade2f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95


#0  Transaction_ctx::store_commit_parent (this=0x7fff7c004a70, last_arg=4) at /opt/mysql-5.7.40/sql/transaction_info.h:398
#1  0x00000000017d8662 in MYSQL_BIN_LOG::commit (this=0x2ceaa40 <mysql_bin_log>, thd=0x7fff7c0010c0, all=false) at /opt/mysql-5.7.40/sql/binlog.cc:8751
#2  0x0000000001627632 in trans_commit_stmt (thd=0x7fff7c0010c0) at /opt/mysql-5.7.40/sql/transaction.cc:470
#3  0x000000000152c318 in mysql_execute_command (thd=0x7fff7c0010c0, first_level=true) at /opt/mysql-5.7.40/sql/sql_parse.cc:4994
#4  0x000000000152dace in mysql_parse (thd=0x7fff7c0010c0, parser_state=0x7fff992de580) at /opt/mysql-5.7.40/sql/sql_parse.cc:5589
#5  0x00000000015232cd in dispatch_command (thd=0x7fff7c0010c0, com_data=0x7fff992dece0, command=COM_QUERY) at /opt/mysql-5.7.40/sql/sql_parse.cc:1492
#6  0x0000000001522134 in do_command (thd=0x7fff7c0010c0) at /opt/mysql-5.7.40/sql/sql_parse.cc:1031
#7  0x0000000001655dfa in handle_connection (arg=0x6db36e0) at /opt/mysql-5.7.40/sql/conn_handler/connection_handler_per_thread.cc:313
#8  0x0000000001ce8ce0 in pfs_spawn_thread (arg=0x6cdbee0) at /opt/mysql-5.7.40/storage/perfschema/pfs.cc:2197
#9  0x00007ffff7bbb764 in start_thread (arg=<optimized out>) at pthread_create.c:477
#10 0x00007ffff60ade2f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95


#0  Commit_order_trx_dependency_tracker::update_max_committed (this=0x2cebf08 <mysql_bin_log+5320>, sequence_number=6) at /opt/mysql-5.7.40/sql/rpl_trx_tracking.cc:165
#1  0x00000000014570d6 in Transaction_dependency_tracker::update_max_committed (this=0x2cebeb0 <mysql_bin_log+5232>, thd=0x7fff7c0010c0) at /opt/mysql-5.7.40/sql/rpl_trx_tracking.cc:374
#2  0x00000000017d930d in MYSQL_BIN_LOG::process_commit_stage_queue (this=0x2ceaa40 <mysql_bin_log>, thd=0x7fff7c0010c0, first=0x7fff7c0010c0) at /opt/mysql-5.7.40/sql/binlog.cc:9038
#3  0x00000000017dacd6 in MYSQL_BIN_LOG::ordered_commit (this=0x2ceaa40 <mysql_bin_log>, thd=0x7fff7c0010c0, all=false, skip_commit=false) at /opt/mysql-5.7.40/sql/binlog.cc:9762
#4  0x00000000017d8d2c in MYSQL_BIN_LOG::commit (this=0x2ceaa40 <mysql_bin_log>, thd=0x7fff7c0010c0, all=false) at /opt/mysql-5.7.40/sql/binlog.cc:8870
#5  0x0000000001627632 in trans_commit_stmt (thd=0x7fff7c0010c0) at /opt/mysql-5.7.40/sql/transaction.cc:470
#6  0x000000000152c318 in mysql_execute_command (thd=0x7fff7c0010c0, first_level=true) at /opt/mysql-5.7.40/sql/sql_parse.cc:4994
#7  0x000000000152dace in mysql_parse (thd=0x7fff7c0010c0, parser_state=0x7fff992de580) at /opt/mysql-5.7.40/sql/sql_parse.cc:5589
#8  0x00000000015232cd in dispatch_command (thd=0x7fff7c0010c0, com_data=0x7fff992dece0, command=COM_QUERY) at /opt/mysql-5.7.40/sql/sql_parse.cc:1492
#9  0x0000000001522134 in do_command (thd=0x7fff7c0010c0) at /opt/mysql-5.7.40/sql/sql_parse.cc:1031
#10 0x0000000001655dfa in handle_connection (arg=0x6db36e0) at /opt/mysql-5.7.40/sql/conn_handler/connection_handler_per_thread.cc:313
#11 0x0000000001ce8ce0 in pfs_spawn_thread (arg=0x6cdbee0) at /opt/mysql-5.7.40/storage/perfschema/pfs.cc:2197
#12 0x00007ffff7bbb764 in start_thread (arg=<optimized out>) at pthread_create.c:477
#13 0x00007ffff60ade2f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95


(gdb) info b
Num     Type           Disp Enb Address            What
1       breakpoint     keep y   0x0000000000e8166c in main(int, char**) at /opt/mysql-5.7.40/sql/main.cc:32
        breakpoint already hit 1 time
2       breakpoint     keep y   0x00000000017e0fe8 in Transaction_ctx::store_commit_parent(long long) at /opt/mysql-5.7.40/sql/transaction_info.h:398
        breakpoint already hit 7 times
3       breakpoint     keep y   0x00000000014572fa in Logical_clock::get_timestamp() at /opt/mysql-5.7.40/sql/rpl_trx_tracking.cc:40
        breakpoint already hit 6 times
5       breakpoint     keep y   0x0000000001456a36 in Commit_order_trx_dependency_tracker::update_max_committed(long long) at /opt/mysql-5.7.40/sql/rpl_trx_tracking.cc:165
        breakpoint already hit 2 times
6       breakpoint     keep y   0x0000000001421789 in MDL_context::acquire_lock(MDL_request*, unsigned long) at /opt/mysql-5.7.40/sql/mdl.cc:3564
        breakpoint already hit 17 times
7       breakpoint     keep y   <MULTIPLE>         
        breakpoint already hit 13 times
7.1                         y     0x000000000142295a in MDL_context::release_lock(enum_mdl_duration, MDL_ticket*) at /opt/mysql-5.7.40/sql/mdl.cc:4286
7.2                         y     0x0000000001422cd2 in MDL_context::release_lock(MDL_ticket*) at /opt/mysql-5.7.40/sql/mdl.cc:4417
(gdb) d 6
#240918 11:29:49 server id 322  end_log_pos 28019 CRC32 0xecee4a11      GTID    last_committed=81       sequence_number=82      rbr_only=no
SET @@SESSION.GTID_NEXT= 'ec9f995d-e5a1-11ee-900b-000c2963503f:104'/*!*/;
# at 28019
#240918 11:29:49 server id 322  end_log_pos 28133 CRC32 0x7aba525e      Query   thread_id=4     exec_time=1     error_code=0
SET TIMESTAMP=1726630189/*!*/;
optimize table testuuu
/*!*/;
# at 28133
#240918 11:29:55 server id 322  end_log_pos 28198 CRC32 0x6b33d92a      GTID    last_committed=81       sequence_number=83      rbr_only=yes
/*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;
SET @@SESSION.GTID_NEXT= 'ec9f995d-e5a1-11ee-900b-000c2963503f:105'/*!*/;
# at 28198
#240918 11:29:55 server id 322  end_log_pos 28279 CRC32 0x76c956ab      Query   thread_id=5     exec_time=0     error_code=0
SET TIMESTAMP=1726630195/*!*/;
BEGIN
/*!*/;
# at 28279
#240918 11:29:55 server id 322  end_log_pos 28330 CRC32 0xb13102e7      Rows_query
# delete from testuuu limit 1
# at 28330
#240918 11:29:55 server id 322  end_log_pos 28389 CRC32 0x621ca080      Table_map: `testslave0912`.`testuuu` mapped to number 117
# at 28389
#240918 11:29:55 server id 322  end_log_pos 28429 CRC32 0x98691042      Delete_rows: table id 117 flags: STMT_END_F

BINLOG '
M0nqZh1CAQAAMwAAAKpuAACAABtkZWxldGUgZnJvbSB0ZXN0dXV1IGxpbWl0IDHnAjGx
M0nqZhNCAQAAOwAAAOVuAAAAAHUAAAAAAAEADXRlc3RzbGF2ZTA5MTIAB3Rlc3R1dXUAAQMAAYCg
HGI=
M0nqZiBCAQAAKAAAAA1vAAAAAHUAAAAAAAEAAgAB//4BAAAAQhBpmA==
'/*!*/;
### DELETE FROM `testslave0912`.`testuuu`
### WHERE
###   @1=1 /* INT meta=0 nullable=1 is_null=0 */
# at 28429
#240918 11:29:55 server id 322  end_log_pos 28460 CRC32 0x9a4c1bbd      Xid = 126
COMMIT/*!*/;
SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/;
DELIMITER ;
# End of log file
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;



Num     Type           Disp Enb Address            What
1       breakpoint     keep y   0x0000000000eb13ac in main(int, char**) at /opt/percona-server-locks-detail-5.7.22/sql/main.cc:25
        breakpoint already hit 1 time
3       breakpoint     keep y   0x00000000017efb70 in Gtid_log_event::do_apply_event(Relay_log_info const*) at /opt/percona-server-locks-detail-5.7.22/sql/log_event.cc:13859
        breakpoint already hit 2 times
5       breakpoint     keep y   0x0000000001877113 in Mts_submode_logical_clock::wait_for_last_committed_trx(Relay_log_info*, long long, long long) at /opt/percona-server-locks-detail-5.7.22/sql/rpl_mts_submode.cc:456
(gdb) d 3


Mts_submode_logical_clock::wait_for_last_committed_trx


Transaction_ctx::store_commit_parent(long long)


alter table engine=innodb;

#0  Transaction_ctx::store_commit_parent (this=0x7ffedc004880, last_arg=5) at /opt/percona-server-locks-detail-5.7.22/sql/transaction_info.h:370
#1  0x0000000001815f5e in MYSQL_BIN_LOG::commit (this=0x2dc09e0 <mysql_bin_log>, thd=0x7ffedc000b70, all=false) at /opt/percona-server-locks-detail-5.7.22/sql/binlog.cc:8889
#2  0x0000000000f54824 in ha_commit_trans (thd=0x7ffedc000b70, all=false, ignore_global_read_lock=false) at /opt/percona-server-locks-detail-5.7.22/sql/handler.cc:1830
#3  0x0000000001676337 in trans_commit_stmt (thd=0x7ffedc000b70) at /opt/percona-server-locks-detail-5.7.22/sql/transaction.cc:458
#4  0x0000000001570408 in mysql_execute_command (thd=0x7ffedc000b70, first_level=true) at /opt/percona-server-locks-detail-5.7.22/sql/sql_parse.cc:5293
#5  0x0000000001571bed in mysql_parse (thd=0x7ffedc000b70, parser_state=0x7fffec1255b0) at /opt/percona-server-locks-detail-5.7.22/sql/sql_parse.cc:5901
#6  0x000000000156673d in dispatch_command (thd=0x7ffedc000b70, com_data=0x7fffec125d90, command=COM_QUERY) at /opt/percona-server-locks-detail-5.7.22/sql/sql_parse.cc:1490
#7  0x00000000015655c5 in do_command (thd=0x7ffedc000b70) at /opt/percona-server-locks-detail-5.7.22/sql/sql_parse.cc:1021
#8  0x00000000016a635c in handle_connection (arg=0x64c3f10) at /opt/percona-server-locks-detail-5.7.22/sql/conn_handler/connection_handler_per_thread.cc:312
#9  0x00000000018ce0f6 in pfs_spawn_thread (arg=0x6554610) at /opt/percona-server-locks-detail-5.7.22/storage/perfschema/pfs.cc:2190
#10 0x00007ffff7bc6ea5 in start_thread () from /lib64/libpthread.so.0
#11 0x00007ffff66008dd in clone () from /lib64/libc.so.6

optimize table 提前释放了MDL LOCK



Breakpoint 2, MDL_context::release_lock (this=0x7ffedc000c08, duration=MDL_TRANSACTION, ticket=0x7ffedc032e90) at /opt/percona-server-locks-detail-5.7.22/sql/mdl.cc:4350
4350      MDL_lock *lock= ticket->m_lock;
4: ticket->m_lock->key.mdl_namespace() = MDL_key::TABLE
3: ticket->m_lock->key.db_name() = 0x7ffedc0248d5 "testslave0912"
2: ticket->m_lock->key.name() = 0x7ffedc0248e3 "testuuu"
1: ticket->m_type = MDL_EXCLUSIVE
(gdb) bt
#0  MDL_context::release_lock (this=0x7ffedc000c08, duration=MDL_TRANSACTION, ticket=0x7ffedc032e90) at /opt/percona-server-locks-detail-5.7.22/sql/mdl.cc:4350
#1  0x0000000001464bf1 in MDL_context::release_locks_stored_before (this=0x7ffedc000c08, duration=MDL_TRANSACTION, sentinel=0x0) at /opt/percona-server-locks-detail-5.7.22/sql/mdl.cc:4521
#2  0x00000000014653c5 in MDL_context::release_transactional_locks (this=0x7ffedc000c08) at /opt/percona-server-locks-detail-5.7.22/sql/mdl.cc:4805
#3  0x0000000001776fa8 in mysql_admin_table(THD *, TABLE_LIST *, HA_CHECK_OPT *, const char *, thr_lock_type, bool, bool, uint, int (*)(THD *, TABLE_LIST *, HA_CHECK_OPT *), struct {...}, int (*)(THD *, TABLE_LIST *)) (thd=0x7ffedc000b70, tables=0x7ffedc006588, check_opt=0x7ffedc0036a0, operator_name=0x21fcdf0 "optimize", lock_type=TL_WRITE, open_for_modify=false, 
    repair_table_use_frm=false, extra_open_options=0, prepare_func=0x0, operator_func=
    (int (handler::*)(handler * const, THD *, HA_CHECK_OPT *)) 0xf5ca60 <handler::ha_optimize(THD*, st_ha_check_opt*)>, view_operator_func=0x0)
    at /opt/percona-server-locks-detail-5.7.22/sql/sql_admin.cc:830
#4  0x000000000177861d in Sql_cmd_optimize_table::execute (this=0x7ffedc006b20, thd=0x7ffedc000b70) at /opt/percona-server-locks-detail-5.7.22/sql/sql_admin.cc:1272
#5  0x000000000156fb51 in mysql_execute_command (thd=0x7ffedc000b70, first_level=true) at /opt/percona-server-locks-detail-5.7.22/sql/sql_parse.cc:5117
#6  0x0000000001571bed in mysql_parse (thd=0x7ffedc000b70, parser_state=0x7fffec1255b0) at /opt/percona-server-locks-detail-5.7.22/sql/sql_parse.cc:5901
#7  0x000000000156673d in dispatch_command (thd=0x7ffedc000b70, com_data=0x7fffec125d90, command=COM_QUERY) at /opt/percona-server-locks-detail-5.7.22/sql/sql_parse.cc:1490
#8  0x00000000015655c5 in do_command (thd=0x7ffedc000b70) at /opt/percona-server-locks-detail-5.7.22/sql/sql_parse.cc:1021
#9  0x00000000016a635c in handle_connection (arg=0x659fa40) at /opt/percona-server-locks-detail-5.7.22/sql/conn_handler/connection_handler_per_thread.cc:312
#10 0x00000000018ce0f6 in pfs_spawn_thread (arg=0x6594e50) at /opt/percona-server-locks-detail-5.7.22/storage/perfschema/pfs.cc:2190
#11 0x00007ffff7bc6ea5 in start_thread () from /lib64/libpthread.so.0
#12 0x00007ffff66008dd in clone () from /lib64/libc.so.6
最后编辑于 ：
©著作权归作者所有,转载或内容合作请联系作者
  • 人面猴
    序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
    沈念sama阅读 216,142评论 6赞 498
  • 死咒
    序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
    沈念sama阅读 92,298评论 3赞 392
  • 救了他两次的神仙让他今天三更去死
    文/潘晓璐 我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
    开封第一讲书人阅读 162,068评论 0赞 351
  • 道士缉凶录：失踪的卖姜人
    文/不坏的土叔 我叫张陵，是天一观的道长。 经常有香客问我，道长，这世上最难降的妖魔是什么？ 我笑而不...
    开封第一讲书人阅读 58,081评论 1赞 291
  • 港岛之恋（遗憾婚礼）
    正文 为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
    茶点故事阅读 67,099评论 6赞 388
  • 恶毒庶女顶嫁案：这布局不是一般人想出来的
    文/花漫 我一把揭开白布。 她就那样静静地躺着，像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上，一...
    开封第一讲书人阅读 51,071评论 1赞 295
  • 城市分裂传说
    那天，我揣着相机与录音，去河边找鬼。 笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。 我是一名探鬼主播，决...
    沈念sama阅读 39,990评论 3赞 417
  • 双鸳鸯连环套：你想象不到人心有多黑
    文/苍兰香墨 我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
    开封第一讲书人阅读 38,832评论 0赞 273
  • 万荣杀人案实录
    序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
    沈念sama阅读 45,274评论 1赞 310
  • 护林员之死
    正文 独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,488评论 2赞 331
  • 白月光启示录
    正文 我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,649评论 1赞 347
  • 活死人
    序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
    沈念sama阅读 35,378评论 5赞 343
  • 日本核电站爆炸内幕
    正文 年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
    茶点故事阅读 40,979评论 3赞 325
  • 男人毒药：我在死后第九天来索命
    文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,625评论 0赞 21
  • 一桩弑父案，背后竟有这般阴谋
    文/苍兰香墨 我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,796评论 1赞 268
  • 情欲美人皮
    我被黑心中介骗来泰国打工， 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。 一个月前我还...
    沈念sama阅读 47,643评论 2赞 368
  • 代替公主和亲
    正文 我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
    茶点故事阅读 44,545评论 2赞 352