auto commit
This commit is contained in:
CyC2018
parent
e1b8e49432
commit
f19c8d4515
|
|
@ -33,9 +33,18 @@
|
|||
* [3. 减少返回的行](#3-减少返回的行)
|
||||
* [4. 拆分大的 DELETE 或 INSERT 语句](#4-拆分大的-delete-或-insert-语句)
|
||||
* [分库与分表](#分库与分表)
|
||||
* [1. 分库与分表的原因](#1-分库与分表的原因)
|
||||
* [2. 实现方式](#2-实现方式)
|
||||
* [2.1 垂直切分](#21-垂直切分)
|
||||
* [2.2 水平切分](#22-水平切分)
|
||||
* [2.3 切分的选择](#23-切分的选择)
|
||||
* [3. Merge 存储引擎](#3-merge-存储引擎)
|
||||
* [4. 分库与分表存在的问题](#4-分库与分表存在的问题)
|
||||
* [4.1 事务问题](#41-事务问题)
|
||||
* [4.2 跨库跨表连接问题](#42-跨库跨表连接问题)
|
||||
* [4.3 额外的数据管理负担和数据运算压力](#43-额外的数据管理负担和数据运算压力)
|
||||
* [5. 分表与分区的不同](#5-分表与分区的不同)
|
||||
* [故障转移和故障恢复](#故障转移和故障恢复)
|
||||
* [1. 故障转移](#1-故障转移)
|
||||
* [2. 故障恢复](#2-故障恢复)
|
||||
* [参考资料](#参考资料)
|
||||
<!-- GFM-TOC -->
|
||||
|
||||
|
|
@ -351,72 +360,74 @@ do {
|
|||
|
||||
# 分库与分表
|
||||
|
||||
**1. 分表与分区的不同**
|
||||
|
||||
分表，就是讲一张表分成多个小表，这些小表拥有不同的表名；而分区是将一张表的数据分为多个区块，这些区块可以存储在同一个磁盘上，也可以存储在不同的磁盘上，这种方式下表仍然只有一个。
|
||||
|
||||
**2. 使用分库与分表的原因**
|
||||
## 1. 分库与分表的原因
|
||||
|
||||
随着时间和业务的发展，数据库中的表会越来越多，并且表中的数据量也会越来越大，那么读写操作的开销也会随着增大。
|
||||
|
||||
**3. 垂直切分**
|
||||
## 2. 实现方式
|
||||
|
||||
### 2.1 垂直切分
|
||||
|
||||
将表按功能模块、关系密切程度划分出来，部署到不同的库上。例如，我们会建立商品数据库 payDB、用户数据库 userDB 等，分别用来存储项目与商品有关的表和与用户有关的表。
|
||||
|
||||
**4. 水平切分**
|
||||
### 2.2 水平切分
|
||||
|
||||
把表中的数据按照某种规则存储到多个结构相同的表中，例如按 id 的散列值、性别等进行划分，
|
||||
把表中的数据按照某种规则存储到多个结构相同的表中，例如按 id 的散列值、性别等进行划分。
|
||||
|
||||
**5. 垂直切分与水平切分的选择**
|
||||
### 2.3 切分的选择
|
||||
|
||||
如果数据库中的表太多，并且项目各项业务逻辑清晰，那么垂直切分是首选。
|
||||
|
||||
如果数据库的表不多，但是单表的数据量很大，应该选择水平切分。
|
||||
|
||||
**6. 水平切分的实现方式**
|
||||
## 3. Merge 存储引擎
|
||||
|
||||
最简单的是使用 merge 存储引擎。
|
||||
该存储引擎支持分表。
|
||||
|
||||
**7. 分库与分表存在的问题**
|
||||
## 4. 分库与分表存在的问题
|
||||
|
||||
(1) 事务问题
|
||||
### 4.1 事务问题
|
||||
|
||||
在执行分库分表之后，由于数据存储到了不同的库上，数据库事务管理出现了困难。如果依赖数据库本身的分布式事务管理功能去执行事务，将付出高昂的性能代价；如果由应用程序去协助控制，形成程序逻辑上的事务，又会造成编程方面的负担。
|
||||
|
||||
(2) 跨库跨表连接问题
|
||||
### 4.2 跨库跨表连接问题
|
||||
|
||||
在执行了分库分表之后，难以避免会将原本逻辑关联性很强的数据划分到不同的表、不同的库上。这时，表的连接操作将受到限制，我们无法连接位于不同分库的表，也无法连接分表粒度不同的表，导致原本只需要一次查询就能够完成的业务需要进行多次才能完成。
|
||||
|
||||
### 4.3 额外的数据管理负担和数据运算压力
|
||||
|
||||
最显而易见的就是数据的定位问题和数据的增删改查的重复执行问题，这些都可以通过应用程序解决，但必然引起额外的逻辑运算。
|
||||
|
||||
## 5. 分表与分区的不同
|
||||
|
||||
分表，就是讲一张表分成多个小表，这些小表拥有不同的表名；而分区是将一张表的数据分为多个区块，这些区块可以存储在同一个磁盘上，也可以存储在不同的磁盘上，这种方式下表仍然只有一个。
|
||||
|
||||
# 故障转移和故障恢复
|
||||
|
||||
故障转移也叫做切换，当主库出现故障时就切换到备库，使备库成为主库。故障恢复顾名思义就是从故障中恢复过来，并且保证数据的正确性。
|
||||
|
||||
## 1. 故障转移
|
||||
|
||||
**1.1 提升备库或切换角色**
|
||||
**提升备库或切换角色**
|
||||
|
||||
提升一台备库为主库，或者在一个主-主复制结构中调整主动和被动角色。
|
||||
|
||||
**1.2 虚拟 IP 地址和 IP 托管**
|
||||
**虚拟 IP 地址和 IP 托管**
|
||||
|
||||
为 MySQL 实例指定一个逻辑 IP 地址，当 MySQL 实例失效时，可以将 IP 地址转移到另一台 MySQL 服务器上。
|
||||
|
||||
**1.3 中间件解决方案**
|
||||
**中间件解决方案**
|
||||
|
||||
通过代理，可以路由流量到可以使用的服务器上。
|
||||
|
||||
<div align="center"> <img src="../pics//fabd5fa0-b75e-48d0-9e2c-31471945ceb9.jpg"/> </div><br>
|
||||
|
||||
**1.4 在应用中处理故障转移**
|
||||
**在应用中处理故障转移**
|
||||
|
||||
将故障转移整合到应用中可能导致应用变得太过笨拙。
|
||||
|
||||
## 2. 故障恢复
|
||||
|
||||
|
||||
# 参考资料
|
||||
|
||||
- 高性能 MySQL
|
||||
- [MySQL 索引背后的数据结构及算法原理 ](http://blog.codinglabs.org/articles/theory-of-mysql-index.html)
|
||||
- [MySQL 索引优化全攻略 ](http://www.runoob.com/w3cnote/mysql-index.html)
|
||||
- [20+ 条 MySQL 性能优化的最佳经验 ](https://www.jfox.info/20-tiao-mysql-xing-nen-you-hua-de-zui-jia-jing-yan.html)
|
||||
- [数据库为什么分库分表？mysql的分库分表方案](https://www.i3geek.com/archives/1108)
|
||||
|
|
|
|||
Loading…
Reference in New Issue
Block a user