数据处理
MySQL数据处理主要是数据的查询、删除、添加和修改。
查询
Mysql的查询是指给定一条指定的查询语句。递交给MySQL服务器，MySQL服务器接收到之后，会进行一系列的处理，然后调用存储引擎，查询出最终的数据，返回给客户端。
MySQL服务器在接收到查询语句之后，主要做了四个事情：
- 查询缓存
- 调用解析器
- 调用优化器
- 调用存储引擎
MysqL会先去查询缓存，判断缓存中是否存在，如果不存在，会调用解析器去解析SQL。
解析器会解析SQL，初步判断SQL的预发是否正确，使用的查询信息是否正确，然后会生成一棵解析树。然后预处理器会去验证解析树是否正确，例如使用的表或者列名是否正确，然后转换为语法树。
然后会调用优化器去优化SQL，根据查询条件找出所有能够使用的索引，然后计算所有所有的查询代价以及全表扫描的查询代价，然后选择一个最小代价的查询方式，生成一个查询计划。优化的内容很多，主要是查询的语句优化，查询连接表优化，查询使用的条件优化等。
根据生成的查询计划，调用存储引擎的API，查询数据，如果有需要服务器会判断查询出来的数据是否满足查询条件，然后进行过滤。
删除
删除的时候并不是直接删除，而是会给这条记录加上一个删除的标志，表示该条记录是一个删除的状态，然后再将数据加入到垃圾列表，会有一个后台线程去purge这些删除状态的数据。
删除数据时不能直接删除的一个直接原因是因为这个删除的数据，在MVCC的机制中，可能会继续为一些事务提供服务，如果直接删除，这些使用该数据的事务，会出现脏读的问题。
更新
更新的情况主要分为了两种：可变字段的更新和不可变字段的更新。对于不可变字段的更新，只需要先找出对应的数据，然后对数据进行加锁，然后更新数据的字段即可。对于可变字段的更新，会涉及到空间分配的问题，可能会出现更新后的字段，现有空间无法存放，因此对于可变字段的更新，是需要先删除原有的数据，然后原有数据的位置插入一条新的记录。
如果最后更新放入的位置，页空间不足的时候，会进行页的分裂，将一页分裂成多页，以确保有足够的空间存放数据。
插入
插入的时候会先根据主键ID，找到对应的插入位置，然后将数据放如到插入的位置。如果插入的页面空间大小不够的时候，会涉及到页的分裂。
在使用单个 insert （包括修改）语句的时候，Mysql会自动创建一个事务，insert数据的提交也会满足两阶段提交。
主从复制
Mysql进行主从复制的方式有两种：基于 bin-log文件、pos位置搭配和 GTID的方式（5.6开始支持）两种方式。
基于bin-log 和 pos 的数据同步
当基于binlog和pos 同步数据的时候，MySQL会从指定的binlog和pos的位置开始，读取数据，然后放入到中继日志中。中继日志中保存了从主库同步的数据，从库会从中继日志中读取，并且回放数据，达到同步数据的效果。
基于GTID的数据同步
使用GTID同步数据的时候，当从主库获取到binlog，放入到从库的中继日志中，当从库从中继日志回放数据的时候，会去提取GTID的值，并且判断该GTID是否已经同步。
GTID：全局事务标识。它具有全局唯一性，一个事务对应一个GTID。唯一性不仅限于主服务器，GTID在所有的从服务器上也是唯一的。一个GTID在一个服务器上只执行一次，从而避免重复执行导致数据混乱或主从不一致。
在传统的复制里面，当发生故障需要主从切换时，服务器需要找到binlog和pos点，然后将其设定为新的主节点开启复制。相对来说比较麻烦，也容易出错。在MySQL 5.6里面，MySQL会通过内部机制自动匹配GTID断点，不再寻找binlog和pos点。我们只需要知道主节点的ip，端口，以及账号密码就可以自动复制
GTID的组成部分
GDIT由两部分组成：GTID = source_id:transaction_id。
- source_id：是产生GTID的服务器，即是server_uuid，在第一次启动时生成，并保存到DATADIR/auto.cnf文件里。
- transaction_id是序列号（sequence number），在每台MySQL服务器上都是从1开始自增长的顺序号，是事务的唯一标识。
例如：3E11FA47-71CA-11E1-9E33-C80AA9429562:23 GTID 的集合是一组GTIDs，可以用source_id+transaction_id范围表示，例如：3E11FA47-71CA-11E1-9E33-C80AA9429562:1-5 复杂一点的：如果这组 GTIDs 来自不同的 source_id，各组 source_id 之间用逗号分隔；如果事务序号有多个范围区间，各组范围之间用冒号分隔，例如：3E11FA47-71CA-11E1-9E33-C80AA9429562:23,3E11FA47-71CA-11E1-9E33-C80AA9429562:1-5
GTID如何产生
GTID的生成受GTID_NEXT控制。
在主服务器上，GTID_NEXT默认值是AUTOMATIC，即在每次事务提交时自动生成GTID。它从当前已执行的GTID集合（即gtid_executed）中，找一个大于0的未使用的最小值作为下个事务GTID。同时在实际的更新事务记录之前，将GTID写入到binlog（set GTID_NEXT记录）。 在Slave上，从binlog先读取到主库的GTID(即get GTID_NEXT记录)，而后执行的事务采用该GTID。
GTID的工作原理
GTID在所有主从服务器上都是不重复的。所以所有在从服务器上执行的事务都可以在bnlog找到。一旦一个事务提交了，与拥有相同GTID的后续事务都会被忽略。这样可以保证从服务器不会重复执行同一件事务。
当使用GTID时，从服务器不需要保留任何非本地数据。使用数据都可以从replicate data stream。从DBA和开发者的角度看，从服务器无保留file-offset pairs以决定如何处理主从服务器间的数据流。
GTID的生成和使用由以下几步组成
- 主服务器更新数据时，会在事务前产生GTID，一同记录到binlog日志中。
- binlog传送到从服务器后，被写入到本地的relay log中。从服务器读取GTID，并将其设定为自己的GTID（GTID_NEXT系统）。
- sql线程从relay log中获取GTID，然后对比从服务器端的binlog是否有记录。
- 如果有记录，说明该GTID的事务已经执行，从服务器会忽略。
- 如果没有记录，从服务器就会从relay log中执行该GTID的事务，并记录到binlog
和传统方式的对比
- 更简单的实现failover，不用以前那样在需要找log_file和log_Pos。
- 更简单的搭建主从复制。
- 比传统复制更加安全。
- GTID是连续没有空洞的，因此主从库出现数据冲突时，可以用添加空事物的方式进行跳过。
