mysql全局表分库同一事务_GitHub - icandiio/mysqlsplit: mysql 分库分表, 分布式事务

mysqlsplit

mysql 分库分表

基本分库分表:

1:分库分表

2:分库表冗余

3:分区表

分布式事务

1:XA分布式事务

2:TCC分布式事务

3:消息分布式事务

Mycat分片规则

Mycat读写分离

Mycat故障切换

Mycat+Percona+Haproxy+keepalived

Zookeeper搭建Mycat高可用集群

Mycat注解技术

Mycat性能监控

Mycat架构剖析

1) Mycat线程架构

2) Mycat网络IO架构

3) Mycat内存还礼与缓存架构

5) Mycat连接池 主从切换

Mycat核心技术

1)Mycat路由的实现

2)Mycat跨库join的实现

3)Mycat数据汇聚和排序

Mysql复制的工作方式

Mysql查询执行路径

什么限制了Mysql的性能

最常见的两个瓶颈：

1)CPU

当数据存储全部存储在内存中，CPU会成为瓶颈

2)IO资源

一般发生在工作所需的数据远远超过有效内存容量的时候

硬件性能的优化

1)低延时

更快的CPU

2)高吞吐

更多的CPU个数,要取决于Mysql版本，不同版本使用CPU的个数是有极限的

Mysql复制也能在高速CPU下工作非常快，而多CPU对复制帮助却不大，主库上的并发任务传递到备库以后会被简化为串行任务，也就是是备库的瓶颈通常是IO子系统，而不是CPU

在硬件层面，一个查询可以再执行或者等待，处于等待状态的原因是在运行队列中等待，等待磁盘，等待网络，等待闩(Latch)或者锁(Lock),

1)如果等待闩或者锁，通常需要更快的CPU

2)如果在运行队列中等待，那么更多或者更快的CPU都可能有帮助

1)Cpu架构 CPU核心

Mysql的扩展模式是指它可以有效利用CPU的数量，以及在压力不断增长的情况下如何扩展，这同时取决于工作负载和系统架构，CPU架构(RISC,CISC,流水线深度)，CPU型号，操作系统都影响Mysql的扩展模式

现代CPU的复杂之处：

1)频率调整

2)boost技术

2)平衡内存和硬盘资源

配置大量内存的最大原因其实不是因为可以在内存中保存大量的数据：

1)最终目的是避免磁盘I/O，因为磁盘I/O比在内存中访问数据要慢的多

2)关键是要平衡内存和磁盘的大小。速度，成本和其他因素。

随机I/O，顺序I/O

顺序操作的执行速度比随机I/O的操作快，无论是在内存还是在硬盘

存储引擎执行顺序读比随机读快

缓存的写入延迟特性：

1)多次写入，一次刷新

2)I/O合并

预写日志(WAL)策略：采用在内存中变更页面，而不马上刷新到磁盘的策略，后续时机再刷新到磁盘

缓存命中率实际上也会决定使用多少CPU，所以评估缓存命中率的最好方法是查看CPU的利用率，若CPU使用了99%的时间工作，1%的时间等待，那么缓存的命中率还是不错的。

1)闪存，

2)固态硬盘，

3)PCIE存储设备

3)RAID性能优化,SAN/NAS

SAN和NAS是两个外部文件存储设备加载到服务器的方法

SAN基于块访问，使得所有服务器的硬盘像访问一块硬盘

NAS基于文件的协议来访问

6)操作系统 文件系统 磁盘调度策略

线程 内存交换区

操作系统选择：

Linux发行版，最好的策略是使用专为服务器应用程序设计的发行版，而不是桌面版本。

文件系统：

通常建议使用XFS文件系统

选择磁盘调度策略

内存交换区

监控操作系统的工具：

vmstat iostat

7)复制

1)基于语句的复制

2)基于行的复制

基于行的复制和基于语句的复制都是通过在主库上记录二进制日志，在备库中重放日志的方式实现异步的数据复制

低版本的Mysql不能作为高版本Mysql的备库，而高版本的Mysql可以作为低版本Mysql的备库，Mysql具有向后兼容性，高版本的Mysql可以兼容低版本的Mysql

复制的三步骤

1)主库把数据更改记录到二进制文件(Binary log)中

在每次准备提交事务完成数据更新前，主库将数据更新的事件记录到二进制文件中，Mysql会按照事务提交的顺序而非每条语句执行的顺序记录二进制日志记录完二进

制日志后，主库会告诉粗怒触引擎可以提交事务了。

2)备库将主库上的日志复制到自己的中继日志(relay Log)中

备库会启动一个工作线程，成为I/O线程，I/O线程跟主库建立一个普通的客户端连接，然后在主库上启动一个特殊的二进制转储线程，这个二进制转储线程会

读取主库上二进制日志中的时间，它不会对事件进行轮训。如果该线程追上了主库，它将进入休眠状态，备库I/O线程会将接收到的事件记录到中继日志中。

3)备库读取中继日志中的时间，将其重放到备库数据之上

5)复制事件

6) 复制问题

1)数据损坏与丢失

1)主库意外关闭

2)备库意外关闭

3)主库上的二进制文件意外损坏

5)备库上的中继日志损坏

6)二进制日志与InnoDB事务日志不同步

2)使用非事务性表

3)不确定语句

5)主库备库使用不同的存储引擎

6)不唯一的服务器ID

7)丢失的零时表

8)Innodb加锁读引起的锁争议

9)过大的复制延迟

10)来自主库过大的包

11)受限的复制带宽

12)备库发生数据改变

13) Mysql复制的高级特性

8)复制拓补结构

1)一主多备

2)主动模式下的主主复制，被动模式下的主主复制

3)环形复制

5)其他复制方案

9)分区表、视图 外键约束 游标 全文索引 查询缓存

分区表是一个独立的逻辑表，底层由多个物理子表组成，创建表时通过partion by子句定义

Mysql实现分区表的方式是对底层的疯转，意味着索引也是按照分区的字表定义的，而没有全局索引Mysql在创建表的时候使用PARTION BY子句定义每个分区存放的数据。在执行查询的时候，优化器会根据分区定义过滤那些没有我们需要数据的分区，这样查询就无需扫描所有分区。分区的一个主要目的是将数据按照一个较粗的粒度分在不同的表中，这样做可以将相关的数据存放在一起，另外，如果想一次批量删除整个分区的数据也会变得方便。

使用场景

1)表非常大以至于无法全部放入内存中，或者只有表的最后部分是热点数据，其他均是历史数据

2)分区表的数据更容易维护。

3)分区表的数据可以分布在不同的物理设备上，从而高效的利用各种物理设备

5)可以使用分区表来避免某些特殊的瓶颈，例如InnoDB的单个索引的互斥访问

6)如果需要，还可以备份和恢复独立的分区，这在数据量非常大的数据集的场景下效果非常好。

一个表最多只能有1024个分区

分区表中无法使用外键约束

分区表的原理：

Select查询时，分区表先打开并锁住所有的底层表了，优化器先判断是否可以顾虑掉部分分区，然后再调用存储引擎接口访问各个分区的数据

Insert操作，分区层先打开并锁住所有的底层表，然后确定那个分区接收这个记录，再将记录写入对应的底层表

Delete操作，当删除一条记录时，分区层先打开并锁住所有的底层表，然后确定数据对应的分区，最后对相应的底层表进行删除操作

视图：

视图本身是一个虚拟表，不存放任何数据。在使用SQL语句访问视图时候，它返回的数据是Mysql从其他表中生成的。不能对视图创建触发器，也不能使用DROP TABLE命令删除视图