skylar2的博客

隐式字符编码转换，比如：t1的字符集是utf8mb4，t2的字符集是utf8；长事务会导致undo log很大，innodb_undo_tablespaces = 2（2个独立的表空间文件）， 方便回滚清理。读（select …查询语句定义的虚拟表，相当于持久化的查询语句别名。如果调用时函数作用在参数上就不影响索引选择，但函数作用在列上，就会导致索引失效。时只是做了记录，到执行第一条读写语句时才真正开启事务，分发事务ID。innodb引擎是索引组织表（B+树），memory引擎是堆组织表（数组）

在start slave之前，先执行change replication filter replicate_do_table=(tbl_name)，让临时库只同步误操作的表；如果时间过了太久，线上备库没有完整的binlog，我们可以把缺的binlog从binlog备份中找到塞到线上备库里，然后建立主备关系。注意：mysqldump是单线程的、而且回放binlog时不仅只回放这个表而是全部，所以会比较慢。在从binlog中取出0点后的日志，应用误删数据前的日志和误删数据后（找对应的GTID）的日志。

后来引入online DDL：插入临时表时，记录操作日志到row log中，重建表完成后重放，此时重建表是在引擎层（inplace）完成的 // 不需要重建整个表，二十在原表数据文件上直接修改。为了防止数据丢失：sync_binlog=1，innodb_flush_log_at_trx_commit=1 事务提交立即写盘（redo log与binlog 配置 “双1”）。0关闭，SSD（固态硬盘）不用开，因为SSD刷的快，不开可以减少sql语句执行等待的时间。共享空间中，即使删表，空间也不会回收。

id=10, auto_increment=11，如果这时删除id=10的数据，auto_increment=11，如果此时插入数据，新数据的id=11(// 注意：表中id不是连续的)；select不像insert…用完会重置到0，但mysql分配线程ID时加了逻辑限制要求唯一：重置0之后，mysql会遍历thread_id_counter，直至找到一个没有被正在用的thread_id，分配给新线程。也有步长是2的情况，比如双主的主备结构，一个机器的自增ID用奇数，一个机器的自增ID用偶数，步长都是2。

由于join buffer优化，导致被驱动表被多次扫描，就算lru 有young区、old区，热数据也有被顶掉的风险。所以慎用BLJ，最好在被驱动表上建索引，如果仅临时操作一次，建索引比较浪费，可以考虑使用临时表。按照MMR的思路，NLJ本来是从t1一条一条取数据去t2 a索引上找的，我们可以每次多取点（看join buffer的大小）到join buffer上排个序再一起MRR，去a索引上找。增加old区，因为全表扫描的冷数据不会变频繁访问，所以一般就在old区，对young区正常业务的缓存影响减小。

同时，控制binlog_group_commit_sync_delay、binlog_group_commit_sync_no_delay_count 多攒点binlog一起提交，通过延迟，增加并发量。两个主节点，你复制我的日志，我复制你的日志，但怎么区分出来我复制你的日志是你执行了的的新日志，不是我传给你的我的日志呢（我不需要复制我的日志，循环复制）不过有个问题：一组事务这个粒度很大，而且同时只有一组事务committing完成在从库复制，要等这组复制完再进行下一组的复制，有空白期，并发能力不够。

一主多从，主库A挂了，找出新的主库B后就要同步位点。因为原来节点B也是A的从库，本地记录的A的位点。但相同的日志，A的位点和B的位点是不同的。比如：延迟从库被选为新主库，就会在主库删除数据宕机后，其他库的数据比延迟从库多，就会报错停下来需要人工处理，判断一下是误删还是正常删除再恢复主从关系。如果B在算差值时，发现有从库需要的日志但在B上没有，认为有问题，直接返回错误：Slave has more GTIDs than the master。一主多从，主库A挂了，找出新的主库B后就要同步数据(主从切换)。

针对方案二，随机取三个字段就是：随机个最大、最小行数（N最小，M最小，R中间），取出limit N, M-N+1这些行，在里面拿出这三行数据。sort buffer大小（sort_buffer_size)不够，就需要存到磁盘上，存在多个文件中，多个文件分别完成排序后再进行归并排序。对于只需要几个返回值，不需要全量排序，innodb使用优先队列算法，扫描所有数据和堆上的数据对比，堆上只放最大的三个。问题：主键ID不连续，可能有空洞。而且随机概率不平均，比如ID排布 1，2，3，8，9，4000，40001。

change buffer主要节省的是写操作时需要随机读磁盘的IO消耗，redo log主要节省的是写时需要随机写磁盘的IO消耗（转为顺序写）。唯一索引找到就返回，普通索引找到下一个不满足的就返回，所以普通索引比唯一索引查找次数的多。当name，age都需要独立索引，还需要联合索引时，推荐创建age单独索引，(name, age)联合索引。二级索引的叶子节点上存这主键索引，主键索引越小（比如int < varchar），二级索引的检索效率越好。原则：尽可能少的创建索引，索引（数据块*）的大小尽可能小。

同时当前线程也只能读t1，不能写t1，可以写t2;执行alter table t add c int写操作前，判断前面是否有长事务（大查询），选择一：等待长事务执行完成；此时，整个表不能读写，等待sessionA、sessionB的完成；如果需要写热点表，虽然数据量不大，但请求频繁，需要设置任务超时时间，改不了也不要影响其他语句，等有空再改；超时时间不好设置，太短容易误伤业务，太长也不好，都等待很长时间，都没执行 //mysql中的锁：全局锁，表锁、元数据锁（MDL），行锁、间隙锁等。

write_pos是当前记录的位置，write_pos到check_point的绿色部分还能写入，其余位置是新的写入。复用连接的问题（长连接问题）：连接在断开时才会释放占用资源，而不是用完就释放；在流程图的时机B崩溃：redo log处于prepare状态，写入binlog完成：服务重新启动时，认为事务提交成功，回放事务，将redo log prepare状态改为commit。在流程图的时机A崩溃：redo log处于prepare状态，未写入binlog: 服务重新启动时，认为事务提交失败，回滚事务。