CREATE TABLE `user` (`id` INT(11) UNSIGNED NOT NULL AUTO_INCREMENT,`name` VARCHAR(45) COLLATE UTF8MB4_UNICODE_CI NOT NULL,`pwd` VARCHAR(255) COLLATE UTF8MB4_UNICODE_CI NOT NULL,`created_at` INT(8) UNSIGNED NOT NULL,PRIMARY KEY (`id`),KEY `idx_created_at` (`created_at`)
)  ENGINE=INNODB DEFAULT CHARSET=UTF8MB4 COLLATE = UTF8MB4_UNICODE_CI;

插入几条数据，方便之后快乐的玩耍

INSERT INTO `user` (`id`, `name`, `pwd`, `created_at`) VALUES ('1', '牛A', '555', '1559318400');
INSERT INTO `user` (`id`, `name`, `pwd`, `created_at`) VALUES ('2', '牛B', '555', '1559318400');
INSERT INTO `user` (`id`, `name`, `pwd`, `created_at`) VALUES ('3', '牛C', '555', '1573441871');
INSERT INTO `user` (`id`, `name`, `pwd`, `created_at`) VALUES ('4', '牛X', '555', '1558329240');

列出服务器上的二进制日志文件

show binary logs

+------------------+-----------+
| Log_name         | File_size |
+------------------+-----------+
| mysql-bin.000081 |       177 |
| mysql-bin.000082 |       154 |
+------------------+-----------+

MySQL的二进制日志可以说是MySQL最重要的日志了，它记录的是已经提交commit 的各种DML和DDL语句(除了数据查询语句)语句，以事件形式记录，还包含语句所执行的消耗的时间，MySQL的二进制日志是事务安全型的

一般来说开启二进制日志大概会有1%的性能损耗(参见MySQL官方中文手册 5.1.24版)。二进制有两个最重要的使用场景:

其一：主从复制，MySQL Replication在Master端开启binlog，Mster把它的二进制日志传递给slaves来达到master-slave数据一致的目的。

其二：基于时间点的恢复，自然就是数据恢复了，通过使用mysqlbinlog工具来使恢复数据。

二进制日志包括两类文件：二进制日志索引文件（文件名后缀为.index）用于记录所有的二进制文件，二进制日志文件（文件名后缀为.00000*）记录数据库所有的DDL和DML(除了数据查询语句)语句事件

master服务器的二进制日志文件的状态信息

查看master状态，即正在写入的二进制文件一个binlog日志的编号名称，及其最后一个操作事件pos结束点(Position)值

show master status

+------------------+----------+--------------+------------------+-------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000082 |      154 |              |                  |                   |
+------------------+----------+--------------+------------------+-------------------+
1 row in set (0.00 sec)

字段名	解释
File	当前正在写入的binlog文件
Position	当前正在写入的位置
Binlog_Do_DB	只记录指定数据库的二进制文件
Binlog_Ignore_DB	不记录指定数据库的二进制文件
Executed_Gtid_Set	记录当前执行的GTID，显示在主库上执行全局事务标识符

显示二进制日志中的事件

可以将指定的binlog日志文件，分成有效事件行的方式返回，并可使用limit指定pos点的起始偏移，查询条数

show binlog events [IN 'log_name'] [FROM pos] [LIMIT [offset,] row_count]

mysql> show binlog events in 'mysql-bin.000082'\G
*************************** 1. row ***************************Log_name: mysql-bin.000082Pos: 4Event_type: Format_descServer_id: 1
End_log_pos: 123Info: Server ver: 5.7.21-log, Binlog ver: 4
*************************** 2. row ***************************Log_name: mysql-bin.000082Pos: 123Event_type: Previous_gtidsServer_id: 1
End_log_pos: 154Info:
2 rows in set (0.00 sec)

字段名	解释
Log_name	查询的binlog日志文件名
Pos	在binlog的起始点
Event_type	描述事件类型的标识符 1. `UNKNOWN`：这个事件类型应该永远不会出现。它从不会写入binlog中。如果binlog中的事件没法被识别成其他已知事件的话，就会被标识为UNKNOWN 2. `START`：该事件是写在每个二进制文件开头的一个描述性的事件 3. `QUERY`： (1)事务开始时，在binlog中有一个QUERY_EVENT类型的BEGIN。(2)在statement格式中，具体执行的SQL语句会保存在该事件中。(3)对于ROW格式的binlog，所有DDL操作以文本的形式记录在该事件中。 4. `STOP`：当MySQL数据库停止时，会在当前的binlog末尾添加一个STOP_EVENT事件表示数据库停止 5. `ROTATE`：binlog文件中的最后一个event，记录下一个binlog的信息 6. `INTVAR`：该事件在语句使用了AUTO_INCREMENT 列或者LAST_INSERT_ID()函数时写入，它只会在QUERY_EVENT事件前写入，并且在基于row模式的日志记录中不会出现 7. `LOAD`：执行LOAD DATA INFILE 语句时产生此事件，即从外部文件导入数据 8. `SLAVE`：该事件还未被使用 9. `CREATE_FILE`： 10. `APPEND_BLOCK`： 11. `EXEC_LOAD`： 12. `DELETE_FILE`： 13. `NEW_LOAD`： 14.`RAND`：执行包含RAND()函数的语句产生此事件，此事件没有被用在binlog_format为ROW模式的情况下 15.`USER_VAR`：执行包含了用户变量的语句产生此事件，此事件没有被用在binlog_format为ROW模式的情况下 16.`FORMAT_DESCRIPTION`：binlog文件的第一个event，记录版本号等元数据信息 17. `XID`：二阶段提交xid记录。在事务提交时，不管是STATEMENT还是ROW格式的binlog，都会在末尾添加一个XID_EVENT事件代表事务的结束。该事件记录了该事务的ID，在MySQL进行崩溃恢复时，根据事务在binlog中的提交情况来决定是否提交存储引擎中状态为prepared的事务 18. `BEGIN_LOAD_QUERY`： 19. `EXECUTE_LOAD_QUERY`： 20. `TABLE_MAP`：row模式下记录表源数据，对读取行记录提供规则参考< 21.`INCIDENT`：该事件在主库中发生异常，提醒从库主库可能发生会导致数据不一致的事件 22. `HEARTBEAT`：这个事件是由master发给slave的，让slave知道master还活着。这类事件不会再binlog或relay log中出现。他们由master的dump事件线程产生，然后直接发给了slave。slave收到后，校验事件内容后，直接抛弃这个事件，而不会写到relay log中 23. `IGNORABLE`： 24. `ROWS_QUERY`：记录原始的 SQL，row格式binlog DML也会记录在Rows_query事件中 25. `WRITE_ROWS`：对应insert操作，包含了要插入的数据 26. `UPDATE_ROWS`：对应update操作，不仅包含了修改后的数据，还包含了修改前的值 27. `DELETE_ROWS`：对应delete操作，仅仅需要指定删除的主 28. `GTID`：事务的GTID值，在启用GTID模式后，MySQL实际上为每个事务都分配了个GTID 29. `ANONYMOUS_GTID`：如果没有开启GTID模式，事件类型会是ANONYMOUS_GTID_EVENT 30. `PREVIOUS_GTIDS`：上一个binlog结束的gtid值
Server_id	标识是由哪台服务器执行的
End_log_pos	在binlog的结束点
Info	执行的sql语句

每个binlog事件都以一个binlog事件头开始，然后是一个binlog事件类型特定的数据部分

GTID即全局事务ID，GTID实际上是由UUID+TID组成的。其中UUID是一个MySQL实例的唯一标识。TID代表了该实例上已经提交的事务数量，并且随着事务提交单调递增，所以GTID能够保证每个MySQL实例事务的执行（不会重复执行同一个事务，并且会补全没有执行的事务）。在启用GTID模式后，MySQL实际上为每个事务都分配了个GTID。

列出了在 table 缓存中当前打开的非临时的表

show open tables

+--------------------+------------------------------------------------------+--------+-------------+
| Database           | Table                                                | In_use | Name_locked |
+--------------------+------------------------------------------------------+--------+-------------+
| performance_schema | events_waits_summary_by_user_by_event_name           |      0 |           0 |
| performance_schema | events_waits_summary_global_by_event_name            |      0 |           0 |
| performance_schema | events_transactions_summary_global_by_event_name     |      0 |           0 |
| performance_schema | replication_connection_status                        |      0 |           0 |
| mysql              | time_zone_leap_second                                |      0 |           0 |
| mysql              | columns_priv                                         |      0 |           0 |
| performance_schema | metadata_locks                                       |      0 |           0 |
| performance_schema | status_by_user                                       |      0 |           0 |
+--------------------+------------------------------------------------------+--------+-------------+

字段名	解释
Database	数据库名称
Table	表名
In_use	表示有多少线程正在使用某张表，有可能已经给这个表上锁，或者等待获得锁
Name_locked	显示表名称是否被锁定，0往往是没有锁定，1为写锁, 写锁基本发生在delete table或rename table时

具体应用：

查看表是否在使用
show open tables where in_use > 0 ;

巨人的肩膀

从他人的工作中汲取经验来避免自己的错误重复，正如我们是站在巨人的肩膀上才能做出更好的成绩。

https://docs.pingcap.com/zh/tidb/stable/mysql-schema
http://www.searchdoc.cn/rdbms/mysql/dev.mysql.com/doc/refman/5.7/en/preface.com.coder114.cn.html
https://www.kancloud.cn/curder/mysql/355287
http://www.jiangxinlingdu.com/mysql/2019/06/07/binlog.html
https://segmentfault.com/a/1190000040042493
https://cloud.tencent.com/developer/article/1508857
https://dev.mysql.com/doc/internals/en/event-meanings.html
https://gitbook.curiouser.top/origin/mysql-binlog.html
https://weikeqin.com/2019/09/05/mysql-lock-table-solution/

VChat

一个没有哆啦A梦和静香的IT码农，不专业Gopher

mysql中高阶玩法系列（八）相关推荐

mysql中高阶玩法系列（六）
目录系统默认数据库巨人的肩膀 VChat 系统默认数据库数据其实可以存储在⽂本⽂件中,但是只适⽤于数据量很少的时候,数据量很少的情况下,在⽂件中保存数据.读写数据,操作简单便利且速度快:但是当数 ...
mysql中高阶玩法系列（七）
目录三种语句结束符查看当前SQL执行状态.是否锁表巨人的肩膀 VChat 先定义一张表,在之后的讲解中的所有例子,都是基于这张表做的演示,那么就定义一张最常见的用户表吧. CREATE TABL ...
mysql中高阶玩法系列（九）
目录显示有关存储引擎的操作信息性能分析 show profiles show profile 实例1 实例2 巨人的肩膀 VChat 先定义一张表,在之后的讲解中的所有例子,都是基于这张表做的演示 ...
pip高阶玩法，让python模块安装飞起来
在学习或者工作中,我们经常在搭建环境时需要下载安装一些库文件,但是pip默认下载使用的源是国外的,因此下载速度会很慢,所以在下载的时候我们可以将源地址换为国内的源,会大大提升下载速度. pip.ini ...
2019支付宝集五福高阶玩法助你快速集齐五福
前几天我们曾介绍过2019支付宝集五福活动正式开启了,从1月25日到2月4日除夕,用户可以在这段时间内收集五福卡,除夕当晚会瓜分现金红包. 只要打开支付宝最新版,就可以在首页看到集五福入口,用户可以通 ...
LeetCode MySQL 1097. 游戏玩法分析 V
文章目录 1. 题目 2. 解题 1. 题目 Activity 活动记录表 +--------------+---------+ | Column Name | Type | +----------- ...
LeetCode MySQL 534. 游戏玩法分析 III
文章目录 1. 题目 2. 解题 1. 题目 Table: Activity +--------------+---------+ | Column Name | Type | +---------- ...
LeetCode MySQL 550. 游戏玩法分析 IV
文章目录 1. 题目 2. 解题 1. 题目 Table: Activity +--------------+---------+ | Column Name | Type | +---------- ...
LeetCode MySQL 512. 游戏玩法分析 II
文章目录 1. 题目 2. 解题 1. 题目 Table: Activity +--------------+---------+ | Column Name | Type | +---------- ...

mysql中高阶玩法系列（八）

目录