這篇文章主要介紹“MySQL中sending data狀態(tài)包含了什么”，在日常操作中，相信很多人在MySQL中sending data狀態(tài)包含了什么問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”MySQL中sending data狀態(tài)包含了什么”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！
原問題如下：
數(shù)據(jù)庫發(fā)送數(shù)據(jù)給客戶端這個時間算是sql的執(zhí)行時間嘛？
要解決問題我們需要知道MySQL何時將數(shù)據(jù)傳輸給了客戶端，既然是要傳輸實際的數(shù)據(jù)給客戶端那么肯定是select語句了，同時我們要明白一個正常select運行到底要經(jīng)歷哪些階段。
2392 T@10: | | | | | THD::enter_stage: 'checking permissions' /root/mysql5.7.14/percona-server-5.7.14-7/sql/auth/sql_authorization.cc:843 2404 T@10: | | | | | | THD::enter_stage: 'Opening tables' /root/mysql5.7.14/percona-server-5.7.14-7/sql/sql_base.cc:5719 2512 T@10: | | | | | THD::enter_stage: 'init' /root/mysql5.7.14/percona-server-5.7.14-7/sql/sql_select.cc:121 2681 T@10: | | | | | | | THD::enter_stage: 'System lock' /root/mysql5.7.14/percona-server-5.7.14-7/sql/lock.cc:321 2772 T@10: | | | | | | | THD::enter_stage: 'optimizing' /root/mysql5.7.14/percona-server-5.7.14-7/sql/sql_optimizer.cc:151 2865 T@10: | | | | | | | THD::enter_stage: 'statistics' /root/mysql5.7.14/percona-server-5.7.14-7/sql/sql_optimizer.cc:386 3329 T@10: | | | | | | | THD::enter_stage: 'preparing' /root/mysql5.7.14/percona-server-5.7.14-7/sql/sql_optimizer.cc:494 3466 T@10: | | | | | | THD::enter_stage: 'executing' /root/mysql5.7.14/percona-server-5.7.14-7/sql/sql_executor.cc:119 3474 T@10: | | | | | | THD::enter_stage: 'Sending data' /root/mysql5.7.14/percona-server-5.7.14-7/sql/sql_executor.cc:195 3668 T@10: | | | | | THD::enter_stage: 'end' /root/mysql5.7.14/percona-server-5.7.14-7/sql/sql_select.cc:199 3685 T@10: | | | | THD::enter_stage: 'query end' /root/mysql5.7.14/percona-server-5.7.14-7/sql/sql_parse.cc:5174 3754 T@10: | | | | THD::enter_stage: 'closing tables' /root/mysql5.7.14/percona-server-5.7.14-7/sql/sql_parse.cc:5252 3882 T@10: | | | THD::enter_stage: 'freeing items' /root/mysql5.7.14/percona-server-5.7.14-7/sql/sql_parse.cc:5855
實際上整個階段都算到了語句的實際消耗時間之中的，但是慢查詢記錄的是：
實際執(zhí)行時間 = (freeing items 末端的時間) 實際消耗時間 - (System lock末端的時間 )比如MDL LOCK等待時間 - (Innodb層鎖定的時間)行鎖等待消耗時間
關于慢查詢的詳細情況可以參考我的一篇文章，這里不再重述。
實際上這個狀態(tài)是select語句才會有的，如果是DML則不同但是都有等同的階段如下：
select：Sending data
insert語句：Update
delete/update：Updating
這個階段非常的巨大，它至少包含了：
Innodb 層數(shù)據(jù)的定位返回給MySQL 層
Innodb 層數(shù)據(jù)的查詢返回給MySQL 層
Innodb 層數(shù)據(jù)的修改(如果是MDL)
Innodb 層加鎖以及等待
等待進入Innodb層(innodb_thread_concurrency參數(shù))
MySQL 層發(fā)送數(shù)據(jù)給客戶端
可以看到基本所有和Innodb層打交道的過程都包裹在這個狀態(tài)下面，當然我只是列舉了我想到的一些，其實可能還有很多很多，這里我也把 MySQL 層發(fā)送數(shù)據(jù)給客戶端包含在 Sending data的答案給出了，下面我們進行分析。
之前你可以參考一下我的文章
我們建立一個簡單的表如下，并且填充數(shù)據(jù)如下：
Create Table: CREATE TABLE `ty` ( `id` int(11) NOT NULL AUTO_INCREMENT, `a` int(11) DEFAULT NULL, `b` int(11) DEFAULT NULL, PRIMARY KEY (`id`), KEY `idxa` (`a`) ) ENGINE=InnoDB AUTO_INCREMENT=12 DEFAULT CHARSET=utf8mb4 mysql> select * from ty; +----+------+------+| id | a | b |+----+------+------+| 8 | 2 | 3 || 9 | 5 | 4 || 10 | 6 | 7 || 11 | 6 | 8 |+----+------+------+4 rows in set (4.14 sec)
我們執(zhí)行如下語句：
mysql> desc select * from ty where a =6 and b=8; +----+-------------+-------+------------+------+---------------+------+---------+-------+------+----------+-------------+| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra | +----+-------------+-------+------------+------+---------------+------+---------+-------+------+----------+-------------+ | 1 | SIMPLE | ty | NULL | ref | idxa | idxa | 5 | const | 2 | 33.33 | Using where |+----+-------------+-------+------------+------+---------------+------+---------+-------+------+----------+-------------+ mysql> select * from ty where a =6 and b=8; +----+------+------+| id | a | b |+----+------+------+| 11 | 6 | 8 |+----+------+------+1 row in set (7.22 sec)
注意：這里的語句執(zhí)行時間很長是因為我打了GDB斷點所以看起來很久而已
我做了語句的trace，這個語句大概需要如下步驟：
首先Innodb定位到索引 idxa數(shù)據(jù)6所在位置這是初次定位調(diào)用函數(shù)ha_innobase::index_read，返回數(shù)據(jù)| 10 | 6 | 7 |給MySQL層，但是MySQL層過濾掉不符合條件 a =6 and b=8 不需要返回給客戶端。
重慶分公司
重慶分公司
