mysql 5.7 引擎_MySQL 5.7 学习：功能性能的提升

1.9：多线程脏页刷写

innodb_page_cleaners，表示刷写BP脏页的线程数，5.6.2开始从master线程中独立出来，5.7.4之后开始支持多线程flush，默认是4。这个值必须小于等于innodb_buffer_pool_instances，提高CPU的利用率。

1.10：终止会话ctrl+c

在linux下，我们经常使用ctrl+c来终止一个命令的运行，在MySQL 5.7 之前，如果用户输入了错误的SQL语句，按下ctrl+c，虽然能够"结束"SQL语句的运行，但是，也会退出当前会话，MySQL 5.7对这一违反直觉的地方进行了改进，不再退出会话。

1.11：临时表性能的优化

MYSQL5.7为了提高临时表相关的性能，对临时表相关的部分进行了大幅修改，包括引入新的临时表空间(ibtmp1)；对于临时表的DDL，不持久化相关表定义；对于临时表的DML，不写redo，关闭change buffer等。

InnoDB临时表元数据不再存储于InnoDB系统表而是存储在INNODB_TEMP_TABLE_INFO，包含所有用户和系统创建的临时表信息。该表在第一次在其上运行select时被创建：

mysql> select * frominformation_schema.innodb_temp_table_info;

Emptyset (0.00sec)

mysql> usedba_test

mysql> create temporary table temp_1(id int,name varchar(100))defaultcharset utf8;

Query OK,0 rows affected (0.00sec)

mysql> select * frominformation_schema.innodb_temp_table_info;+----------+--------------+--------+-------+----------------------+---------------+

+----------+--------------+--------+-------+----------------------+---------------+

| 42 | #sql1883_8_0 | 5 | 27 | FALSE | FALSE |

+----------+--------------+--------+-------+----------------------+---------------+

1 row in set (0.00 sec)

并且MySQL5.7使用了独立的临时表空间来存储临时表数据，但不能是压缩表。临时表空间在实例启动的时候进行创建，shutdown的时候进行删除。即为所有非压缩的innodb临时表提供一个独立的表空间，默认的临时表空间文件为ibtmp1，位于数据目录。我们可通过innodb_temp_data_file_path参数指定临时表空间的路径和大小，默认12M。只有重启实例才能回收临时表空间文件ibtmp1的大小。create temporary table和using temporary table将共用这个临时表空间。

mysql >show variables like 'innodb_temp_data_file_path';+----------------------------+-----------------------+

| Variable_name | Value |

+----------------------------+-----------------------+

| innodb_temp_data_file_path | ibtmp1:12M:autoextend |

+----------------------------+-----------------------+

物理文件：

# ls -lh ibtmp1-rw-r----- 1 mysql mysql 12M 7月 12 15:13 ibtmp1

mysql> create temporary table temp_1(id int,name varchar(100))default character setutf8;

Query OK,0 rows affected (0.01sec)

mysql> insert into temp_1 select * fromttt;

Query OK,2752512 rows affected (7.10sec)

Records:2752512 Duplicates: 0 Warnings: 0# ls-lh ibtmp1-rw-r----- 1 mysql mysql 204M 7月 12 15:16 ibtmp1 #重启才能回收

在MySQL5.7中，临时表在连接断开或者数据库实例关闭的时候，会进行删除，也就无需redo logs，避免了写relog相关的io，从而提高了性能。只有临时表的metadata使用了redo保护，保护元数据的完整性，以便异常启动后进行清理工作。临时表的元数据5.7之后使用了一个独立的表(innodb_temp_table_info)进行保存，这样就不要使用redo保护，元数据也只保存在内存中。但这有一个前提，必须使用共享的临时表空间，如果使用file-per-table，仍然需要持久化元数据，以便异常恢复清理。临时表需要undo log，用于MySQL运行时的回滚、MVCC等。具体的可以看官方文档和

注意：从5.7.5开始，新增一个系统选项internal_tmp_disk_storage_engine可定义磁盘临时表的引擎类型，默认为InnoDB，可选MyISAM。而在这以前，只能使用MyISAM。而在5.6.3以后新增的参数default_tmp_storage_engine是控制create temporary table创建的临时表的存储引擎，在以前默认是MEMORY。

mysql> show variables like '%engine%';+----------------------------------+--------+

| Variable_name | Value |

+----------------------------------+--------+

| default_storage_engine | InnoDB |

| default_tmp_storage_engine | InnoDB |

| disabled_storage_engines | |

| enforce_storage_engine | |

| internal_tmp_disk_storage_engine | InnoDB |

+----------------------------------+--------+

1.12：离线的InnoDB文件校验工具功能增强，可以查看ibd文件。新增选择项或扩展的功能：

1.支持使用指定校验算法；2.支持只重写校验值而不进行验证；3.可指定允许的校验和不匹配量；4.显示各类页的个数、导出页类型信息、输出至日志、从标准输入读取数据等；5.从5.7.2起可支持校验超过2G的文件；

innochecksum --help。使用时需要停止mysql服务，或则把ibd文件复制出来，否则会报错：

# innochecksum --page-type-summary ibdata1

Error: Unable to lock file:: ibdata1

fcntl: Resource temporarily unavailable

关闭数据库或则复制出ibd文件执行：

# innochecksum --page-type-summary /tmp/ibdata1

File::/tmp/ibdata1================PAGE TYPE SUMMARY==============#PAGE_COUNT PAGE_TYPE===============================================

13 Indexpage #索引页2820 Undo logpage #undo页2Inode page0 Insertbuffer free list page #插入缓存空闲页1928Freshly allocated page #可用页1 Insertbuffer bitmap #插入缓存位图页98System page #系统页1 Transactionsystem page1 File SpaceHeader0Extent descriptor page0BLOB page0Compressed BLOB page0 Other type ofpage===============================================Additional information:

Undo page type:2806 insert, 14 update, 0other

Undo page state:0 active, 36 cached, 0 to_free, 0 to_purge, 0 prepared, 2784 other

通过 --page-type-summary参数可以看到表空间里面各个页的情况，关于页的一些细节信息可以参考看MySQL Innodb 存储结构。

通过 --count 参数可以查看表空间的总页数：

# innochecksum --count /tmp/ibdata1

Number of pages:4864

更多的信息可以查看官方文档和这篇文章说明。

1.13：默认行格式改变，由innodb_default_row_format控制，5.7.9之后默认DYNAMIC，之前默认COMPACT。更多信息见官方文档。

1.14：官方文档。

mysql> create tablespacedxy add datafile 'dxy.ibd' file_block_size=16k; #创建名为dxy的共享表空间

Query OK,0 rows affected (0.10sec)

mysql> create table t1(id int,name varchar(10))engine = innodb defaultcharset utf8mb4 tablespace dxy; #指定表空间

Query OK,0 rows affected (0.09sec)

# ls-lh-rw-r----- 1 mysql mysql 96K 7月 14 12:11 dxy.ibd #查看表空间文件mysql> alter tablettt tablespace dxy; #指定表空间

# ls-lh dxy.ibd-rw-r----- 1 mysql mysql 244M 7月 14 12:18 dxy.ibd #表空间文件变大

如何删除创建的共享表空间？因为是共享表空间不能直接通过drop table tbname来删除，也不能回收空间。当确定共享表空间的数据都没用，并且依赖该表空间的表均已经删除，则可以通过drop tablespace来删除共享表空间来释放空间，如果依赖该共享表空间的表存在则会删除失败。

# ls -lh dxy.ibd-rw-r----- 1 mysql mysql 452M 7月 14 12:27 dxy.ibd

mysql> drop tablet1; #删除依赖该表空间的表

Query OK,0 rows affected (0.16sec)

mysql> droptablespace dxy; #删除表空间

ERROR1529 (HY000): Failed to dropTABLESPACE dxy #删除失败，因为还有表依赖这个表空间。

mysql> drop tablettt;

Query OK,0 rows affected (0.04sec)

mysql> droptablespace dxy; #成功删除自建的共享表空间

Query OK,0 rows affected (0.03sec)

# ls-lh dxy.ibd

ls: cannot access dxy.ibd: No suchfile or directory #ibd文件被删除，空间回收。

1.15：

[mysqld]early-plugin-load=keyring_file.so

开始参数后，查看是否支持：

mysql> SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS where PLUGIN_NAME LIKE 'keyring%';+--------------+---------------+

| PLUGIN_NAME | PLUGIN_STATUS |

+--------------+---------------+

| keyring_file | ACTIVE |

+--------------+---------------+

1 row in set (0.00 sec)

创建加密表空间：

mysql> create table t(id int,name varchar(10))engine = innodb default charset utf8mb4 encryption='y';

Query OK,0 rows affected (0.17sec)

mysql> show create tablet\G*************************** 1. row ***************************

Table: tCreate Table: CREATE TABLE`t` (

`id`int(11) DEFAULT NULL,

`name`varchar(10) DEFAULT NULL) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 ENCRYPTION='y'1 row in set (0.00 sec)

1.16：MySQL一直使用double write buffer来解决一个page写入的partial write问题，但在linux系统上的Fusion-io Non-Volatile Memory (NVM) file system支持原子的写入。这样就可以省略掉double write buffer的使用， 5.7.4以后，如果Fusion-io devices支持atomic write，那么MySQL自动把dirty block直接写入到数据文件了。这样减少了一次内存copy和IO操作。

1.17：InnoDB分区表。MySQL 5.7之前的版本，InnoDB并不支持分区表，分区表的支持是在ha_partition引擎上支持的，从5.7开始，InnoDB支持原生的分区表，并且可以使用传输表空间。

1.18：支持在一个table对象上建多个trigger。

持续更新...

...

MySQL 5.7.7版本之后新增了sys 数据库，该库通过视图的形式把information_schema和performance_schema结合起来，查询出更加令人容易理解的数据，帮助dba和开发人员收集的数据库性能信息，快速定位性能瓶颈。sys下的一共包括三种对象：1. view，2. procedure 3 function

这些对象都是基于performance_schema下的表，进行了可读性的聚合，没有真正存储数据，只存储了定义。默认通过账号'mysql.sys'@'localhost'收集信息，之前是root@localhost进行收集操作。安装时可以通过--skip-sys-schema跳过安装。后面会另起一篇文章对sys schema进行说明，也可以先看MySQL 5.7系列之sys schema(2) by吴炳锡。

3，被删除和被修改默认值的参数和特性

参数移除：

3.1：MySQL 5.7.4之后innodb_additional_mem_pool_size参数被移除。原来是存放数据字典和内部数据结构，要是表很多，需要分配更多的内存。若缓冲池的内存溢出则需要从系统分配内存，但会写一个warning到错误日志。

3.2：MySQL5.7.4之后innodb_use_sys_malloc参数被移除。原来表示InnoDB使用操作系统内存分配器还是自己的内存分配器，默认是使用操作系统内存分配器。3.1和3.2被移除的原因，是因为内部实现不如外部的实现，可以见http://www.kancloud.cn/taobaomysql/monthly/143931。

3.3：innodb 存储引擎不能被禁用，系统表有innodb表。 --innodb=OFF and --skip-innodb没有作用，未来会移除该参数。

3.5：innodb_large_prefix在MySQL5.7.7中被弃用，将来会移除。该参数表示当innodb为字段创建索引时，限制的字节长度。关闭时，字节长度大于767则会报错。开启时，大于3072则会报错，创建不成功。

3.6：innodb_locks_unsafe_for_binlog在MySQL5.6.3被弃用，将来会移除。该参数表示innodb锁和二进制的安全问题，当ON的时候可以避免gap lock的问题，但是会引起binlog写入顺序出问题，导致主从数据不一致。建议关闭。

3.7：innodb_support_xa在MySQL5.7.1中被弃用，将来会移除。MySQL5.7.1之后不能禁用innodb_support_xa。虽然它会导致一次额外的磁盘flush(prepare阶段flush redo log). 但是我们必须启用，而不能关闭它。因为关闭会导致binlog写入的顺序和实际的事务提交顺序不一致，会导致崩溃恢复和slave复制时发生数据错误。如果启用了log-bin参数，并且不止一个线程对数据库进行修改，那么就必须启用innodb_support_xa参数。

3.8：@@session.gtid_executed 不建议使用，将来会移除。

3.9：binlog_format在MySQL5.7.7之后，默认值变成ROW。

3.10：slave_net_timeout在MySQL5.7.7之后，默认改成60秒。该参数定义了从库从主库获取数据等待的秒数，超过这个时间从库会主动退出读取，中断连接，并尝试重连。即：设置在多久没收到数据后认为网络超时，之后 Slave 的 IO 线程会重新连接 Master。此前的默认值是3600秒，长时间的复制延迟很可能是网络瞬断造成的。可以用一个心跳时间

说明：

在MySQL的复制协议里，由 Slave 发送一个 COM_BINLOG_DUMP 命令后，就完全由 Master 来推送数据，Master、Slave 之间不再需要交互。如果 Master 没有更新，也就不会有数据流，Slave 就不会收到任何数据包。但是如果由于某种原因造成 Master 无法把数据发送到 Slave ，比如发生过网络故障或其他原因导致 Master 上的 TCP 连接丢失，Slave 没有机会得到通知，所以也没法知道收不到数据是因为 Master 本来就没有更新呢还是由于出了故障。

stop slave;

change master to master_heartbeat_period= 10;

set global slave_net_timeout= 25;

start slave;

心跳会让Master 在没有数据的时候，每10秒发送一个心跳包。这样 Slave 就能知道 Master 是不是还正常。slave_net_timeout是设置在多久没收到数据后认为网络超时，之后 Slave 的 IO 线程会重新连接 Master 。

结合这两个设置就可以避免由于网络问题导致的复制延误。master_heartbeat_period 单位是秒，可以是个带上小数，如10.5。最高精度为 1毫秒。

需要注意的是：默认情况heartbeat_period的值是slave_net_timeout的一般。在从上通过show global status like'slave%'来查看心跳信息。

要是heartbeat_period设置大于slave_net_timeout会报warnings：

The requested valuefor the heartbeat period exceeds the value of `slave_net_timeout'seconds. A sensible value for the period should be less than the timeout.

View Code

关于从库重连主库的相关信息：

MySQL 可以指定三个参数，用于复制线程重连主库： --master-retry-count ， --master-connect-retry ， --slave-net-timeout 。

其中 master-connect-retry 和 master-retry-count 需要在 Change Master 搭建主备复制时指定，而 slave-net-timeout 是一个全局变量，可以在 MySQL 运行时在线设置。

具体的重试策略为：备库过了slave-net-timeout秒还没有收到主库来的数据，它就会开始第一次重试。然后每过 master-connect-retry 秒，备库会再次尝试重连主库。直到重试了 master-retry-count 次，它才会放弃重试。如果重试的过程中，连上了主库，那么它认为当前主库是好的，又会开始 slave-net-timeout 秒的等待。

slave-net-timeout 的默认值是 60 秒， master-connect-retry 默认为 60 秒， master-retry-count 默认为 86400次。也就是说，如果主库一分钟都没有任何数据变更发送过来，备库才会尝试重连主库。

如果主库上变更比较频繁，可以考虑将 slave-net-timeout 设置的小一点，避免主库Binlog dump(IO)线程终止，无法将最新的更新推送过来，及时发现问题而不是等到超时之后才收到报错去处理。

当然 slave-net-timeout 设置的过小也有问题，这样会导致如果主库的变更确实比较少的时候，备库频繁的重新连接主库，造成资源浪费。

View Code

3.11：sync_binlog在MySQL5.7.7之后，默认值改成了1，更安全。因为MySQL5.6支持了组提交的功能，所以值1不像5.6之前的说的binlog提交一次就写一次磁盘，而是表了在把binlog刷新到磁盘前，提交的组的数量。

...

特性移除：

3.1：show engine innodb status打印到error log中；通过information_schema中INNODB_SYS%开头的表可以把innodb_table_monitor的信息显示出来，对比说明下他们的差异，方便自己查阅。

####通过innodb_table_monitor打印到error log中的信息，关于说明请见innodb_table_monitor的介绍TABLE: name jute/jute_vote, id 149, flags 1, columns 8, indexes 1, appr.rows 182198COLUMNS: surveyId: DATA_INT DATA_BINARY_TYPE DATA_NOT_NULLlen 4; userId: DATA_INT DATA_BINARY_TYPE DATA_NOT_NULL len 4; choiceId: DATA_INT DATA_BINARY_TYPE DATA_NOT_NULL len 4; voteTime: DATA_FIXBINARY DATA_BINARY_TYPE DATA_NOT_NULL len 5; comment: DATA_BLOB len 11; DB_ROW_ID: DATA_SYS prtype 256 len 6; DB_TRX_ID: DATA_SYS prtype 257 len 6; DB_ROLL_PTR: DATA_SYS prtype 258 len 7;INDEX: name PRIMARY, id 324, fields 2/7, uniq 2, type 3root page3, appr.key vals 182198, leaf pages 472, size pages 545FIELDS: surveyId userId DB_TRX_ID DB_ROLL_PTR choiceId voteTime comment

#####通过information_schema中各相关表(7张表)的说明，和上面对比

information_schema12:31:21>select * from INNODB_SYS_TABLES where NAME='jute/jute_vote';+----------+----------------+------+--------+-------+-------------+------------+---------------+

+----------+----------------+------+--------+-------+-------------+------------+---------------+

| 149 | jute/jute_vote | 1 | 8 | 143 | Antelope | Compact | 0 |

+----------+----------------+------+--------+-------+-------------+------------+---------------+

1 row in set (0.00sec)

information_schema12:32:30>select * from INNODB_SYS_DATAFILES where SPACE=143;+-------+----------------------+

| SPACE | PATH |

+-------+----------------------+

| 143 | ./jute/jute_vote.ibd |

+-------+----------------------+

1 row in set (0.00sec)

information_schema12:32:44>select * from INNODB_SYS_TABLESPACES where SPACE=143;+-------+----------------+------+-------------+----------------------+-----------+---------------+

+-------+----------------+------+-------------+----------------------+-----------+---------------+

| 143 | jute/jute_vote | 0 | Antelope | Compact or Redundant | 16384 | 0 |

+-------+----------------+------+-------------+----------------------+-----------+---------------+

1 row in set (0.01sec)

information_schema12:32:55>select * from INNODB_SYS_TABLESTATS where table_id=149;+----------+----------------+-------------------+----------+------------------+------------------+------------------+---------+-----------+

+----------+----------------+-------------------+----------+------------------+------------------+------------------+---------+-----------+

| 149 | jute/jute_vote | Initialized | 182198 | 545 | 0 | 0 | 0 | 1 |

+----------+----------------+-------------------+----------+------------------+------------------+------------------+---------+-----------+

1 row in set (0.01sec)

information_schema12:38:33>select * from INNODB_SYS_INDEXES where TABLE_ID=149;+----------+---------+----------+------+----------+---------+-------+

+----------+---------+----------+------+----------+---------+-------+

| 324 | PRIMARY | 149 | 3 | 2 | 3 | 143 |

+----------+---------+----------+------+----------+---------+-------+

1 row in set (0.01sec)

information_schema12:33:25>select * from INNODB_SYS_COLUMNS where TABLE_ID=149;+----------+----------+-----+-------+---------+-----+

+----------+----------+-----+-------+---------+-----+

| 149 | surveyId | 0 | 6 | 1283 | 4 |

| 149 | userId | 1 | 6 | 1283 | 4 |

| 149 | choiceId | 2 | 6 | 1283 | 4 |

| 149 | voteTime | 3 | 3 | 525580 | 5 |

| 149 | comment | 4 | 5 | 2949372 | 11 |

+----------+----------+-----+-------+---------+-----+

5 rows in set (0.01sec)

information_schema12:33:37>select * from INNODB_SYS_FIELDS where INDEX_ID in (324);+----------+----------+-----+

| INDEX_ID | NAME | POS |

+----------+----------+-----+

| 324 | surveyId | 0 |

| 324 | userId | 1 |

+----------+----------+-----+

2 rows in set (0.00 sec)

View Code

也可以通过一条sql进行对innodb_table_monitor的展示，里面各参数的意义看官方文档：

SELECTa.PATH datafile,b.NAME name,b.TABLE_ID table_id,b.FLAG flags,b.N_COLS columns,count(distinct c.INDEX_ID) indexes,d.NUM_ROWS `appr.rows`,group_concat(distinct e.NAME) column_name,substring_index(group_concat(e.LEN),',',b.N_COLS-3) column_len,c.NAME index_name,c.INDEX_ID index_id,group_concat(distinctg.NAME) index_fields,d.CLUST_INDEX_SIZE,d.OTHER_INDEX_SIZE,f.PAGE_SIZE,b.FILE_FORMAT,b.ROW_FORMATFROMINNODB_SYS_TABLES b,INNODB_SYS_DATAFILES a,INNODB_SYS_INDEXES c,INNODB_SYS_TABLESTATS d,INNODB_SYS_COLUMNS e,INNODB_SYS_TABLESPACES f,INNODB_SYS_FIELDS gWHEREa.SPACE=b.SPACE and b.TABLE_ID=c.TABLE_ID and b.TABLE_ID=d.TABLE_ID and b.TABLE_ID=e.TABLE_ID and b.SPACE=f.SPACE and c.INDEX_ID=g.INDEX_ID and b. NAME='jute/jute_vote'

GROUP BYc.TABLE_ID,c.INDEX_ID;

效果如下：

*************************** 1. row ***************************datafile: ./jute/jute_vote.ibd

name: jute/jute_vote

table_id:149###表id

flags:1columns:8 ###表只有5列，为什么显示8列？因为包含了隐藏列：DB_ROW_ID(6)、DB_TRX_ID(6)、DB_ROLL_PTR(7)

indexes:1appr.rows:182198###表行的估算值

column_name: surveyId,choiceId,voteTime,userId,comment ###表列

column_len:4,4,5,4,4###对应表列的长度

index_name:PRIMARY###索引名

index_id:324###索引id

index_fields: surveyId,userId ###索引列

CLUST_INDEX_SIZE:545###聚集索引的页数

OTHER_INDEX_SIZE:0###二级索引的页数，表中没有二级索引

PAGE_SIZE:16384###页的单位，16K

FILE_FORMAT: Antelope ###文件格式

ROW_FORMAT: Compact ####行格式

View Code

从上面看出虽然能用information_schema中的各表展示，但还是少了一些信息，比如隐藏字段和索引包括主键的完整字段。

##老

show profile cpu,block iofor query 2;

##information_schemaSELECT query_id,state,DURATION,CPU_USER,CPU_SYSTEM,BLOCK_OPS_IN,BLOCK_OPS_OUT FROM INFORMATION_SCHEMA.PROFILING WHERE QUERY_ID = 36;

官方文档已经出了说明，这里大致讲下如何通过performance_schema查看，关于performance_schema的说明可以看这里1)setup_actors：配置用户纬度的监控，默认监控所有用户

performance_schema01:40:04>SELECT * FROMsetup_actors;+------+------+------+---------+---------+

+------+------+------+---------+---------+

| % | % | % | YES | YES |

+------+------+------+---------+---------+

默认是监控所有用户的操作，会有一定性能的损耗，所以只需要开启指定用户的即可：

performance_schema01:40:23>UPDATE performance_schema.setup_actors SET ENABLED = 'NO', HISTORY = 'NO' WHERE HOST = '%' AND USER = '%';

Query OK,1 row affected (0.01sec)

Rows matched:1 Changed: 1 Warnings: 0performance_schema01:40:40>SELECT * FROMsetup_actors;+------+------+------+---------+---------+

+------+------+------+---------+---------+

| % | % | % | NO | NO |

+------+------+------+---------+---------+

1 row in set (0.17sec)

##开启对dba用户的监控：

performance_schema01:40:42>INSERT INTO performance_schema.setup_actors (HOST,USER,ROLE,ENABLED,HISTORY) VALUES('192.168.100.%','dba','%','YES','YES');

performance_schema01:43:08>SELECT * FROMsetup_actors;+---------------+------+------+---------+---------+

+---------------+------+------+---------+---------+

| % | % | % | NO | NO |

| 192.168.100.% | dba | % | YES | YES |

+---------------+------+------+---------+---------+

2)打开所有需要监控的选项：

performance_schema01:51:35>UPDATE performance_schema.setup_instruments SET ENABLED = 'YES', TIMED = 'YES' WHERE NAME LIKE '%statement/%';

performance_schema01:57:01>UPDATE performance_schema.setup_instruments SET ENABLED = 'YES', TIMED = 'YES' WHERE NAME LIKE '%stage/%';

performance_schema01:57:09>UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME LIKE '%events_statements_%';

performance_schema01:57:27>UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME LIKE '%events_stages_%';3)执行需要监控的语句select.....4)查看：

①老的：

performance_schema01:42:06>show profile cpu,block io for query 6;+----------------------+----------+----------+------------+--------------+---------------+

+----------------------+----------+----------+------------+--------------+---------------+

+----------------------+----------+----------+------------+--------------+---------------+

②新的：

先找出EVENT_ID:SELECT EVENT_ID, TRUNCATE(TIMER_WAIT/1000000000000,6) as Duration, SQL_TEXT FROM performance_schema.events_statements_history_long WHERE SQL_TEXT like '%18,19,20,21%';

...

通过上面找到的EVENT_ID再执行：SELECT event_name AS Stage, TRUNCATE(TIMER_WAIT/1000000000000,6) AS Duration FROM performance_schema.events_stages_history_long WHERE NESTING_EVENT_ID=231;+--------------------------------+----------+

| Stage | Duration |

+--------------------------------+----------+

| stage/sql/starting | 0.000213 |

| stage/sql/checking permissions | 0.000009 |

| stage/sql/Opening tables | 0.000049 |

| stage/sql/init | 0.000065 |

| stage/sql/System lock | 0.000016 |

| stage/sql/optimizing | 0.000022 |

| stage/sql/statistics | 0.001060 |

| stage/sql/preparing | 0.000136 |

| stage/sql/executing | 0.000003 |

| stage/sql/Sending data | 1.265452 |

| stage/sql/end | 0.000006 |

| stage/sql/query end | 0.000412 |

| stage/sql/removing tmp table | 0.000011 |

| stage/sql/closing tables | 0.000012 |

| stage/sql/freeing items | 0.000058 |

| stage/sql/logging slow query | 0.000203 |

| stage/sql/cleaning up | 0.000002 |

+--------------------------------+----------+

3.4：采用ALTER USER来为用户修改密码，不建议再使用SET PASSWORD修改密码。

...

4，总结

在官方测试里看到，MySQL5.7在功能、性能、可用性、安全和监控上又提升了很高。如上面介绍的这些，特别是复制方面的改进：多线程、多源、GTID，半同步等都做了很大改进，以及中文分词的支持还有sys schema上面的数据库性能信息状态收集等。后续会详细介绍这几方面的知识，加强对MySQL5.7的认识，本文只是说了一些自己比较关注的，比较详细的请见后续会持续更新说明。

5，参考文档：

mysql 5.7 引擎_MySQL 5.7 学习：功能性能的提升相关推荐

mysql myisam存储引擎_MySQL浅谈MyISAM存储引擎
本文来源于:IT摆渡网---一个IT实时问答系统快速解决你的任何IT问题,无需等待! mysql中用的最多存储引擎就是innodb和myisam.做为Mysql的默认存储引擎,myisam值得我们学习 ...
mysql归档日志满了_MySQL核心知识学习之路（1）
[MySQL]| 总结/Edison Zhou 作为一个后端工程师,想必没有人没用过数据库,跟我一起复习一下MySQL吧,本文是我学习<MySQL实战45讲>的总结笔记的第一篇,总结了My ...
mysql一共有多少引擎_MySQL存储引擎你们知道多少？
MySQL是我们经常使用的数据库处理系统(DBMS),不知小伙伴们有没有注意过其中的"存储引擎"(storage_engine)呢?有时候面试题中也会问道MySQL几种常用的存储引 ...
mysql自定义存储引擎_MySQL存储引擎
最近碰到面试题问到MySQL存储引擎,然后发现自己有点懵...回来后看了相关知识点,希望对以后面试的各位有帮助先看看自己数据库默认当前的存储引擎:输入show variables like '%st ...
mysql 使用不同引擎_mysql 不同引擎的比较
mysql 支持的默认引擎是InnoDB,其他的常用引擎包括MyISAM等,那么他们有什么差别呢. 首先执行 show engines; 来查看数据库当前支持的引擎. 可以看到mysql支持这么多不同 ...
mysql 时序存储引擎_MySQL常见的三种存储引擎
原文链接:https://www.cnblogs.com/yuxiuyan/p/6511837.html 简单来说,存储引擎就是指表的类型以及表在计算机上的存储方式. 存储引擎的概念是MySQL的特点 ...
mysql key value 引擎_mysql集成的key-value引擎-个人翻译
正如上文提到的,我们只是释放出了一个技术预览版.此功能目前只是mysql的一个插件,使用memcached协议. If you would just like to get a brief intro ...
mysql三种引擎_MySQL常见的三种存储引擎
原文连接:https://www.cnblogs.com/yuxiuyan/p/6511837.htmlhtml 简单来讲,存储引擎就是指表的类型以及表在计算机上的存储方式.数据库存储引擎的概念是M ...
mysql的存储引擎_Mysql数据库3种存储引擎有什么区别？
展开全部 MySQL常见的三种存储e68a843231313335323631343130323136353331333366306561引擎为InnoDB.MyISAM和MEMORY.其区别体现在事 ...

mysql 5.7 引擎_MySQL 5.7 学习：功能性能的提升

mysql 5.7 引擎_MySQL 5.7 学习：功能性能的提升相关推荐

最新文章

热门文章