【MySQL调优、分库分表、读写分离、高可用】

文章目录

mysql调优

第一步，从初期的一个需求规划，也就是对表的设计就开始了，我们在设计表的时候，尽量减少单行数据的大小，字段的宽度设得尽可能小，尽可能不用text、Blob、Clob等类型，它会增加存储空间的占用，读取速度较慢。能用数字型字段就不要设计为字符型，因为字符型锁占的存储空间更大，比如，性别这个字段不用男女进行存储，改为0/1的方式，这样不仅可以控制数据量的大小，增加了同一高度下的B+树容纳的数据量，还能提高检索速度。尽量使用varchar/nvarchar代替char/nchar，因为变长字段空间小，可以节省存储空间。不在数据库中存储图片、文件等大数据，可以通过第三方云存储，存放图片或者文件地址。金额用decimal，注意长度和精度。如果存储的数据范围超过decimal的范围，建议将数据拆成整数和小树分开存储。尽可能不要给数据库留null值，尤其是时间、整数等类型，可以在建表的时候就给非空设置。

第二步，就是建索引。

第三步，针对SQL进行调整，在写SQL的时候遵循最左前缀原则，向右匹配直到遇到范围查询（>、<、between、like）就停止匹配，范围列可以用到索引，但是范围列后面的列无法用到索引。like以通配符%开头索引失效会变成全表扫描的操作。如果查询条件中含有函数或表达式，将导致索引失效而进行全表扫描。只要列中包含有 NULL 值都将不会被包含在索引中，复合索引中只要有一列含有 NULL 值，那么这一列对于此复合索引就是无效的。不要使用select *，改用select加字段名称，因为select *走的聚集索引，会进行全表扫描，如果一定要使用select *的话，mysql至少使用5.6版本，这个版本有一个离散读的优化，一个ICP的优化，一个MRR优化。另外在写sql的时候，尽量使用它的一个执行计划，去看我们的索引是不是失效了。

索引失效有这么几种情况，上面也提到过几个，如果条件中有or，即使其中有部分条件带索引也不会使用。对于复合索引，如果不使用前列，后续列也将无法使用。like以%开头。列类型是字符串，那一定要在条件中将数据使用引号引用起来，否则不使用索引。where中索引列有运算，有函数的，不使用索引。如果mysql觉得全表扫描更快的时候，数据少的情况下，不使用索引。

第四步，随着数据量的增涨之后，会考虑一个数据的分区，Partition分区，表分区必须在表建立的时候创建规则，而已经存在的没有创建过表分区规则的表需要重新做导入处理。如果想修改有规则的表分区，只能新增，不要随意删除，删除表分区会造成该表分区内部数据也一起被删除掉。除此之外，分区也需要结合实际场景进行分区，而且Partition分区也是有一个局限性，因为单台的mysql服务器支持1024个分区，一旦达到这个分区上限，考虑垂直拆分和水平拆分了。垂直分区，它是将单表变多表，这样也是有些优点的，一条数据存储的数据量越小，三层b+所容纳的数据量是更多的，这样一个分区就可以承载多个数据，多个分区它承载的数据就会更多，这是一个累加的效果，不过也有缺点，就是进行表的垂直划分的时候，还需要考虑它的一个关联性，在进行sql查询的情况下，需要反复测试，考虑它的一个性能问题，最好的结果就是拆分出来的表还是能够支持铁定的业务线。比如一个包含了大text和BLOB列的表，这些text和BLOB列又不经常被访问，这时候就要把这些不经常使用的text和BLOB了划分到另一个分区，在保证它们数据相关性的同时还能提高访问速度。随着数据量持续的增涨，这个时候就需要考虑水平分区了，水平分区有多种模式，Range（范围）模式：允许DBA将数据划分不同范围。比如DBA可以将一个表通过年份划分成三个分区，80年代的数据，90年代的数据以及任何在2000年之后的数据。Hash（哈希）模式允许DBA通过对表的一个或多个列的Hash Key进行计算，最后通过这个Hash码不同数值对应的数据区域进行分区，比如DBA可以建立一个，对表的主键进行分区的表。List（预定义列表）模式：允许系统通过DBA定义列表的值所对应的行数据进行分割。例如：DBA建立了一个横跨三个分区的表，分别根据2004年，2005年，2006年值对应数据。Composite（复合模式），就是多模式的组合使用，在初始化已经进行了Range范围分区的表上，我们可以对其中一个分区再进行hash哈希分区。

第五步，就是冷热备份，对于一些无用的数据，这个时候根据实际的需求，对数据进行一个实时的备份，保证MySQL的数据保持在一个比较稳定的情况。

分库分表

对于分库分表，目前主流的是ShardingSphere，起源于当当网内部的应用框架。
shardingJDBC定位为轻量级 Java 框架，在 Java 的 JDBC 层提供的额外服务。它使⽤客户端直连数据库，以 jar 包形式提供服务，⽆需额外部署和依赖，可理解为增强版的 JDBC 驱动，完全兼容 JDBC 和各种 ORM 框架。

ShardingProxy定位为透明化的数据库代理端，提供封装了数据库⼆进制协议的服务端版本，⽤于完成对异构语⾔的⽀持。⽬前提供 MySQL 和 PostgreSQL 版本，它可以使⽤任何兼容 MySQL/PostgreSQL 协议的访问客⼾端。

ShardingJDBC只是客户端的一个工具包，可以理解为一个特殊的JDBC驱动包，所有分库分表逻辑均由业务方自己控制，所以他的功能相对灵活，支持的数据库也非常多，但是对业务侵入大，需要业务方自己定制所有的分库分表逻辑。而ShardingProxy是一个独立部署的服务，对业务方无侵入，业务方可以像用一个普通的MySQL服务一样进行数据交互，基本上感觉不到后端分库分表逻辑的存在，但是这也意味着功能会比较固定，能够支持的数据库也比较少。这两者各有优劣。

数据分片主要流程

sql解析整体结构

路由引擎

改写引擎

执行引擎

归并引擎

源码流程

分库分表的的分片算法

提供一个分片键和一个分片表达式来制定分片算法

NoneShardingStrategy

• 不分片。这种严格来说不算是一种分片策略了。只是ShardingSphere也提供了这么一个配置。

InlineShardingStrategy

最常用的分片方式

• 配置参数： inline.shardingColumn 分片键；inline.algorithmExpression 分片表达式
• 实现方式： 按照分片表达式来进行分片。

StandardShardingStrategy

只支持单分片键的标准分片策略。

• 配置参数：standard.sharding-column 分片键；standard.precise-algorithm-class-name 精确分片算法类名；standard.range-algorithm-class-name 范围分片算法类名
• 实现方式：shardingColumn指定分片算法。preciseAlgorithmClassName 指向一个实现了io.shardingsphere.api.algorithm.sharding.standard.PreciseShardingAlgorithm接口的java类名，提供按照 = 或者 IN 逻辑的精确分片 示例：com.roy.shardingDemo.algorithm.MyPreciseShardingAlgorithm。rangeAlgorithmClassName 指向一个实现了 io.shardingsphere.api.algorithm.sharding.standard.RangeShardingAlgorithm接口的java类名，提供按照Between 条件进行的范围分片。示例：com.roy.shardingDemo.algorithm.MyRangeShardingAlgorithm
• 说明： 其中精确分片算法是必须提供的，而范围分片算法则是可选的。

ComplexShardingStrategy

支持多分片键的复杂分片策略。

• 配置参数：complex.sharding-columns 分片键(多个); complex.algorithm-class-name 分片算法实现类。
• 实现方式：shardingColumn指定多个分片列。algorithmClassName指向一个实现了org.apache.shardingsphere.api.sharding.complex.ComplexKeysShardingAlgorithm接口的java类名。提供按照多个分片列进行综合分片的算法。示例：com.roy.shardingDemo.algorithm.MyComplexKeysShardingAlgorithm

HintShardingStrategy

不需要分片键的强制分片策略。这个分片策略，简单来理解就是说，他的分片键不再跟SQL语句相关联，而是用程序另行指定。对于一些复杂的情况，例如select count(*) from (select userid from t_user where userid in (1,3,5,7,9)) 这样的SQL语句，就没法通过SQL语句来指定一个分片键。这个时候就可以通过程序，给他另行执行一个分片键，例如在按userid奇偶分片的策略下，可以指定1作为分片键，然后自行指定他的分片策略。

• 配置参数：hint.algorithm-class-name 分片算法实现类。
• 实现方式：algorithmClassName指向一个实现了org.apache.shardingsphere.api.sharding.hint.HintShardingAlgorithm接口的java类名。 示例：com.roy.shardingDemo.algorithm.MyHintShardingAlgorithm。在这个算法类中，同样是需要分片键的。而分片键的指定是通过HintManager.addDatabaseShardingValue方法(分库)和HintManager.addTableShardingValue(分表)来指定。使用时要注意，这个分片键是线程隔离的，只在当前线程有效，所以通常建议使用之后立即关闭，或者用try资源方式打开。

而Hint分片策略并没有完全按照SQL解析树来构建分片策略，是绕开了SQL解析的，所有对某些比较复杂的语句，Hint分片策略性能有可能会比较好(情况太多了，无法一一分析)。
但是要注意，Hint强制路由在使用时有非常多的限制：
– 不支持UNION SELECT * FROM t_order1 UNION SELECT * FROM t_order2 INSERT INTO tbl_name (col1, col2, …) SELECT col1, col2, … FROM tbl_name WHERE col3 = ?
– 不支持多层子查询 SELECT COUNT(*) FROM (SELECT * FROM t_order o WHERE o.id IN (SELECT id FROM t_order WHERE status = ?))
– 不支持函数计算。ShardingSphere只能通过SQL字面提取用于分片的值 SELECT * FROM t_order WHERE to_date(create_time, ‘yyyy-mm-dd’) = ‘2019-01-01’;

从这里也能看出，即便有了ShardingSphere框架，分库分表后对于SQL语句的支持依然是非常脆弱的。

分库分表带来的问题

​ 1、分库分表，其实围绕的都是一个核心问题，就是单机数据库容量的问题。我们要了解，在面对这个问题时，解决方案是很多的，并不止分库分表这一种。但是ShardingSphere的这种分库分表，是希望在软件层面对硬件资源进行管理，从而便于对数据库的横向扩展，这无疑是成本很小的一种方式。

​ 2、一般情况下，如果单机数据库容量撑不住了，应先从缓存技术着手降低对数据库的访问压力。如果缓存使用过后，数据库访问量还是非常大，可以考虑数据库读写分离策略。如果数据库压力依然非常大，且业务数据持续增长无法估量，最后才考虑分库分表，单表拆分数据应控制在1000万以内。

​ 当然，随着互联网技术的不断发展，处理海量数据的选择也越来越多。在实际进行系统设计时，最好是用MySQL数据库只用来存储关系性较强的热点数据，而对海量数据采取另外的一些分布式存储产品。例如PostGreSQL、VoltDB甚至HBase、Hive、ES等这些大数据组件来存储。

​ 3、从ShardingJDBC的分片算法中我们可以看到，由于SQL语句的功能实在太多太全面了，所以分库分表后，对SQL语句的支持，其实是步步为艰的，稍不小心，就会造成SQL语句不支持、业务数据混乱等很多很多问题。所以，实际使用时，我们会建议这个分库分表，能不用就尽量不要用。

​ 如果要使用优先在OLTP场景下使用，优先解决大量数据下的查询速度问题。而在OLAP场景中，通常涉及到非常多复杂的SQL，分库分表的限制就会更加明显。当然，这也是ShardingSphere以后改进的一个方向。

​ 4、如果确定要使用分库分表，就应该在系统设计之初开始对业务数据的耦合程度和使用情况进行考量，尽量控制业务SQL语句的使用范围，将数据库往简单的增删改查的数据存储层方向进行弱化。并首先详细规划垂直拆分的策略，使数据层架构清晰明了。而至于水平拆分，会给后期带来非常非常多的数据问题，所以应该谨慎、谨慎再谨慎。一般也就在日志表、操作记录表等很少的一些边缘场景才偶尔用用。

读写分离

为了保证数据一致，通常会需要保证数据只在主服务上写，而从服务只进行数据读取。这个功能就是读写分离。mysql主从本身是无法提供读写分离的服务的，需要由业务自己来实现，这也是ShardingSphere的一个重要功能。

在MySQL主从架构中，是需要严格限制从服务的数据写入的，一旦从服务有数据写入，就会造成数据不一致。并且从服务在执行事务期间还很容易造成数据同步失败。如果需要限制用户写数据，我们可以在从服务中将read_only参数的值设为1(

set global read_only=1

; )。这样就可以限制用户写入数据。

read_only=1设置的只读模式，不会影响slave同步复制的功能。限定的是普通用户进行数据修改的操作，但不会限定具有super权限的用户的数据修改操作。

如果需要限定super权限的用户写数据，可以设置super_read_only=0。另外如果要想连super权限用户的写操作也禁止，就使用"flush tables with read lock;"，这样设置也会阻止主从同步复制！

mysql数据库集群高可用

使用MySQL自身的功能来搭建的集群，这样的集群，不具备高可用的功能。即如果是MySQL主服务挂了，从服务是没办法自动切换成主服务的。常见的MySQL集群方案有三种: MMM、MHA、MGR。

对主从复制集群中的Master节点进行监控。
自动的对Master进行迁移，通过VIP。
重新配置集群中的其它slave对新的Master进行同步。

MMM

MMM是一套由Perl语言实现的脚本程序，可以对mysql集群进行监控和故障迁移。他需要两个Master，同一时间只有一个Master对外提供服务，可以说是主备模式。​他是通过一个VIP(虚拟IP)的机制来保证集群的高可用。整个集群中，在主节点上会通过一个VIP地址来提供数据读写服务，而当出现故障时，VIP就会从原来的主节点漂移到其他节点，由其他节点提供服务。
优点：

提供了读写VIP的配置，使读写请求都可以达到高可用
工具包相对比较完善，不需要额外的开发脚本
完成故障转移之后可以对MySQL集群进行高可用监控

缺点：

故障简单粗暴，容易丢失事务，建议采用半同步复制方式，减少失败的概率
目前MMM社区已经缺少维护，不支持基于GTID的复制

适用场景：

读写都需要高可用的
基于日志点的复制方式

MHA

由日本人开发的一个基于Perl脚本写的工具。这个工具专门用于监控主库的状态，当发现master节点故障时，会提升其中拥有新数据的slave节点成为新的master节点，在此期间，MHA会通过其他从节点获取额外的信息来避免数据一致性方面的问题。MHA还提供了mater节点的在线切换功能，即按需切换master-slave节点。MHA能够在30秒内实现故障切换，并能在故障切换过程中，最大程度的保证数据一致性。在淘宝内部，也有一个相似的TMHA产品。

MHA是需要单独部署的，分为Manager节点和Node节点，两种节点。其中Manager节点一般是单独部署的一台机器。而Node节点一般是部署在每台MySQL机器上的。 Node节点得通过解析各个MySQL的日志来进行一些操作。

Manager节点会通过探测集群里的Node节点去判断各个Node所在机器上的MySQL运行是否正常，如果发现某个Master故障了，就直接把他的一个Slave提升为Master，然后让其他Slave都挂到新的Master上去，完全透明。

优点：

MHA除了支持日志点的复制还支持GTID的方式
同MMM相比，MHA会尝试从旧的Master中恢复旧的二进制日志，只是未必每次都能成功。如果希望更少的数据丢失场景，建议使用MHA架构。

缺点：

MHA需要自行开发VIP转移脚本。
MHA只监控Master的状态，未监控Slave的状态

MGR

MGR：MySQL Group Replication。 是MySQL官方在5.7.17版本正式推出的一种组复制机制。主要是解决传统异步复制和半同步复制的数据一致性问题。

由若干个节点共同组成一个复制组，一个事务提交后，必须经过超过半数节点的决议并通过后，才可以提交。引入组复制，主要是为了解决传统异步复制和半同步复制可能产生数据不一致的问题。MGR依靠分布式一致性协议(Paxos协议的一个变体)，实现了分布式下数据的最终一致性，提供了真正的数据高可用方案(方案落地后是否可靠还有待商榷)。

支持多主模式，但官方推荐单主模式：
多主模式下，客户端可以随机向MySQL节点写入数据
单主模式下，MGR集群会选出primary节点负责写请求，primary节点与其它节点都可以进行读请求处理.

优点：

基本无延迟，延迟比异步的小很多
支持多写模式，但是目前还不是很成熟
数据的强一致性，可以保证数据事务不丢失

缺点：

仅支持innodb，且每个表必须提供主键。
只能用在GTID模式下，且日志格式为row格式。