zincooo的博客

mysql5.6之后引入online DDL。好处是在重建表的过程中，允许对表A做增删改操作。增删改查都会造成数据空洞：delete命令其只是把记录的位置，或者数据页标记为了“可复用”。

一般非双1是:

将从库上执行DDL产生的GTID在主库上利用生成一个空事务GTID的方式将这个GTID在主库上生成出来。假设数据库采用了等GTID的方案，现在要对主库的一张大表做DDL，可能会出现什么情况？如果出现这种情况，应该怎么做？表做DDL的时候可能会出现主从延迟，导致等 GTID 的方案可能会导致这部分流量全打到主库，或者全部超时。OFF，然后做DDL，所有从库及备主全做完之后，做主从切换，最后在原来的主库用同样的方式做DDL。需要注意的是如果有MM架构的情况下，承担写职责的主库上的slave需要先停掉.

在GTID模式下设置主从关系的时候，从库执行start slave命令后，主库发现需要的binlog已经被删除掉了，导致主备创建不成功。这种情况下，可以怎么处理呢?

延迟复制的备库是一种特殊的备库，通过 CHANGE MASTER TO MASTER_DELAY=N命令可以指定这个备库持续保持跟主库有N秒的延迟。1.insert语句，将binlog event类型由Write_rows event改成Delete_rows event；3.Update rows的话，binlog里面记录了数据行修改前和修改后的值，对调这两行的位置即可。使用最近的一次全量备份恢复一个临时库，再把这段时间内的日志除了删除操作的应用到库。权限控制、操作规范、sql审计、

MySQL 5.6版本以后提供的performance_schema库，在file_summary_by_event_name。表里统计了每次IO请求的时间。这样判断里面IO的时间即可，但是打开统计会有一定的性能损耗；

LRU old指向的就是old区域的第一个位置，是整个链表的5/8处。一个数据页里面有多条记录，这个数据页会被多次访问到，但由于是顺序扫描，这个数据页第一次被访问和最后一次被访问的时间间隔不会超过1秒，因此还是会被保留在old区域;再继续扫描后续的数据，之前的这个数据页之后也不会再被访问到，于是始终没有机会移到链表头部(也就是young区域)，很快就会被淘汰出去。所以没有不会有太大的影响。2.访问一个新的不存在于当前链表的数据页，这时候依然是淘汰掉最后的数据页，但是新插入的数据页是放在LRU old处。

文章目录如何避免长事务带来的影响？应用开发端：服务端：如何避免长事务带来的影响？应用开发端：使用set autocommit=1；去掉不必要的只读事务；通过SETMAX EXECUTION TIME命令来控制每个语句执行的最长时间服务端：监控 information schema.lnnodb trx表，设置长事务阈值；如果使用的是MVSQL5.6或者更新版本，把innodb_undo_tablespaces设置成2(或更大的值)。如果真的出现大事务导致回滚段过大，这样设置后清理起来更

1.把线程状态设置为KILL CONNECTION（执行show processlist的时候，有一个特别的逻辑:如果一个线程的状态是KILL CONNECTION，就把Command列显示成Killed.）kill [connection] +线程id，这里connection可缺省，表示断开这个线程的连接，当然如果这个线程有语句正在执行，也是要先停止正在执行的语句的。如果查询过程中生成了比较大的临时文件，加上此时文件系统压力大，删除临时文件可能需要等待lO资源，导致耗时较长。2.关掉线程的网络连接。

session A 的第一个查询 由于可重复读事务隔离级别，查询的结果还会是update前的结果 由于mvcc多版本控制 update前的结果是通过回滚得来的。2.查询sys.schema_table_lock_waits（需要设置performance_schema=on）kill id kill掉对应的查询即可。session A 的第二个查询 事务隔离级别是当前读 所以查询结果会读到update后的结果 这里可以直接返回。2.此时可能是flush被其他线程堵塞了 kill掉对应的查询即可。

flush privleges语句本身会用数据表的数据重建一份内存权限数据，所以在权限数据可能存在不致的情况下再使用。注意，在MYSQL里面，用户名(user)+地址(host)才表示一个用户，因此 ua@ip1和 ua@ip2代表的是两个不同的用户。每次需要判断一个用户对一个数据库读写权限的时候，都需要遍历一次acl_dbs数组，根据user、host和db找到匹配的对象，然后根据对象的权限位来判断。跟db权限类似，这两个权限每次grant的时候都会修改数据表，也会同步修改内存中的hash结构。

单行长度太大时，此时只会将排序字段和主键放入sort_buffer排序，最后再回表查出所需的字段。将字段放入sort_buffer(有序数组)做排序，内存不够时会使用磁盘临时文件。group by逻辑正常需要构造一个带唯一索引的临时表，执行代价都是比较高的。

产生幻读的原因是，行锁只能锁住行，但是新插入记录这个动作，要更新的是记录之间的“间隙”。因此，为了解决幻读问题，InnoDB引入新的锁，也就是间隙锁(GapLock).在InnoDB事务中，行锁是在需要的时候才加上的，并且是要等到事务结束时才释放。幻读指的是一个事务在前后两次查询同一个范围的时候，后一次查询看到了前一次查询没有看到的行。坏处：间隙锁的引入，可能会导致同样的语句锁住更大的范围，会影响了并发度。假如有一个表t，六行记录，此时会有七个间隙，都会加锁。2.幻读仅专指“新插入的行”

mysql的优化，对于join的key不是被驱动表b的index，此时会将a的数据读入线程内存join_buffer(无序数组，放不下会分段放)，扫描b将每一行数据读出来与a做比对。在BNL中，由于join_buffer是无序数组，需要总判断次数=a的总行数*b的总行数。优化的目的在于：因为大多数的数据都是按照主键递增顺序插入得到的，所以可以认为，如果按照主键的递增顺序查询的话，对磁盘的读比较接近顺序读，能够提升读性能。join的key不是被驱动表b的index，那么此时a的每一行都需要去b中做全表扫描。

干净页：内存数据写入到磁盘后，内存和磁盘上的数据页内容一致。脏页：内存数据页与磁盘数据页内容不一致。

对于复合索引，满足最左前缀原则:Mysql从左到右的使用索引中的字段，一个查询可以只使用索引中的一部份，但只能是最左侧部分。例如索引是key index (a,b,c). 可以支持a | a,b| a,b,c 3种组合进行查找，但不支持 b,c进行查找。对于其他优化器误判的情况，可以用force index来强行指定索引，也可以通过修改语句来引导优化器，还可以通过增加或者删除索引来绕过这个问题。使用非主键索引查询时，需要先查询非主键所在的树得到主键的值，再查询主键树，这个过程称为回表。

如果该文件，MySQL会重新生成一个新的server_uuid，相同的server_uuid下的事务对应的sequence_id在binlog文件中是递增且连续有序的，他们以集合的方式呈现。GTID的全称是Global Transaction ldentifier，也就是全局事务ID，是一个事务在提交的时候生成的，是这个事务的唯一标识。一主多从的情况下，可以通过GTID自动找点位，而无需像之前那样通过File_name和File_position找点位。这样就可以实现自动failover。

如果Master_Log_File和Relay_Master_Log_File、Read_Master_Log_Pos和Exec_Master_Log_Pos这两组值完全相同，就表示接收到的日志已经同步完成。Relay_Master_Log_File和Exec_Master_Log_Pos，表示的是备库执行的最新位点。Master_Log_File和Read_Master_Log_Pos，表示的是读到的主库的最新位点;Retrieved_Gtid_Set，是备库收到的所有日志的GTID集合。

2. 配置为LOGICAL_CLOCK，表示的就是类似MariaDB的策略并针对并行度做了优化：处于所有执行中的状态不能并行，所有处于redo log prepare状态的事务可以并行（此时已经通过了锁冲突检测）1.事务在备库上执行的时候，不能完全与主库一样并行，要等第一组事务完全执行完成后，第二组事务才能开始执行,系统的吞吐量不够。如果两个事务更新不同的表，它们就可以并行。当然，对于“表上没主键”和“外键约束”的场景，WRITESET策略也是没法并行的，也会暂时退化为单线程模型。

循环复制问题：在A执行update语句时，生成binlog并发送给B，而B同步完成后，也会生成binlog (log-slave-updates设置为on，表示备库会生成binlog)。而当A也是B的备库时，则B也会把binlog发送给A，造成循环复制。1、判断备库的seconds_behind_master值如果小于某个值就继续下一步，否则继续判断；3、判断备库的seconds_behind_master的值，直到变成0。4、readonly对super权限是无效的，同步进程是超级权限。

客户端负责数据存储和读取。

假设一个事务A执行到一半，已经写了一些redolog到buffer中，这时候有另外一个线程的事务B提交，如果innodb_flush_log_at_trx_commit设置的是1，那么按照这个参数的逻辑，事务B要把redolog buffer里的日志全部持久化到磁盘。如果把innodb_flush_log_at_trx_commit设置成1，那么redo log在prepare阶段就要持久化一次,因为有一个崩溃恢复逻辑是要依赖于prepare的redo log，再加上binlog来恢复的。

innodb每个事务有唯一的事务ID(transaction id)，事务开始时申请的，并按顺序严格递增。每次事务更新数据的时候，都会生成一个新的数据版本，并且把transaction id赋值给这个数据版本的事务ID，记为row trx_id。begin/starttransaction 命令并不是一个事务的起点，在执行到它们之后的第一个操作InnoDB表的语句，事务才真正启动。这里的虚线箭头就是undo log（回滚日志）旧版本并不是真实存在的，需要的时候会通过undo log回滚得到。