auto commit
This commit is contained in:
CyC2018
@ -19,10 +19,6 @@
|
||||
* [水平切分](#水平切分)
|
||||
* [切分的选择](#切分的选择)
|
||||
* [存在的问题](#存在的问题)
|
||||
* [六、分库与分表带来的分布式困境与应对之策](#六分库与分表带来的分布式困境与应对之策)
|
||||
* [事务问题](#事务问题)
|
||||
* [查询问题](#查询问题)
|
||||
* [ID 唯一性](#id-唯一性)
|
||||
* [六、故障转移和故障恢复](#六故障转移和故障恢复)
|
||||
* [参考资料](#参考资料)
|
||||
<!-- GFM-TOC -->
|
||||
@ -58,11 +54,15 @@ MyISAM 设计简单，数据以紧密格式存储。对于只读数据，或者
|
||||
|
||||
## 比较
|
||||
|
||||
1. 事务：InnoDB 是事务型的。
|
||||
2. 备份：InnoDB 支持在线热备份。
|
||||
3. 崩溃恢复：MyISAM 崩溃后发生损坏的概率比 InnoDB 高很多，而且恢复的速度也更慢。
|
||||
4. 并发：MyISAM 只支持表级锁，而 InnoDB 还支持行级锁。
|
||||
5. 其它特性：MyISAM 支持压缩表和空间数据索引。
|
||||
- 事务：InnoDB 是事务型的。
|
||||
|
||||
- 备份：InnoDB 支持在线热备份。
|
||||
|
||||
- 崩溃恢复：MyISAM 崩溃后发生损坏的概率比 InnoDB 高很多，而且恢复的速度也更慢。
|
||||
|
||||
- 并发：MyISAM 只支持表级锁，而 InnoDB 还支持行级锁。
|
||||
|
||||
- 其它特性：MyISAM 支持压缩表和空间数据索引。
|
||||
|
||||
# 二、数据类型
|
||||
|
||||
@ -102,7 +102,7 @@ MySQL 提供了两种相似的日期时间类型：DATATIME 和 TIMESTAMP。
|
||||
|
||||
和 UNIX 时间戳相同，保存从 1970 年 1 月 1 日午夜（格林威治时间）以来的秒数，使用 4 个字节，只能表示从 1970 年 到 2038 年。
|
||||
|
||||
它和时区有关。
|
||||
它和时区有关，也就是说一个时间戳在不同的时区所代表的具体时间是不同的。
|
||||
|
||||
MySQL 提供了 FROM_UNIXTIME() 函数把 UNIX 时间戳转换为日期，并提供了 UNIX_TIMESTAMP() 函数把日期转换为 UNIX 时间戳。
|
||||
|
||||
@ -124,7 +124,7 @@ MySQL 提供了 FROM_UNIXTIME() 函数把 UNIX 时间戳转换为日期，并提
|
||||
|
||||
<div align="center"> <img src="../pics//c23957e9-a572-44f8-be15-f306c8b92722.jpg"/> </div><br>
|
||||
|
||||
《高性能 MySQL》一书使用 B-Tree 进行描述，其实从技术上来说这种索引是 B+Tree。
|
||||
《高性能 MySQL》一书使用 B-Tree 进行描述，其实从技术上来说这种索引是 B+Tree，因为只有叶子节点存储数据值。
|
||||
|
||||
B+Tree 索引是大多数 MySQL 存储引擎的默认索引类型。
|
||||
|
||||
@ -147,15 +147,15 @@ InnoDB 引擎有一个特殊的功能叫“自适应哈希索引”，当某个
|
||||
限制：
|
||||
|
||||
- 哈希索引只包含哈希值和行指针，而不存储字段值，所以不能使用索引中的值来避免读取行。不过，访问内存中的行的速度很快，所以大部分情况下这一点对性能影响并不明显；
|
||||
- 无法用于分组与排序；
|
||||
- 无法用于排序与分组；
|
||||
- 只支持精确查找，无法用于部分查找和范围查找；
|
||||
- 如果哈希冲突很多，查找速度会变得很慢。
|
||||
|
||||
### 3. 空间数据索引（R-Tree）
|
||||
|
||||
MyISAM 存储引擎支持空间索引，可以用于地理数据存储。
|
||||
MyISAM 存储引擎支持空间数据索引，可以用于地理数据存储。
|
||||
|
||||
空间索引会从所有维度来索引数据，可以有效地使用任意维度来进行组合查询。
|
||||
空间数据索引会从所有维度来索引数据，可以有效地使用任意维度来进行组合查询。
|
||||
|
||||
必须使用 GIS 相关的函数来维护数据。
|
||||
|
||||
@ -163,7 +163,7 @@ MyISAM 存储引擎支持空间索引，可以用于地理数据存储。
|
||||
|
||||
MyISAM 存储引擎支持全文索引，用于查找文本中的关键词，而不是直接比较索引中的值。
|
||||
|
||||
使用 MATCH AGAINST，而不是普通的 WHERE。
|
||||
查找条件使用 MATCH AGAINST，而不是普通的 WHERE。
|
||||
|
||||
## 索引的优点
|
||||
|
||||
@ -171,7 +171,7 @@ MyISAM 存储引擎支持全文索引，用于查找文本中的关键词，而
|
||||
|
||||
- 帮助服务器避免进行排序和创建临时表（B+Tree 索引是有序的，可以用来做 ORDER BY 和 GROUP BY 操作）；
|
||||
|
||||
- 将随机 I/O 变为顺序 I/O（B+Tree 索引是有序的，也就将相邻的列值都存储在一起）。
|
||||
- 将随机 I/O 变为顺序 I/O（B+Tree 索引是有序的，也就将相邻的数据都存储在一起）。
|
||||
|
||||
## 索引优化
|
||||
|
||||
@ -256,9 +256,7 @@ customer_id_selectivity: 0.0373
|
||||
|
||||
<div align="center"> <img src="../pics//5ed71283-a070-4b21-85ae-f2cbfd6ba6e1.jpg"/> </div><br>
|
||||
|
||||
为了描述 B-Tree，首先定义一条数据记录为一个二元组 [key, data]。
|
||||
|
||||
B-Tree 是满足下列条件的数据结构：
|
||||
定义一条数据记录为一个二元组 [key, data]，B-Tree 是满足下列条件的数据结构：
|
||||
|
||||
- 所有叶节点具有相同的深度，也就是说 B-Tree 是平衡的；
|
||||
- 一个节点中的 key 从左到右非递减排列；
|
||||
@ -283,17 +281,25 @@ B-Tree 是满足下列条件的数据结构：
|
||||
|
||||
一般在数据库系统或文件系统中使用的 B+Tree 结构都在经典 B+Tree 基础上进行了优化，在叶子节点增加了顺序访问指针，做这个优化的目的是为了提高区间访问的性能。
|
||||
|
||||
### 4. 为什么使用 B-Tree 和 B+Tree
|
||||
### 4. 为什么使用 B+Tree 和 B-Tree
|
||||
|
||||
红黑树等数据结构也可以用来实现索引，但是文件系统及数据库系统普遍采用 B-/+Tree 作为索引结构。
|
||||
红黑树等平衡树也可以用来实现索引，但是文件系统及数据库系统普遍采用 B+Tree B-Tree 作为索引结构，主要有以下两个原因：
|
||||
|
||||
页是计算机管理存储器的逻辑块，硬件及操作系统往往将主存和磁盘存储区分割为连续的大小相等的块，每个存储块称为一页（在许多操作系统中，页的大小通常为 4k），主存和磁盘以页为单位交换数据。
|
||||
**（一）更少的检索次数**
|
||||
|
||||
一般来说，索引本身也很大，不可能全部存储在内存中，因此索引往往以索引文件的形式存储的磁盘上。为了减少磁盘 I/O，磁盘往往不是严格按需读取，而是每次都会预读。这样做的理论依据是计算机科学中著名的局部性原理：当一个数据被用到时，其附近的数据也通常会马上被使用。数据库系统的设计者巧妙利用了磁盘预读原理，将一个节点的大小设为等于一个页，这样每个节点只需要一次 I/O 就可以完全载入。
|
||||
红黑树和 B+Tree B-Tree 检索数据的时间复杂度等于树高 h，而树高大致为 O(h)=O(log<sub>d</sub>N)，其中 d 为每个节点的出度。
|
||||
|
||||
B-Tree 中一次检索最多需要 h-1 次 I/O（根节点常驻内存），渐进复杂度为 O(h)=O(log<sub>d</sub>N)。一般实际应用中，出度 d 是非常大的数字，通常超过 100，因此 h 非常小（通常不超过 3）。而红黑树这种结构，h 明显要深的多。并且于逻辑上很近的节点（父子）物理上可能很远，无法利用局部性，效率明显比 B-Tree 差很多。
|
||||
红黑树的出度为 2，而 B+Tree 与 B-Tree 的出度一般都非常大。红黑树的树高 h 很明显比 B+Tree B-Tree 大非常多，因此检索的次数也就更多。
|
||||
|
||||
B+Tree 更适合外存索引，原因和内节点出度 d 有关。由于 B+Tree 内节点去掉了 data 域，因此可以拥有更大的出度，拥有更好的性能。
|
||||
B+Tree 相比于 B-Tree 更适合外存索引，因为 B+Tree 内节点去掉了 data 域，因此可以拥有更大的出度，检索效率会更高。
|
||||
|
||||
**（二）利用计算机预读特性**
|
||||
|
||||
为了减少磁盘 I/O，磁盘往往不是严格按需读取，而是每次都会预读。这样做的理论依据是计算机科学中著名的局部性原理：当一个数据被用到时，其附近的数据也通常会马上被使用。预读过程中，磁盘进行顺序读取，顺序读取不需要进行磁盘寻道，并且只需要很短的旋转时间，因此速度会非常快。
|
||||
|
||||
操作系统一般将内存和磁盘分割成固态大小的块，每一块称为一页，内存与磁盘以页为单位交换数据。数据库系统将索引的一个节点的大小设置为页的大小，使得一次 I/O 就能完全载入一个节点，并且可以利用预读特性，临近的节点也能够被预先载入。
|
||||
|
||||
更多内容请参考：[MySQL 索引背后的数据结构及算法原理](http://blog.codinglabs.org/articles/theory-of-mysql-index.html)
|
||||
|
||||
# 四、查询性能优化
|
||||
|
||||
@ -372,25 +378,6 @@ do {
|
||||
|
||||
最显而易见的就是数据的定位问题和数据的增删改查的重复执行问题，这些都可以通过应用程序解决，但必然引起额外的逻辑运算。
|
||||
|
||||
# 六、分库与分表带来的分布式困境与应对之策
|
||||
|
||||
<div align="center"> <img src="../pics//c81af7d8-3128-4a3c-a9c9-3e0f5b87ab22.jpg"/> </div><br>
|
||||
|
||||
## 事务问题
|
||||
|
||||
使用分布式事务。
|
||||
|
||||
## 查询问题
|
||||
|
||||
使用汇总表。
|
||||
|
||||
## ID 唯一性
|
||||
|
||||
- 使用全局唯一 ID：GUID。
|
||||
- 为每个分片指定一个 ID 范围。
|
||||
- 分布式 ID 生成器 (如 Twitter 的 [Snowflake](https://twitter.github.io/twitter-server/) 算法)。
|
||||
|
||||
|
||||
# 六、故障转移和故障恢复
|
||||
|
||||
故障转移也叫做切换，当主库出现故障时就切换到备库，使备库成为主库。故障恢复顾名思义就是从故障中恢复过来，并且保证数据的正确性。
|
||||
@ -415,7 +402,6 @@ do {
|
||||
|
||||
- BaronScbwartz, PeterZaitsev, VadimTkacbenko, 等. 高性能 MySQL[M]. 电子工业出版社, 2013.
|
||||
- [How Sharding Works](https://medium.com/@jeeyoungk/how-sharding-works-b4dec46b3f6)
|
||||
- [MySQL 索引背后的数据结构及算法原理 ](http://blog.codinglabs.org/articles/theory-of-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)
|
||||
- [How Sharding Works](https://medium.com/@jeeyoungk/how-sharding-works-b4dec46b3f6)
|
||||
|
||||
Reference in New Issue
Block a user