auto commit
This commit is contained in:
CyC2018
parent
daa3be3e62
commit
2fb6d1c838
203
notes/MySQL.md
203
notes/MySQL.md
|
|
@ -1,57 +1,33 @@
|
|||
<!-- GFM-TOC -->
|
||||
* [存储引擎](#存储引擎)
|
||||
* [1. InnoDB](#1-innodb)
|
||||
* [2. MyISAM](#2-myisam)
|
||||
* [3. InnoDB 与 MyISAM 的比较](#3-innodb-与-myisam-的比较)
|
||||
* [数据类型](#数据类型)
|
||||
* [1. 整型](#1-整型)
|
||||
* [2. 浮点数](#2-浮点数)
|
||||
* [3. 字符串](#3-字符串)
|
||||
* [4. 时间和日期](#4-时间和日期)
|
||||
* [索引](#索引)
|
||||
* [1. 索引分类](#1-索引分类)
|
||||
* [1.1 B-Tree 索引](#11-b-tree-索引)
|
||||
* [1.2 哈希索引](#12-哈希索引)
|
||||
* [1.3. 空间索引（R-Tree）](#13-空间索引r-tree)
|
||||
* [1.4 全文索引](#14-全文索引)
|
||||
* [2. 索引的优点](#2-索引的优点)
|
||||
* [3. 索引优化](#3-索引优化)
|
||||
* [3.1 独立的列](#31-独立的列)
|
||||
* [3.2 前缀索引](#32-前缀索引)
|
||||
* [3.3 多列索引](#33-多列索引)
|
||||
* [3.4 索引列的顺序](#34-索引列的顺序)
|
||||
* [3.5 聚簇索引](#35-聚簇索引)
|
||||
* [3.6 覆盖索引](#36-覆盖索引)
|
||||
* [4. B-Tree 和 B+Tree 原理](#4-b-tree-和-b+tree-原理)
|
||||
* [4. 1 B-Tree](#4-1-b-tree)
|
||||
* [4.2 B+Tree](#42-b+tree)
|
||||
* [4.3 带有顺序访问指针的 B+Tree](#43-带有顺序访问指针的-b+tree)
|
||||
* [4.4 为什么使用 B-Tree 和 B+Tree](#44-为什么使用-b-tree-和-b+tree)
|
||||
* [查询性能优化](#查询性能优化)
|
||||
* [1. Explain](#1-explain)
|
||||
* [2. 减少返回的列](#2-减少返回的列)
|
||||
* [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-分表与分区的不同)
|
||||
* [故障转移和故障恢复](#故障转移和故障恢复)
|
||||
* [一、存储引擎](#一存储引擎)
|
||||
* [InnoDB](#innodb)
|
||||
* [MyISAM](#myisam)
|
||||
* [比较](#比较)
|
||||
* [二、数据类型](#二数据类型)
|
||||
* [整型](#整型)
|
||||
* [浮点数](#浮点数)
|
||||
* [字符串](#字符串)
|
||||
* [时间和日期](#时间和日期)
|
||||
* [三、索引](#三索引)
|
||||
* [索引分类](#索引分类)
|
||||
* [索引的优点](#索引的优点)
|
||||
* [索引优化](#索引优化)
|
||||
* [B-Tree 和 B+Tree 原理](#b-tree-和-b+tree-原理)
|
||||
* [四、查询性能优化](#四查询性能优化)
|
||||
* [五、分库与分表](#五分库与分表)
|
||||
* [原因](#原因)
|
||||
* [实现方式](#实现方式)
|
||||
* [Merge 存储引擎](#merge-存储引擎)
|
||||
* [存在的问题](#存在的问题)
|
||||
* [分表与分区的不同](#分表与分区的不同)
|
||||
* [六、故障转移和故障恢复](#六故障转移和故障恢复)
|
||||
* [参考资料](#参考资料)
|
||||
<!-- GFM-TOC -->
|
||||
|
||||
|
||||
# 存储引擎
|
||||
# 一、存储引擎
|
||||
|
||||
## 1. InnoDB
|
||||
## InnoDB
|
||||
|
||||
InnoDB 是 MySQL 默认的事务型存储引擎，只有在需要 InnoDB 不支持的特性时，才考虑使用其它存储引擎。
|
||||
|
||||
|
|
@ -63,7 +39,7 @@ InnoDB 是 MySQL 默认的事务型存储引擎，只有在需要 InnoDB 不支
|
|||
|
||||
通过一些机制和工具支持真正的热备份。
|
||||
|
||||
## 2. MyISAM
|
||||
## MyISAM
|
||||
|
||||
MyISAM 提供了大量的特性，包括全文索引、压缩、空间函数（GIS）等。但 MyISAM 不支持事务和行级锁，而且崩溃后无法安全恢复。
|
||||
|
||||
|
|
@ -81,43 +57,29 @@ MyISAM 提供了大量的特性，包括全文索引、压缩、空间函数（G
|
|||
|
||||
MyISAM 设计简单，数据以紧密格式存储，所以在某些场景下性能很好。
|
||||
|
||||
## 3. InnoDB 与 MyISAM 的比较
|
||||
## 比较
|
||||
|
||||
**事务**
|
||||
1. 事务：InnoDB 是事务型的。
|
||||
2. 备份：InnoDB 支持在线热备份。
|
||||
3. 崩溃恢复：MyISAM 崩溃后发生损坏的概率比 InnoDB 高很多，而且恢复的速度也更慢。
|
||||
4. 并发：MyISAM 只支持表级锁，而 InnoDB 还支持行级锁。
|
||||
5. 其它特性：MyISAM 支持全文索引，地理空间索引。
|
||||
|
||||
InnoDB 是事务型的。
|
||||
# 二、数据类型
|
||||
|
||||
**备份**
|
||||
|
||||
InnoDB 支持在线热备份。
|
||||
|
||||
**崩溃恢复**
|
||||
|
||||
MyISAM 崩溃后发生损坏的概率比 InnoDB 高很多，而且恢复的速度也更慢。
|
||||
|
||||
**并发**
|
||||
|
||||
MyISAM 只支持表级锁，而 InnoDB 还支持行级锁。
|
||||
|
||||
**其它特性**
|
||||
|
||||
MyISAM 支持全文索引，地理空间索引。
|
||||
|
||||
# 数据类型
|
||||
|
||||
## 1. 整型
|
||||
## 整型
|
||||
|
||||
TINYINT, SMALLINT, MEDIUMINT, INT, BIGINT 分别使用 8, 16, 24, 32, 64 位存储空间，一般情况下越小的列越好。
|
||||
|
||||
INT(11) 中的数字只是规定了交互工具显示字符的个数，对于存储和计算来说是没有意义的。
|
||||
|
||||
## 2. 浮点数
|
||||
## 浮点数
|
||||
|
||||
FLOAT 和 DOUBLE 为浮点类型，DECIMAL 为高精度小数类型。CPU 原生支持浮点运算，但是不支持 DECIMAl 类型的计算，因此 DECIMAL 的计算比浮点类型需要更高的代价。
|
||||
|
||||
FLOAT、DOUBLE 和 DECIMAL 都可以指定列宽，例如 DECIMAL(18, 9) 表示总共 18 位，取 9 位存储小数部分，剩下 9 位存储整数部分。
|
||||
|
||||
## 3. 字符串
|
||||
## 字符串
|
||||
|
||||
主要有 CHAR 和 VARCHAR 两种类型，一种是定长的，一种是变长的。
|
||||
|
||||
|
|
@ -125,11 +87,11 @@ VARCHAR 这种变长类型能够节省空间，因为只需要存储必要的内
|
|||
|
||||
VARCHAR 会保留字符串末尾的空格，而 CHAR 会删除。
|
||||
|
||||
## 4. 时间和日期
|
||||
## 时间和日期
|
||||
|
||||
MySQL 提供了两种相似的日期时间类型：DATATIME 和 TIMESTAMP。
|
||||
|
||||
**DATATIME**
|
||||
### 1. DATATIME
|
||||
|
||||
能够保存从 1001 年到 9999 年的日期和时间，精度为秒，使用 8 字节的存储空间。
|
||||
|
||||
|
|
@ -137,7 +99,7 @@ MySQL 提供了两种相似的日期时间类型：DATATIME 和 TIMESTAMP。
|
|||
|
||||
默认情况下，MySQL 以一种可排序的、无歧义的格式显示 DATATIME 值，例如“2008-01-16 22:37:08”，这是 ANSI 标准定义的日期和时间表示方法。
|
||||
|
||||
**TIMESTAMP**
|
||||
### 2. TIMESTAMP
|
||||
|
||||
和 UNIX 时间戳相同，保存从 1970 年 1 月 1 日午夜（格林威治时间）以来的秒数，使用 4 个字节，只能表示从 1970 年 到 2038 年。
|
||||
|
||||
|
|
@ -149,7 +111,7 @@ MySQL 提供了 FROM_UNIXTIME() 函数把 UNIX 时间戳转换为日期，并提
|
|||
|
||||
应该尽量使用 TIMESTAMP，因为它比 DATETIME 空间效率更高。
|
||||
|
||||
# 索引
|
||||
# 三、索引
|
||||
|
||||
索引是在存储引擎层实现的，而不是在服务器层实现的，所以不同存储引擎具有不同的索引类型和实现。
|
||||
|
||||
|
|
@ -157,9 +119,9 @@ MySQL 提供了 FROM_UNIXTIME() 函数把 UNIX 时间戳转换为日期，并提
|
|||
|
||||
对于非常小的表、大部分情况下简单的全表扫描比建立索引更高效。对于中到大型的表，索引就非常有效。但是对于特大型的表，建立和使用索引的代价将会随之增长。这种情况下，需要用到一种技术可以直接区分出需要查询的一组数据，而不是一条记录一条记录地匹配，例如可以使用分区技术。
|
||||
|
||||
## 1. 索引分类
|
||||
## 索引分类
|
||||
|
||||
### 1.1 B-Tree 索引
|
||||
### 1. B-Tree 索引
|
||||
|
||||
B-Tree 索引是大多数 MySQL 存储引擎的默认索引类型。
|
||||
|
||||
|
|
@ -171,7 +133,7 @@ B-Tree 索引是大多数 MySQL 存储引擎的默认索引类型。
|
|||
|
||||
如果不是按照索引列的顺序进行查找，则无法使用索引。
|
||||
|
||||
### 1.2 哈希索引
|
||||
### 2. 哈希索引
|
||||
|
||||
基于哈希表实现，优点是查找非常快。
|
||||
|
||||
|
|
@ -181,19 +143,19 @@ InnoDB 引擎有一个特殊的功能叫“自适应哈希索引”，当某个
|
|||
|
||||
限制：哈希索引只包含哈希值和行指针，而不存储字段值，所以不能使用索引中的值来避免读取行。不过，访问内存中的行的速度很快，所以大部分情况下这一点对性能影响并不明显；无法用于分组与排序；只支持精确查找，无法用于部分查找和范围查找；如果哈希冲突很多，查找速度会变得很慢。
|
||||
|
||||
### 1.3. 空间索引（R-Tree）
|
||||
### 3. 空间索引（R-Tree）
|
||||
|
||||
MyISAM 存储引擎支持空间索引，可以用于地理数据存储。
|
||||
|
||||
空间索引会从所有维度来索引数据，可以有效地使用任意维度来进行组合查询。
|
||||
|
||||
### 1.4 全文索引
|
||||
### 4. 全文索引
|
||||
|
||||
MyISAM 存储引擎支持全文索引，用于查找文本中的关键词，而不是直接比较索引中的值。
|
||||
|
||||
使用 MATCH AGAINST，而不是普通的 WHERE。
|
||||
|
||||
## 2. 索引的优点
|
||||
## 索引的优点
|
||||
|
||||
- 大大减少了服务器需要扫描的数据量；
|
||||
|
||||
|
|
@ -201,9 +163,9 @@ MyISAM 存储引擎支持全文索引，用于查找文本中的关键词，而
|
|||
|
||||
- 将随机 I/O 变为顺序 I/O。
|
||||
|
||||
## 3. 索引优化
|
||||
## 索引优化
|
||||
|
||||
### 3.1 独立的列
|
||||
### 1. 独立的列
|
||||
|
||||
在进行查询时，索引列不能是表达式的一部分，也不能是函数的参数，否则无法使用索引。
|
||||
|
||||
|
|
@ -213,13 +175,13 @@ MyISAM 存储引擎支持全文索引，用于查找文本中的关键词，而
|
|||
SELECT actor_id FROM sakila.actor WHERE actor_id + 1 = 5;
|
||||
```
|
||||
|
||||
### 3.2 前缀索引
|
||||
### 2. 前缀索引
|
||||
|
||||
对于 BLOB、TEXT 和 VARCHAR 类型的列，必须使用前缀索引，只索引开始的部分字符。
|
||||
|
||||
对于前缀长度的选取需要根据 **索引选择性** 来确定：不重复的索引值和记录总数的比值。选择性越高，查询效率也越高。最大值为 1 ，此时每个记录都有唯一的索引与其对应。
|
||||
|
||||
### 3.3 多列索引
|
||||
### 3. 多列索引
|
||||
|
||||
在需要使用多个列作为条件进行查询时，使用多列索引比使用多个单列索引性能更好。例如下面的语句中，最好把 actor_id 和 film_id 设置为多列索引。
|
||||
|
||||
|
|
@ -228,7 +190,7 @@ SELECT film_id, actor_ id FROM sakila.film_actor
|
|||
WhERE actor_id = 1 AND film_id = 1;
|
||||
```
|
||||
|
||||
### 3.4 索引列的顺序
|
||||
### 4. 索引列的顺序
|
||||
|
||||
让选择性最强的索引列放在前面，例如下面显示的结果中 customer_id 的选择性比 staff_id 更高，因此最好把 customer_id 列放在多列索引的前面。
|
||||
|
||||
|
|
@ -245,7 +207,7 @@ customer_id_selectivity: 0.0373
|
|||
COUNT(*): 16049
|
||||
```
|
||||
|
||||
### 3.5 聚簇索引
|
||||
### 5. 聚簇索引
|
||||
|
||||
<div align="center"> <img src="../pics//b9e9ae8c-e216-4c01-b267-a50dbeb98fa4.jpg"/> </div><br>
|
||||
|
||||
|
|
@ -255,12 +217,12 @@ customer_id_selectivity: 0.0373
|
|||
|
||||
因为无法把数据行存放在两个不同的地方，所以一个表只能有一个聚簇索引。
|
||||
|
||||
**优点**
|
||||
#### 优点
|
||||
|
||||
1. 可以把相关数据保存在一起，减少 I/O 操作；
|
||||
2. 因为数据保存在 B-Tree 中，因此数据访问更快。
|
||||
|
||||
**缺点**
|
||||
#### 缺点
|
||||
|
||||
1. 聚簇索引最大限度提高了 I/O 密集型应用的性能，但是如果数据全部放在内存，就没必要用聚簇索引。
|
||||
2. 插入速度严重依赖于插入顺序，按主键的顺序插入是最快的。
|
||||
|
|
@ -268,19 +230,19 @@ customer_id_selectivity: 0.0373
|
|||
4. 当插入到某个已满的页中，存储引擎会将该页分裂成两个页面来容纳该行，页分裂会导致表占用更多的磁盘空间。
|
||||
5. 如果行比较稀疏，或者由于页分裂导致数据存储不连续时，聚簇索引可能导致全表扫描速度变慢。
|
||||
|
||||
### 3.6 覆盖索引
|
||||
### 6. 覆盖索引
|
||||
|
||||
索引包含所有需要查询的字段的值。
|
||||
|
||||
**优点**
|
||||
#### 优点
|
||||
|
||||
1. 因为索引条目通常远小于数据行的大小，所以若只读取索引，能大大减少数据访问量。
|
||||
2. 一些存储引擎（例如 MyISAM）在内存中只缓存索引，而数据依赖于操作系统来缓存。因此，只访问索引可以不使用系统调用（通常比较费时）。
|
||||
3. 对于 InnoDB 引擎，若二级索引能够覆盖查询，则无需访问聚簇索引。
|
||||
|
||||
## 4. B-Tree 和 B+Tree 原理
|
||||
## B-Tree 和 B+Tree 原理
|
||||
|
||||
### 4. 1 B-Tree
|
||||
### 1. B-Tree
|
||||
|
||||
<div align="center"> <img src="../pics//5ed71283-a070-4b21-85ae-f2cbfd6ba6e1.jpg"/> </div><br>
|
||||
|
||||
|
|
@ -296,7 +258,7 @@ B-Tree 是满足下列条件的数据结构：
|
|||
|
||||
由于插入删除新的数据记录会破坏 B-Tree 的性质，因此在插入删除时，需要对树进行一个分裂、合并、转移等操作以保持 B-Tree 性质。
|
||||
|
||||
### 4.2 B+Tree
|
||||
### 2. B+Tree
|
||||
|
||||
<div align="center"> <img src="../pics//63cd5b50-d6d8-4df6-8912-ef4a1dd5ba13.jpg"/> </div><br>
|
||||
|
||||
|
|
@ -305,13 +267,13 @@ B-Tree 是满足下列条件的数据结构：
|
|||
- 每个节点的指针上限为 2d 而不是 2d+1；
|
||||
- 内节点不存储 data，只存储 key，叶子节点不存储指针。
|
||||
|
||||
### 4.3 带有顺序访问指针的 B+Tree
|
||||
### 3. 带有顺序访问指针的 B+Tree
|
||||
|
||||
<div align="center"> <img src="../pics//1ee5f0a5-b8df-43b9-95ab-c516c54ec797.jpg"/> </div><br>
|
||||
|
||||
一般在数据库系统或文件系统中使用的 B+Tree 结构都在经典 B+Tree 基础上进行了优化，在叶子节点增加了顺序访问指针，做这个优化的目的是为了提高区间访问的性能。
|
||||
|
||||
### 4.4 为什么使用 B-Tree 和 B+Tree
|
||||
### 4. 为什么使用 B-Tree 和 B+Tree
|
||||
|
||||
红黑树等数据结构也可以用来实现索引，但是文件系统及数据库系统普遍采用 B-/+Tree 作为索引结构。
|
||||
|
||||
|
|
@ -321,9 +283,9 @@ B-Tree 是满足下列条件的数据结构：
|
|||
|
||||
B+Tree 更适合外存索引，原因和内节点出度 d 有关。由于 B+Tree 内节点去掉了 data 域，因此可以拥有更大的出度，拥有更好的性能。
|
||||
|
||||
# 查询性能优化
|
||||
# 四、查询性能优化
|
||||
|
||||
## 1. Explain
|
||||
### Explain
|
||||
|
||||
用来分析 SQL 语句，分析结果中比较重要的字段有：
|
||||
|
||||
|
|
@ -333,13 +295,13 @@ B+Tree 更适合外存索引，原因和内节点出度 d 有关。由于 B+Tree
|
|||
|
||||
- rows : 扫描的行数
|
||||
|
||||
## 2. 减少返回的列
|
||||
### 减少返回的列
|
||||
|
||||
慢查询主要是因为访问了过多数据，除了访问过多行之外，也包括访问过多列。
|
||||
|
||||
最好不要使用 SELECT * 语句，要根据需要选择查询的列。
|
||||
|
||||
## 3. 减少返回的行
|
||||
### 减少返回的行
|
||||
|
||||
最好使用 LIMIT 语句来取出想要的那些行。
|
||||
|
||||
|
|
@ -349,7 +311,7 @@ B+Tree 更适合外存索引，原因和内节点出度 d 有关。由于 B+Tree
|
|||
SELECT * FROM sakila.film_actor WHERE film_id = 1;
|
||||
```
|
||||
|
||||
## 4. 拆分大的 DELETE 或 INSERT 语句
|
||||
### 拆分大的 DELETE 或 INSERT 语句
|
||||
|
||||
如果一次性执行的话，可能一次锁住很多数据、占满整个事务日志、耗尽系统资源、阻塞很多小的但重要的查询。
|
||||
|
||||
|
|
@ -364,73 +326,72 @@ do {
|
|||
} while rows_affected > 0
|
||||
```
|
||||
|
||||
# 分库与分表
|
||||
# 五、分库与分表
|
||||
|
||||
## 1. 分库与分表的原因
|
||||
## 原因
|
||||
|
||||
随着时间和业务的发展，数据库中的表会越来越多，并且表中的数据量也会越来越大，那么读写操作的开销也会随着增大。
|
||||
|
||||
## 2. 实现方式
|
||||
## 实现方式
|
||||
|
||||
### 2.1 垂直切分
|
||||
### 1. 垂直切分
|
||||
|
||||
将表按功能模块、关系密切程度划分出来，部署到不同的库上。例如，我们会建立商品数据库 payDB、用户数据库 userDB 等，分别用来存储项目与商品有关的表和与用户有关的表。
|
||||
|
||||
### 2.2 水平切分
|
||||
### 2. 水平切分
|
||||
|
||||
把表中的数据按照某种规则存储到多个结构相同的表中，例如按 id 的散列值、性别等进行划分。
|
||||
|
||||
### 2.3 切分的选择
|
||||
### 3. 切分的选择
|
||||
|
||||
如果数据库中的表太多，并且项目各项业务逻辑清晰，那么垂直切分是首选。
|
||||
|
||||
如果数据库的表不多，但是单表的数据量很大，应该选择水平切分。
|
||||
|
||||
## 3. Merge 存储引擎
|
||||
## Merge 存储引擎
|
||||
|
||||
该存储引擎支持分表。
|
||||
|
||||
## 4. 分库与分表存在的问题
|
||||
## 存在的问题
|
||||
|
||||
### 4.1 事务问题
|
||||
### 1. 事务问题
|
||||
|
||||
在执行分库分表之后，由于数据存储到了不同的库上，数据库事务管理出现了困难。如果依赖数据库本身的分布式事务管理功能去执行事务，将付出高昂的性能代价；如果由应用程序去协助控制，形成程序逻辑上的事务，又会造成编程方面的负担。
|
||||
|
||||
### 4.2 跨库跨表连接问题
|
||||
### 2. 跨库跨表连接问题
|
||||
|
||||
在执行了分库分表之后，难以避免会将原本逻辑关联性很强的数据划分到不同的表、不同的库上。这时，表的连接操作将受到限制，我们无法连接位于不同分库的表，也无法连接分表粒度不同的表，导致原本只需要一次查询就能够完成的业务需要进行多次才能完成。
|
||||
|
||||
### 4.3 额外的数据管理负担和数据运算压力
|
||||
### 3. 额外的数据管理负担和数据运算压力
|
||||
|
||||
最显而易见的就是数据的定位问题和数据的增删改查的重复执行问题，这些都可以通过应用程序解决，但必然引起额外的逻辑运算。
|
||||
|
||||
## 5. 分表与分区的不同
|
||||
## 分表与分区的不同
|
||||
|
||||
分表，就是将一张表分成多个小表，这些小表拥有不同的表名；而分区是将一张表的数据分为多个区块，这些区块可以存储在同一个磁盘上，也可以存储在不同的磁盘上，这种方式下表仍然只有一个。
|
||||
|
||||
# 故障转移和故障恢复
|
||||
# 六、故障转移和故障恢复
|
||||
|
||||
故障转移也叫做切换，当主库出现故障时就切换到备库，使备库成为主库。故障恢复顾名思义就是从故障中恢复过来，并且保证数据的正确性。
|
||||
|
||||
**提升备库或切换角色**
|
||||
### 提升备库或切换角色
|
||||
|
||||
提升一台备库为主库，或者在一个主-主复制结构中调整主动和被动角色。
|
||||
|
||||
**虚拟 IP 地址和 IP 托管**
|
||||
### 虚拟 IP 地址和 IP 托管
|
||||
|
||||
为 MySQL 实例指定一个逻辑 IP 地址，当 MySQL 实例失效时，可以将 IP 地址转移到另一台 MySQL 服务器上。
|
||||
|
||||
**中间件解决方案**
|
||||
### 中间件解决方案
|
||||
|
||||
通过代理，可以路由流量到可以使用的服务器上。
|
||||
|
||||
<div align="center"> <img src="../pics//fabd5fa0-b75e-48d0-9e2c-31471945ceb9.jpg"/> </div><br>
|
||||
|
||||
**在应用中处理故障转移**
|
||||
### 在应用中处理故障转移
|
||||
|
||||
将故障转移整合到应用中可能导致应用变得太过笨拙。
|
||||
|
||||
|
||||
# 参考资料
|
||||
|
||||
- 高性能 MySQL
|
||||
|
|
|
|||
Loading…
Reference in New Issue
Block a user