【数据库】MySQL锁机制、热备、分表

时间 2019-11-29

标签数据库 mysql 机制分表栏目 SQL 繁體版

原文原文链接

欢迎关注公众号：【爱编码】若是有须要后台回复2019赠送1T的学习资料哦！！html

注：本文大都来自互联网，文字较多，基本是概念，若想深刻了解，还需各位本身找文章研究。前端

表锁和行锁机制

表锁（MyISAM和InnoDB）

表锁的优点：开销小；加锁快；无死锁表锁的劣势：锁粒度大，发生锁冲突的几率高，并发处理能力低加锁的方式：自动加锁。查询操做（SELECT），会自动给涉及的全部表加读锁，更新操做（UPDATE、DELETE、INSERT），会自动给涉及的表加写锁。也能够显示加锁：mysql

共享读锁：lock table tableName read;
独占写锁：lock table tableName write;
批量解锁：unlock tables;
复制代码

什么场景下用表锁

InnoDB默认采用行锁，在未使用索引字段查询时升级为表锁。即使你在条件中使用了索引字段，MySQL会根据自身的执行计划，考虑是否使用索引(因此explain命令中会有possible_key 和 key)。 若是MySQL认为全表扫描效率更高，它就不会使用索引，这种状况下InnoDB将使用表锁，而不是行锁。所以，在分析锁冲突时，别忘了检查SQL的执行计划，以确认是否真正使用了索引。git

第一种状况：全表更新：事务须要更新大部分或所有数据，且表又比较大。若使用行锁，会致使事务执行效率低，从而可能形成其余事务长时间锁等待和更多的锁冲突。github

第二种状况：多表查询：事务涉及多个表，比较复杂的关联查询，极可能引发死锁，形成大量事务回滚。这种状况若能一次性锁定事务涉及的表，从而能够避免死锁、减小数据库因事务回滚带来的开销。sql

行锁（InnoDB的行锁）

行锁的劣势：开销大；加锁慢；会出现死锁数据库

行锁的优点：锁的粒度小，发生锁冲突的几率低；处理并发的能力强后端

加锁的方式：自动加锁。对于UPDATE、DELETE和INSERT语句，InnoDB会自动给涉及数据集加排他锁；对于普通SELECT语句，InnoDB不会加任何锁；固然咱们也能够显示的加锁：bash

共享锁：select * from tableName where … + lock in share more
排他锁：select * from tableName where … + for update
复制代码

行锁优化

1 尽量让全部数据检索都经过索引来完成，避免无索引行或索引失效致使行锁升级为表锁。服务器

2 尽量避免间隙锁带来的性能降低，减小或使用合理的检索范围。

3 尽量减小事务的粒度，好比控制事务大小，而从减小锁定资源量和时间长度，从而减小锁的竞争等，提供性能。

4 尽量低级别事务隔离，隔离级别越高，并发的处理能力越低。

InnoDB和MyISAM的最大不一样点有两个：

一，InnoDB支持事务(transaction)；

二，默认采用行级锁。加锁能够保证事务的一致性，可谓是有人(锁)的地方，就有江湖(事务)；咱们先简单了解一下事务知识。

MySQL 事务

事务是由一组SQL语句组成的逻辑处理单元，事务具备ACID属性。 原子性（Atomicity）：事务是一个原子操做单元。在当时原子是不可分割的最小元素，其对数据的修改，要么所有成功，要么所有都不成功。

一致性（Consistent）：事务开始到结束的时间段内，数据都必须保持一致状态。

隔离性（Isolation）：数据库系统提供必定的隔离机制，保证事务在不受外部并发操做影响的”独立”环境执行。

持久性（Durable）：事务完成后，它对于数据的修改是永久性的，即便出现系统故障也可以保持。

事务隔离级别

脏读，不可重复读，幻读，其实都是数据库读一致性问题，必须由数据库提供必定的事务隔离机制来解决。

双机热备

概念

双机热备

双机热备特指基于高可用系统中的两台服务器的热备（或高可用），因两机高可用在国内使用较多，故得名双机热备。从广义上讲，就是对于重要的服务，使用两台服务器，互相备份，共同执行同一服务。当一台服务器出现故障时，能够由另外一台服务器承担服务任务，从而在不须要人工干预的状况下，自动保证系统能持续提供服务。

双机热备和备份的区别

热备份指的是：High Available（HA）即高可用，而备份指的是Backup,即数据备份的一种，这是两种不一样的概念，应对的产品也是两种功能上彻底不一样的产品。

热备份主要保障业务的连续性，实现的方法是故障点的转移。而备份，主要目的是为了防止数据丢失，而作的一份拷贝，因此备份强调的是数据恢复而不是应用的故障转移。

双机热备分类

按工做中的切换方式分为： 主-备方式（Active-Standby方式）和双主机方式（Active-Active方式）。

主-备方式即指的是一台服务器处于某种业务的激活状态（即Active状态），另外一台服务器处于该业务的备用状态（即Standby状态)。
双主机方式即指两种不一样业务分别在两台服务器上互为主备状态（即Active-Standby和Standby-Active状态）。

mysql 双机热备工做原理

简单的说就是把一个服务器上执行过的sql语句在别的服务器上也重复执行一遍，这样只要两个数据库的初态是同样的，那么它们就能一直同步。固然这种复制和重复都是mysql自动实现的，咱们只须要配置便可。咱们进一步详细介绍原理的细节，这有一张图：

上图中有两个服务器，演示了从一个主服务器（master）把数据同步到从服务器（slave）的过程。这是一个主-从复制的例子。主-主互相复制只是把上面的例子反过来再作一遍。因此咱们以这个例子介绍原理。对于一个mysql服务器，通常有两个线程来负责复制和被复制。当开启复制以后。

1. 做为主服务器Master，会把本身的每一次改动都记录到二进制日志 Binarylog 中。（从服务器会负责来读取这个log，而后在本身那里再执行一遍。）
2. 做为从服务器Slave，会用master上的帐号登录到 master上，读取master的Binarylog, 写入到本身的中继日志 Relaylog，而后本身的sql线程会负责读取这个中继日志，并执行一遍。到这里主服务器上的更改就同步到从服务器上了。在mysql上能够查看当前服务器的主，从状态。其实就是当前服务器的 Binary（做为主服务器角色）状态和位置。以及其RelayLog（做为从服务器）的复制进度。

mysql 双机热备实现

参考下面各位大神的配置吧，他们写得太好了，太详细了。我就收藏一下。

分库分表

基本思想就要把一个数据库切分红多个部分放到不一样的数据库(server)上，从而缓解单一数据库的性能问题。

为何要分库分表

当一张表的数据达到几千万时，你查询一次所花的时间会变多，若是有联合查询的话，我想有可能会死在那儿了。分表的目的就在于此，减少数据库的负担，缩短查询时间。

垂直切分和水平切分

垂直切分

一个数据库由不少表的构成，每一个表对应着不一样的业务，垂直切分是指按照业务将表进行分类，分布到不一样的数据库上面，这样也就将数据或者说压力分担到不一样的库上面

优势：

1. 拆分后业务清晰，拆分规则明确。
    2. 系统之间整合或扩展容易。
    3. 数据维护简单。
复制代码

缺点：

1. 部分业务表没法join，只能经过接口方式解决，提升了系统复杂度。
    2. 受每种业务不一样的限制存在单库性能瓶颈，不易数据扩展跟性能提升。
    3. 事务处理复杂。
复制代码

水平切分

相对于垂直拆分的区别是：垂直拆分是把不一样的表拆到不一样的数据库中，而水平拆分是把同一个表拆到不一样的数据库中。

优势：

1. 不存在单库大数据，高并发的性能瓶颈。
    2. 对应用透明，应用端改造较少。     
    3. 按照合理拆分规则拆分，join操做基本避免跨库。
    4. 提升了系统的稳定性跟负载能力。
复制代码

缺点：

1. 拆分规则难以抽象。
    2. 分片事务一致性难以解决。
    3. 数据屡次扩展难度跟维护量极大。
    4. 跨库join性能较差。
复制代码

小结

两张方式共同缺点

1. 引入分布式事务的问题。
    2. 跨节点Join 的问题。
    3. 跨节点合并排序分页问题。
复制代码

目前主要有两种思路：

A. **客户端模式**，在每一个应用程序模块中配置管理本身须要的一个（或者多个）数据源，直接访问各个 数据库，在模块内完成数据的整合。 
    优势：相对简单，无性能损耗。   
    缺点：不够通用，数据库链接的处理复杂，对业务不够透明，处理复杂。
   B. 经过**中间代理层**来统一管理全部的数据源，后端数据库集群对前端应用程序透明；   
    优势：通用，对应用透明，改造少。   
    缺点：实现难度大，有二次转发性能损失
复制代码

Mycat分库分表

Mycat的架构其实很好理解，Mycat是代理，Mycat后面就是物理数据库。和Web服务器的Nginx相似。对于使用者来讲，访问的都是Mycat，不会接触到后端的数据库。

经常使用的分库分表中间件

简单易用的组件：

强悍重量级的中间件：

具体实现能够参考下面这些文章：

最后

若是对 Java、大数据感兴趣请长按二维码关注一波，我会努力带给大家价值。以为对你哪怕有一丁点帮助的请帮忙点个赞或者转发哦。关注公众号【爱编码】，回复 2019 有相关资料哦。