一、GTID的概念
1、全局事务标识：global transaction identifiers。
2、GTID是一个事务一一对应，并且全局唯一ID。
3、一个GTID在一个服务器上只执行一次，避免重复执行导致数据混乱或者主从不一致。
4、GTID用来代替传统复制方法，不再使用MASTER_LOG_FILE+MASTER_LOG_POS开启复制。而是使用MASTER_AUTO_POSTION=1的方式开始复制。
5、MySQL-5.6.5开始支持的，MySQL-5.6.10后开始完善。
6、在传统的slave端，binlog是不用开启的，但是在GTID中slave端的binlog是必须开启

全部内容

MySQL主从复制中常见的问题以及如何定位和解决问题

一、从库复制延迟问题

1、可能的原因如下
（1）主从服务器处于不同的网络之中，由于网络延迟导致；
（2）主从服务器的硬件配置不同，从服务器的硬件配置（包括内存，CPU，网卡等）远低于主服务器；
（3）主库上有大量的写入操作，导致从库无法实时重放主库上的binlog；
（4）主库上存在着大事务操作或者慢SQL，导致从库在应用主库binlog的过程过慢，形成延迟；
（5）数据库实例的参数配置问题导致，如：从库开启了binlog，或者配置了每次事务都去做刷盘操作；

2、主从同步延迟问题判断
（1）根据从库上的状态参数判断

mysql-ser

全部内容

MySQL半同步配置过程

1、定义
是介于异步复制和全同步复制之间的一种复制方式，主库在执行完客户端提交的事务后不是立刻返回给客户端，而是等待至少一个从库接收到并写到relay log中才返回给客户端。

2、优缺点
（1）优点：有效的提高了数据的安全性，需要等到数据写到从库之后才返回给客户端；
（2）缺点：因为需要等待至少一个从库接收到并写入relaylog中，索引会造成一定的网络延迟，需要在网络延迟较低的环境中使用

3、搭建过程
（1）前提条件：

a、MySQL数据库版本为5.5及以上
b、属性变量have_dynamic_loading的值为YES
c、异步复制已经搭建完成
（2）查

全部内容

Master

（1）从库执行 change master to 语句，会立即将主库信息记录到master.info中
（2）从库执行 start slave语句，会立即生成IO_T和SQL_T
（3）IO_T 读取master.info文件，获取到主库信息
（4）IO_T 连接主库，主库会立即分配一个DUMP_T,进行交互 
（5）IO_T 根据master.info binlog信息，向DUMP_T请求最新的binlog 
（6）主库DUMP_T,经过查询，如果发现有新的，截取并反回给从库IO_T
（7）从库IO_T会收到binlog，存储在TCP/IP缓存中,在网络底层返回ACK
（8）

全部内容

id : 查询序列号。

第一种：id全部相同，sql的执行顺序是由上至下；

第二种：id全部不同，sql的执行顺序是根据id大的优先执行；

第三种：id既存在相同，又存在不同的。先根据id大的优先执行，再根据相同id从上至下的执行。

select_type : 查询类型

simple：简单的select 查询，查询中不包含子查询或者union

primary：查询中若包含任何复杂的子查询，最外层查询则被标记为primary

subquery：在select或where 列表中包含了子查询

derived：在from列表中包含的子查询被标记为derived（衍生）MySQL会递归执行这些子查询，

全部内容

MySQL性能优化：

抛开数据量和并发数，谈性能都是耍流氓。MySQL没有限制单表最大记录数，它取决于操作系统对文件大小的限制。

《阿里巴巴Java开发手册》提出单表行数超过500万行或者单表容量超过2GB，才推荐分库分表。性能由综合因素决定，抛开业务复杂度，影响程度依次是硬件配置、MySQL配置、数据表设计、索引优化。500万这个值仅供参考，并非铁律。

博主曾经操作过超过4亿行数据的单表，分页查询最新的20条记录耗时0.6秒，SQL语句大致是select field_1,field_2 from table where id < #{prePageMinId} order by i

全部内容

MySQL的“utf8mb4”是真正的“UTF-8”。 MySQL的“utf8”是一种“专属的编码”，它能够编码的Unicode字符并不多。

源网址：

https://mp.weixin.qq.com/s?__biz=MzAwNDUxOTQ5MQ==&mid=2247496287&idx=1&sn=62ad536a458c471eac32712d596b9857

全部内容