auto commit
This commit is contained in:
CyC2018
parent
3da8d737e6
commit
9f1e252e36
314
notes/MySQL.md
314
notes/MySQL.md
|
|
@ -1,22 +1,23 @@
|
|||
<!-- GFM-TOC -->
|
||||
* [一、存储引擎](#一存储引擎)
|
||||
* [一、索引](#一索引)
|
||||
* [B+ Tree 原理](#b-tree-原理)
|
||||
* [MySQL 索引](#mysql-索引)
|
||||
* [索引优化](#索引优化)
|
||||
* [索引的优点](#索引的优点)
|
||||
* [索引的使用场景](#索引的使用场景)
|
||||
* [二、查询性能优化](#二查询性能优化)
|
||||
* [使用 Explain 进行分析](#使用-explain-进行分析)
|
||||
* [优化数据访问](#优化数据访问)
|
||||
* [重构查询方式](#重构查询方式)
|
||||
* [三、存储引擎](#三存储引擎)
|
||||
* [InnoDB](#innodb)
|
||||
* [MyISAM](#myisam)
|
||||
* [比较](#比较)
|
||||
* [二、数据类型](#二数据类型)
|
||||
* [四、数据类型](#四数据类型)
|
||||
* [整型](#整型)
|
||||
* [浮点数](#浮点数)
|
||||
* [字符串](#字符串)
|
||||
* [时间和日期](#时间和日期)
|
||||
* [三、索引](#三索引)
|
||||
* [B+ Tree 原理](#b-tree-原理)
|
||||
* [索引分类](#索引分类)
|
||||
* [索引的优点](#索引的优点)
|
||||
* [索引优化](#索引优化)
|
||||
* [四、查询性能优化](#四查询性能优化)
|
||||
* [使用 Explain 进行分析](#使用-explain-进行分析)
|
||||
* [优化数据访问](#优化数据访问)
|
||||
* [重构查询方式](#重构查询方式)
|
||||
* [五、切分](#五切分)
|
||||
* [水平切分](#水平切分)
|
||||
* [垂直切分](#垂直切分)
|
||||
|
|
@ -29,101 +30,7 @@
|
|||
<!-- GFM-TOC -->
|
||||
|
||||
|
||||
# 一、存储引擎
|
||||
|
||||
## InnoDB
|
||||
|
||||
InnoDB 是 MySQL 默认的事务型存储引擎，只有在需要 InnoDB 不支持的特性时，才考虑使用其它存储引擎。
|
||||
|
||||
实现了四个标准的隔离级别，默认级别是可重复读（REPEATABLE READ）。在可重复读隔离级别下，通过多版本并发控制（MVCC）+ 间隙锁（next-key locking）防止幻影读。
|
||||
|
||||
主索引是聚簇索引，在索引中保存了数据，从而避免直接读取磁盘，因此对查询性能有很大的提升。
|
||||
|
||||
内部做了很多优化，包括从磁盘读取数据时采用的可预测性读、能够加快读操作并且自动创建的自适应哈希索引、能够加速插入操作的插入缓冲区等。
|
||||
|
||||
支持真正的在线热备份。其它存储引擎不支持在线热备份，要获取一致性视图需要停止对所有表的写入，而在读写混合场景中，停止写入可能也意味着停止读取。
|
||||
|
||||
## MyISAM
|
||||
|
||||
MyISAM 设计简单，数据以紧密格式存储。对于只读数据，或者表比较小、可以容忍修复操作，则依然可以使用 MyISAM。
|
||||
|
||||
MyISAM 提供了大量的特性，包括压缩表、空间数据索引等。
|
||||
|
||||
不支持事务。
|
||||
|
||||
不支持行级锁，只能对整张表加锁，读取时会对需要读到的所有表加共享锁，写入时则对表加排它锁。但在表有读取操作的同时，也可以往表中插入新的记录，这被称为并发插入（CONCURRENT INSERT）。
|
||||
|
||||
可以手工或者自动执行检查和修复操作，但是和事务恢复以及崩溃恢复不同，可能导致一些数据丢失，而且修复操作是非常慢的。
|
||||
|
||||
如果指定了 DELAY_KEY_WRITE 选项，在每次修改执行完成时，不会立即将修改的索引数据写入磁盘，而是会写到内存中的键缓冲区，只有在清理键缓冲区或者关闭表的时候才会将对应的索引块写入磁盘。这种方式可以极大的提升写入性能，但是在数据库或者主机崩溃时会造成索引损坏，需要执行修复操作。
|
||||
|
||||
## 比较
|
||||
|
||||
- 事务：InnoDB 是事务型的，可以使用 Commit 和 Rollback 语句。
|
||||
|
||||
- 并发：MyISAM 只支持表级锁，而 InnoDB 还支持行级锁。
|
||||
|
||||
- 外键：InnoDB 支持外键。
|
||||
|
||||
- 备份：InnoDB 支持在线热备份。
|
||||
|
||||
- 崩溃恢复：MyISAM 崩溃后发生损坏的概率比 InnoDB 高很多，而且恢复的速度也更慢。
|
||||
|
||||
- 其它特性：MyISAM 支持压缩表和空间数据索引。
|
||||
|
||||
# 二、数据类型
|
||||
|
||||
## 整型
|
||||
|
||||
TINYINT, SMALLINT, MEDIUMINT, INT, BIGINT 分别使用 8, 16, 24, 32, 64 位存储空间，一般情况下越小的列越好。
|
||||
|
||||
INT(11) 中的数字只是规定了交互工具显示字符的个数，对于存储和计算来说是没有意义的。
|
||||
|
||||
## 浮点数
|
||||
|
||||
FLOAT 和 DOUBLE 为浮点类型，DECIMAL 为高精度小数类型。CPU 原生支持浮点运算，但是不支持 DECIMAl 类型的计算，因此 DECIMAL 的计算比浮点类型需要更高的代价。
|
||||
|
||||
FLOAT、DOUBLE 和 DECIMAL 都可以指定列宽，例如 DECIMAL(18, 9) 表示总共 18 位，取 9 位存储小数部分，剩下 9 位存储整数部分。
|
||||
|
||||
## 字符串
|
||||
|
||||
主要有 CHAR 和 VARCHAR 两种类型，一种是定长的，一种是变长的。
|
||||
|
||||
VARCHAR 这种变长类型能够节省空间，因为只需要存储必要的内容。但是在执行 UPDATE 时可能会使行变得比原来长，当超出一个页所能容纳的大小时，就要执行额外的操作。MyISAM 会将行拆成不同的片段存储，而 InnoDB 则需要分裂页来使行放进页内。
|
||||
|
||||
VARCHAR 会保留字符串末尾的空格，而 CHAR 会删除。
|
||||
|
||||
## 时间和日期
|
||||
|
||||
MySQL 提供了两种相似的日期时间类型：DATETIME 和 TIMESTAMP。
|
||||
|
||||
### 1. DATETIME
|
||||
|
||||
能够保存从 1001 年到 9999 年的日期和时间，精度为秒，使用 8 字节的存储空间。
|
||||
|
||||
它与时区无关。
|
||||
|
||||
默认情况下，MySQL 以一种可排序的、无歧义的格式显示 DATETIME 值，例如“2008-01-16 22:37:08”，这是 ANSI 标准定义的日期和时间表示方法。
|
||||
|
||||
### 2. TIMESTAMP
|
||||
|
||||
和 UNIX 时间戳相同，保存从 1970 年 1 月 1 日午夜（格林威治时间）以来的秒数，使用 4 个字节，只能表示从 1970 年 到 2038 年。
|
||||
|
||||
它和时区有关，也就是说一个时间戳在不同的时区所代表的具体时间是不同的。
|
||||
|
||||
MySQL 提供了 FROM_UNIXTIME() 函数把 UNIX 时间戳转换为日期，并提供了 UNIX_TIMESTAMP() 函数把日期转换为 UNIX 时间戳。
|
||||
|
||||
默认情况下，如果插入时没有指定 TIMESTAMP 列的值，会将这个值设置为当前时间。
|
||||
|
||||
应该尽量使用 TIMESTAMP，因为它比 DATETIME 空间效率更高。
|
||||
|
||||
# 三、索引
|
||||
|
||||
索引能够轻易将查询性能提升几个数量级。
|
||||
|
||||
对于非常小的表、大部分情况下简单的全表扫描比建立索引更高效。对于中到大型的表，索引就非常有效。但是对于特大型的表，建立和维护索引的代价将会随之增长。这种情况下，需要用到一种技术可以直接区分出需要查询的一组数据，而不是一条记录一条记录地匹配，例如可以使用分区技术。
|
||||
|
||||
索引是在存储引擎层实现的，而不是在服务器层实现的，所以不同存储引擎具有不同的索引类型和实现。
|
||||
# 一、索引
|
||||
|
||||
## B+ Tree 原理
|
||||
|
||||
|
|
@ -141,37 +48,37 @@ B+ Tree 是基于 B Tree 和叶子节点顺序访问指针进行实现，它具
|
|||
|
||||
进行查找操作时，首先在根节点进行二分查找，找到一个 key 所在的指针，然后递归地在指针所指向的节点进行查找。直到查找到叶子节点，然后在叶子节点上进行二分查找，找出 key 所对应的 data。
|
||||
|
||||
插入删除操作记录会破坏平衡树的平衡性，因此在插入删除时，需要对树进行一个分裂、合并、旋转等操作。
|
||||
插入删除操作记录会破坏平衡树的平衡性，因此在插入删除操作之后，需要对树进行一个分裂、合并、旋转等操作来维护平衡性。
|
||||
|
||||
### 3. 与红黑树的比较
|
||||
|
||||
红黑树等平衡树也可以用来实现索引，但是文件系统及数据库系统普遍采用 B+ Tree 作为索引结构，主要有以下两个原因：
|
||||
|
||||
（一）更少的检索次数
|
||||
（一）更少的查找次数
|
||||
|
||||
平衡树检索数据的时间复杂度等于树高 h，而树高大致为 O(h)=O(log<sub>d</sub>N)，其中 d 为每个节点的出度。
|
||||
平衡树查找操作的时间复杂度等于树高 h，而树高大致为 O(h)=O(log<sub>d</sub>N)，其中 d 为每个节点的出度。
|
||||
|
||||
红黑树的出度为 2，而 B+ Tree 的出度一般都非常大。红黑树的树高 h 很明显比 B+ Tree 大非常多，因此检索的次数也就更多。
|
||||
红黑树的出度为 2，而 B+ Tree 的出度一般都非常大，所以红黑树的树高 h 很明显比 B+ Tree 大非常多，检索的次数也就更多。
|
||||
|
||||
（二）利用计算机预读特性
|
||||
|
||||
为了减少磁盘 I/O，磁盘往往不是严格按需读取，而是每次都会预读。这样做的理论依据是计算机科学中著名的局部性原理：当一个数据被用到时，其附近的数据也通常会马上被使用。预读过程中，磁盘进行顺序读取，顺序读取不需要进行磁盘寻道，并且只需要很短的旋转时间，因此速度会非常快。
|
||||
为了减少磁盘 I/O，磁盘往往不是严格按需读取，而是每次都会预读。预读过程中，磁盘进行顺序读取，顺序读取不需要进行磁盘寻道，并且只需要很短的旋转时间，因此速度会非常快。
|
||||
|
||||
操作系统一般将内存和磁盘分割成固态大小的块，每一块称为一页，内存与磁盘以页为单位交换数据。数据库系统将索引的一个节点的大小设置为页的大小，使得一次 I/O 就能完全载入一个节点，并且可以利用预读特性，相邻的节点也能够被预先载入。
|
||||
|
||||
## 索引分类
|
||||
## MySQL 索引
|
||||
|
||||
索引是在存储引擎层实现的，而不是在服务器层实现的，所以不同存储引擎具有不同的索引类型和实现。
|
||||
|
||||
### 1. B+Tree 索引
|
||||
|
||||
B+Tree 索引是大多数 MySQL 存储引擎的默认索引类型。
|
||||
是大多数 MySQL 存储引擎的默认索引类型。
|
||||
|
||||
因为不再需要进行全表扫描，只需要对树进行搜索即可，因此查找速度快很多。除了用于查找，还可以用于排序和分组。
|
||||
|
||||
可以指定多个列作为索引列，多个索引列共同组成键。
|
||||
|
||||
B+Tree 索引适用于全键值、键值范围和键前缀查找，其中键前缀查找只适用于最左前缀查找。
|
||||
|
||||
如果不是按照索引列的顺序进行查找，则无法使用索引。
|
||||
适用于全键值、键值范围和键前缀查找，其中键前缀查找只适用于最左前缀查找。如果不是按照索引列的顺序进行查找，则无法使用索引。
|
||||
|
||||
InnoDB 的 B+Tree 索引分为主索引和辅助索引。
|
||||
|
||||
|
|
@ -185,12 +92,12 @@ InnoDB 的 B+Tree 索引分为主索引和辅助索引。
|
|||
|
||||
### 2. 哈希索引
|
||||
|
||||
InnoDB 引擎有一个特殊的功能叫“自适应哈希索引”，当某个索引值被使用的非常频繁时，会在 B+Tree 索引之上再创建一个哈希索引，这样就让 B+Tree 索引具有哈希索引的一些优点，比如快速的哈希查找。
|
||||
|
||||
哈希索引能以 O(1) 时间进行查找，但是失去了有序性，它具有以下限制：
|
||||
|
||||
- 无法用于排序与分组；
|
||||
- 只支持精确查找，无法用于部分查找和范围查找；
|
||||
- 只支持精确查找，无法用于部分查找和范围查找。
|
||||
|
||||
InnoDB 存储引擎有一个特殊的功能叫“自适应哈希索引”，当某个索引值被使用的非常频繁时，会在 B+Tree 索引之上再创建一个哈希索引，这样就让 B+Tree 索引具有哈希索引的一些优点，比如快速的哈希查找。
|
||||
|
||||
### 3. 全文索引
|
||||
|
||||
|
|
@ -200,20 +107,12 @@ MyISAM 存储引擎支持全文索引，用于查找文本中的关键词，而
|
|||
|
||||
InnoDB 存储引擎在 MySQL 5.6.4 版本中也开始支持全文索引。
|
||||
|
||||
### 4. 空间数据索引（R-Tree）
|
||||
### 4. 空间数据索引
|
||||
|
||||
MyISAM 存储引擎支持空间数据索引，可以用于地理数据存储。空间数据索引会从所有维度来索引数据，可以有效地使用任意维度来进行组合查询。
|
||||
MyISAM 存储引擎支持空间数据索引（R-Tree），可以用于地理数据存储。空间数据索引会从所有维度来索引数据，可以有效地使用任意维度来进行组合查询。
|
||||
|
||||
必须使用 GIS 相关的函数来维护数据。
|
||||
|
||||
## 索引的优点
|
||||
|
||||
- 大大减少了服务器需要扫描的数据行数。
|
||||
|
||||
- 帮助服务器避免进行排序和创建临时表（B+Tree 索引是有序的，可以用来做 ORDER BY 和 GROUP BY 操作）；
|
||||
|
||||
- 将随机 I/O 变为顺序 I/O（B+Tree 索引是有序的，也就将相邻的数据都存储在一起）。
|
||||
|
||||
## 索引优化
|
||||
|
||||
### 1. 独立的列
|
||||
|
|
@ -266,11 +165,25 @@ customer_id_selectivity: 0.0373
|
|||
|
||||
具有以下优点：
|
||||
|
||||
- 因为索引条目通常远小于数据行的大小，所以若只读取索引，能大大减少数据访问量。
|
||||
- 索引通常远小于数据行的大小，只读取索引能大大减少数据访问量。
|
||||
- 一些存储引擎（例如 MyISAM）在内存中只缓存索引，而数据依赖于操作系统来缓存。因此，只访问索引可以不使用系统调用（通常比较费时）。
|
||||
- 对于 InnoDB 引擎，若辅助索引能够覆盖查询，则无需访问主索引。
|
||||
|
||||
# 四、查询性能优化
|
||||
## 索引的优点
|
||||
|
||||
- 大大减少了服务器需要扫描的数据行数。
|
||||
|
||||
- 帮助服务器避免进行排序和分组，也就不需要创建临时表（B+Tree 索引是有序的，可以用于 ORDER BY 和 GROUP BY 操作。临时表主要是在排序和分组过程中创建，因为不需要排序和分组，也就不需要创建临时表）。
|
||||
|
||||
- 将随机 I/O 变为顺序 I/O（B+Tree 索引是有序的，也就将相邻的数据都存储在一起）。
|
||||
|
||||
## 索引的使用场景
|
||||
|
||||
- 对于非常小的表、大部分情况下简单的全表扫描比建立索引更高效。
|
||||
- 对于中到大型的表，索引就非常有效。
|
||||
- 但是对于特大型的表，建立和维护索引的代价将会随之增长。这种情况下，需要用到一种技术可以直接区分出需要查询的一组数据，而不是一条记录一条记录地匹配，例如可以使用分区技术。
|
||||
|
||||
# 二、查询性能优化
|
||||
|
||||
## 使用 Explain 进行分析
|
||||
|
||||
|
|
@ -282,23 +195,13 @@ Explain 用来分析 SELECT 查询语句，开发人员可以通过分析 Explai
|
|||
- key : 使用的索引
|
||||
- rows : 扫描的行数
|
||||
|
||||
更多内容请参考：[MySQL 性能优化神器 Explain 使用分析](https://segmentfault.com/a/1190000008131735)
|
||||
|
||||
## 优化数据访问
|
||||
|
||||
### 1. 减少请求的数据量
|
||||
|
||||
（一）只返回必要的列
|
||||
|
||||
最好不要使用 SELECT * 语句。
|
||||
|
||||
（二）只返回必要的行
|
||||
|
||||
使用 WHERE 语句进行查询过滤，有时候也需要使用 LIMIT 语句来限制返回的数据。
|
||||
|
||||
（三）缓存重复查询的数据
|
||||
|
||||
使用缓存可以避免在数据库中进行查询，特别要查询的数据经常被重复查询，缓存可以带来的查询性能提升将会是非常明显的。
|
||||
- 只返回必要的列：最好不要使用 SELECT * 语句。
|
||||
- 只返回必要的行：使用 LIMIT 语句来限制返回的数据。
|
||||
- 缓存重复查询的数据：使用缓存可以避免在数据库中进行查询，特别在要查询的数据经常被重复查询时，缓存带来的查询性能提升将会是非常明显的。
|
||||
|
||||
### 2. 减少服务器端扫描的行数
|
||||
|
||||
|
|
@ -324,12 +227,12 @@ do {
|
|||
|
||||
### 2. 分解大连接查询
|
||||
|
||||
将一个大连接查询（JOIN）分解成对每一个表进行一次单表查询，然后将结果在应用程序中进行关联，这样做的好处有：
|
||||
将一个大连接查询分解成对每一个表进行一次单表查询，然后将结果在应用程序中进行关联，这样做的好处有：
|
||||
|
||||
- 让缓存更高效。对于连接查询，如果其中一个表发生变化，那么整个查询缓存就无法使用。而分解后的多个查询，即使其中一个表发生变化，对其它表的查询缓存依然可以使用。
|
||||
- 分解成多个单表查询，这些单表查询的缓存结果更可能被其它查询使用到，从而减少冗余记录的查询。
|
||||
- 减少锁竞争；
|
||||
- 在应用层进行连接，可以更容易对数据库进行拆分，从而更容易做到高性能和可扩展。
|
||||
- 在应用层进行连接，可以更容易对数据库进行拆分，从而更容易做到高性能和可伸缩。
|
||||
- 查询本身效率也可能会有所提升。例如下面的例子中，使用 IN() 代替连接查询，可以让 MySQL 按照 ID 顺序进行查询，这可能比随机的连接要更高效。
|
||||
|
||||
```sql
|
||||
|
|
@ -345,23 +248,111 @@ SELECT * FROM tag_post WHERE tag_id=1234;
|
|||
SELECT * FROM post WHERE post.id IN (123,456,567,9098,8904);
|
||||
```
|
||||
|
||||
# 三、存储引擎
|
||||
|
||||
## InnoDB
|
||||
|
||||
是 MySQL 默认的事务型存储引擎，只有在需要它不支持的特性时，才考虑使用其它存储引擎。
|
||||
|
||||
实现了四个标准的隔离级别，默认级别是可重复读（REPEATABLE READ）。在可重复读隔离级别下，通过多版本并发控制（MVCC）+ 间隙锁（Next-Key Locking）防止幻影读。
|
||||
|
||||
主索引是聚簇索引，在索引中保存了数据，从而避免直接读取磁盘，因此对查询性能有很大的提升。
|
||||
|
||||
内部做了很多优化，包括从磁盘读取数据时采用的可预测性读、能够加快读操作并且自动创建的自适应哈希索引、能够加速插入操作的插入缓冲区等。
|
||||
|
||||
支持真正的在线热备份。其它存储引擎不支持在线热备份，要获取一致性视图需要停止对所有表的写入，而在读写混合场景中，停止写入可能也意味着停止读取。
|
||||
|
||||
## MyISAM
|
||||
|
||||
设计简单，数据以紧密格式存储。对于只读数据，或者表比较小、可以容忍修复操作，则依然可以使用它。
|
||||
|
||||
提供了大量的特性，包括压缩表、空间数据索引等。
|
||||
|
||||
不支持事务。
|
||||
|
||||
不支持行级锁，只能对整张表加锁，读取时会对需要读到的所有表加共享锁，写入时则对表加排它锁。但在表有读取操作的同时，也可以往表中插入新的记录，这被称为并发插入（CONCURRENT INSERT）。
|
||||
|
||||
可以手工或者自动执行检查和修复操作，但是和事务恢复以及崩溃恢复不同，可能导致一些数据丢失，而且修复操作是非常慢的。
|
||||
|
||||
如果指定了 DELAY_KEY_WRITE 选项，在每次修改执行完成时，不会立即将修改的索引数据写入磁盘，而是会写到内存中的键缓冲区，只有在清理键缓冲区或者关闭表的时候才会将对应的索引块写入磁盘。这种方式可以极大的提升写入性能，但是在数据库或者主机崩溃时会造成索引损坏，需要执行修复操作。
|
||||
|
||||
## 比较
|
||||
|
||||
- 事务：InnoDB 是事务型的，可以使用 Commit 和 Rollback 语句。
|
||||
|
||||
- 并发：MyISAM 只支持表级锁，而 InnoDB 还支持行级锁。
|
||||
|
||||
- 外键：InnoDB 支持外键。
|
||||
|
||||
- 备份：InnoDB 支持在线热备份。
|
||||
|
||||
- 崩溃恢复：MyISAM 崩溃后发生损坏的概率比 InnoDB 高很多，而且恢复的速度也更慢。
|
||||
|
||||
- 其它特性：MyISAM 支持压缩表和空间数据索引。
|
||||
|
||||
# 四、数据类型
|
||||
|
||||
## 整型
|
||||
|
||||
TINYINT, SMALLINT, MEDIUMINT, INT, BIGINT 分别使用 8, 16, 24, 32, 64 位存储空间，一般情况下越小的列越好。
|
||||
|
||||
INT(11) 中的数字只是规定了交互工具显示字符的个数，对于存储和计算来说是没有意义的。
|
||||
|
||||
## 浮点数
|
||||
|
||||
FLOAT 和 DOUBLE 为浮点类型，DECIMAL 为高精度小数类型。CPU 原生支持浮点运算，但是不支持 DECIMAl 类型的计算，因此 DECIMAL 的计算比浮点类型需要更高的代价。
|
||||
|
||||
FLOAT、DOUBLE 和 DECIMAL 都可以指定列宽，例如 DECIMAL(18, 9) 表示总共 18 位，取 9 位存储小数部分，剩下 9 位存储整数部分。
|
||||
|
||||
## 字符串
|
||||
|
||||
主要有 CHAR 和 VARCHAR 两种类型，一种是定长的，一种是变长的。
|
||||
|
||||
VARCHAR 这种变长类型能够节省空间，因为只需要存储必要的内容。但是在执行 UPDATE 时可能会使行变得比原来长，当超出一个页所能容纳的大小时，就要执行额外的操作。MyISAM 会将行拆成不同的片段存储，而 InnoDB 则需要分裂页来使行放进页内。
|
||||
|
||||
VARCHAR 会保留字符串末尾的空格，而 CHAR 会删除。
|
||||
|
||||
## 时间和日期
|
||||
|
||||
MySQL 提供了两种相似的日期时间类型：DATETIME 和 TIMESTAMP。
|
||||
|
||||
### 1. DATETIME
|
||||
|
||||
能够保存从 1001 年到 9999 年的日期和时间，精度为秒，使用 8 字节的存储空间。
|
||||
|
||||
它与时区无关。
|
||||
|
||||
默认情况下，MySQL 以一种可排序的、无歧义的格式显示 DATETIME 值，例如“2008-01-16 22:37:08”，这是 ANSI 标准定义的日期和时间表示方法。
|
||||
|
||||
### 2. TIMESTAMP
|
||||
|
||||
和 UNIX 时间戳相同，保存从 1970 年 1 月 1 日午夜（格林威治时间）以来的秒数，使用 4 个字节，只能表示从 1970 年 到 2038 年。
|
||||
|
||||
它和时区有关，也就是说一个时间戳在不同的时区所代表的具体时间是不同的。
|
||||
|
||||
MySQL 提供了 FROM_UNIXTIME() 函数把 UNIX 时间戳转换为日期，并提供了 UNIX_TIMESTAMP() 函数把日期转换为 UNIX 时间戳。
|
||||
|
||||
默认情况下，如果插入时没有指定 TIMESTAMP 列的值，会将这个值设置为当前时间。
|
||||
|
||||
应该尽量使用 TIMESTAMP，因为它比 DATETIME 空间效率更高。
|
||||
|
||||
# 五、切分
|
||||
|
||||
## 水平切分
|
||||
|
||||
<div align="center"> <img src="../pics//63c2909f-0c5f-496f-9fe5-ee9176b31aba.jpg"/> </div><br>
|
||||
|
||||
水平切分又称为 Sharding，它是将同一个表中的记录拆分到多个结构相同的表中。
|
||||
|
||||
当一个表的数据不断增多时，Sharding 是必然的选择，它可以将数据分布到集群的不同节点上，从而缓存单个数据库的压力。
|
||||
|
||||
<div align="center"> <img src="../pics//63c2909f-0c5f-496f-9fe5-ee9176b31aba.jpg"/> </div><br>
|
||||
|
||||
## 垂直切分
|
||||
|
||||
<div align="center"> <img src="../pics//e130e5b8-b19a-4f1e-b860-223040525cf6.jpg"/> </div><br>
|
||||
|
||||
垂直切分是将一张表按列切分成多个表，通常是按照列的关系密集程度进行切分，也可以利用垂直切分将经常被使用的列和不经常被使用的列切分到不同的表中。
|
||||
|
||||
在数据库的层面使用垂直切分将按数据库中表的密集程度部署到不同的库中，例如将原来的电商数据库垂直切分成商品数据库 payDB、用户数据库 userDB 等。
|
||||
在数据库的层面使用垂直切分将按数据库中表的密集程度部署到不同的库中，例如将原来的电商数据库垂直切分成商品数据库、用户数据库等。
|
||||
|
||||
## Sharding 策略
|
||||
|
||||
|
|
@ -375,15 +366,15 @@ SELECT * FROM post WHERE post.id IN (123,456,567,9098,8904);
|
|||
|
||||
使用分布式事务来解决，比如 XA 接口。
|
||||
|
||||
### 2. JOIN
|
||||
### 2. 链接
|
||||
|
||||
可以将原来的 JOIN 查询分解成多个单表查询，然后在用户程序中进行 JOIN。
|
||||
可以将原来的 JOIN 分解成多个单表查询，然后在用户程序中进行 JOIN。
|
||||
|
||||
### 3. ID 唯一性
|
||||
|
||||
- 使用全局唯一 ID：GUID。
|
||||
- 为每个分片指定一个 ID 范围。
|
||||
- 分布式 ID 生成器 (如 Twitter 的 Snowflake 算法)。
|
||||
- 使用全局唯一 ID：GUID
|
||||
- 为每个分片指定一个 ID 范围
|
||||
- 分布式 ID 生成器 (如 Twitter 的 Snowflake 算法)
|
||||
|
||||
更多内容请参考：
|
||||
|
||||
|
|
@ -396,24 +387,24 @@ SELECT * FROM post WHERE post.id IN (123,456,567,9098,8904);
|
|||
|
||||
主要涉及三个线程：binlog 线程、I/O 线程和 SQL 线程。
|
||||
|
||||
- **binlog 线程** ：负责将主服务器上的数据更改写入二进制文件（binlog）中。
|
||||
- **I/O 线程** ：负责从主服务器上读取二进制日志文件，并写入从服务器的中继日志中。
|
||||
- **binlog 线程** ：负责将主服务器上的数据更改写入二进制日志中。
|
||||
- **I/O 线程** ：负责从主服务器上读取二进制日志，并写入从服务器的中继日志中。
|
||||
- **SQL 线程** ：负责读取中继日志并重放其中的 SQL 语句。
|
||||
|
||||
<div align="center"> <img src="../pics//master-slave.png"/> </div><br>
|
||||
|
||||
## 读写分离
|
||||
|
||||
主服务器用来处理写操作以及实时性要求比较高的读操作，而从服务器用来处理读操作。
|
||||
主服务器处理写操作以及实时性要求比较高的读操作，而从服务器处理读操作。
|
||||
|
||||
读写分离常用代理方式来实现，代理服务器接收应用层传来的读写请求，然后决定转发到哪个服务器。
|
||||
|
||||
MySQL 读写分离能提高性能的原因在于：
|
||||
读写分离能提高性能的原因在于：
|
||||
|
||||
- 主从服务器负责各自的读和写，极大程度缓解了锁的争用；
|
||||
- 从服务器可以配置 MyISAM 引擎，提升查询性能以及节约系统开销；
|
||||
- 从服务器可以使用 MyISAM，提升查询性能以及节约系统开销；
|
||||
- 增加冗余，提高可用性。
|
||||
|
||||
读写分离常用代理方式来实现，代理服务器接收应用层传来的读写请求，然后决定转发到哪个服务器。
|
||||
|
||||
<div align="center"> <img src="../pics//master-slave-proxy.png"/> </div><br>
|
||||
|
||||
# 参考资料
|
||||
|
|
@ -425,3 +416,4 @@ MySQL 读写分离能提高性能的原因在于：
|
|||
- [How to create unique row ID in sharded databases?](https://stackoverflow.com/questions/788829/how-to-create-unique-row-id-in-sharded-databases)
|
||||
- [SQL Azure Federation – Introduction](http://geekswithblogs.net/shaunxu/archive/2012/01/07/sql-azure-federation-ndash-introduction.aspx "Title of this entry.")
|
||||
- [MySQL 索引背后的数据结构及算法原理](http://blog.codinglabs.org/articles/theory-of-mysql-index.html)
|
||||
- [MySQL 性能优化神器 Explain 使用分析](https://segmentfault.com/a/1190000008131735)
|
||||
|
|
|
|||
|
|
@ -49,7 +49,7 @@
|
|||
|
||||
Redis 是速度非常快的非关系型（NoSQL）内存键值数据库，可以存储键和五种不同类型的值之间的映射。
|
||||
|
||||
键的类型只能为字符串，值支持的五种类型数据类型为：字符串、列表、集合、有序集合、散列表。
|
||||
键的类型只能为字符串，值支持的五种类型数据类型为：字符串、列表、集合、散列表、有序集合。
|
||||
|
||||
Redis 支持很多特性，例如将内存中的数据持久化到硬盘中，使用复制来扩展读性能，使用分片来扩展写性能。
|
||||
|
||||
|
|
@ -58,7 +58,7 @@ Redis 支持很多特性，例如将内存中的数据持久化到硬盘中，
|
|||
| 数据类型 | 可以存储的值 | 操作 |
|
||||
| :--: | :--: | :--: |
|
||||
| STRING | 字符串、整数或者浮点数 | 对整个字符串或者字符串的其中一部分执行操作</br> 对整数和浮点数执行自增或者自减操作 |
|
||||
| LIST | 列表 | 从两端压入或者弹出元素</br> 读取单个或者多个元素</br> 进行修剪，只保留一个范围内的元素 |
|
||||
| LIST | 列表 | 从两端压入或者弹出元素</br> 对单个或者多个元素</br> 进行修剪，只保留一个范围内的元素 |
|
||||
| SET | 无序集合 | 添加、获取、移除单个元素</br> 检查一个元素是否存在于集合中</br> 计算交集、并集、差集</br> 从集合里面随机获取元素 |
|
||||
| HASH | 包含键值对的无序散列表 | 添加、获取、移除单个键值对</br> 获取所有键值对</br> 检查某个键是否存在|
|
||||
| ZSET | 有序集合 | 添加、获取、删除元素</br> 根据分值范围或者成员来获取元素</br> 计算一个键的排名 |
|
||||
|
|
@ -555,7 +555,7 @@ Sentinel（哨兵）可以监听主服务器，并在主服务器进入下线状
|
|||
|
||||
分片是将数据划分为多个部分的方法，可以将数据存储到多台机器里面，这种方法在解决某些问题时可以获得线性级别的性能提升。
|
||||
|
||||
假设有 4 个 Reids 实例 R0，R1，R2，R3，还有很多表示用户的键 user:1，user:2，... 等等，有不同的方式来选择一个指定的键存储在哪个实例中。
|
||||
假设有 4 个 Reids 实例 R0，R1，R2，R3，还有很多表示用户的键 user:1，user:2，... ，有不同的方式来选择一个指定的键存储在哪个实例中。
|
||||
|
||||
- 最简单的方式是范围分片，例如用户 id 从 0\~1000 的存储到实例 R0 中，用户 id 从 1001\~2000 的存储到实例 R1 中，等等。但是这样需要维护一张映射范围表，维护操作代价很高。
|
||||
- 还有一种方式是哈希分片，使用 CRC32 哈希函数将键转换为一个数字，再对实例数量求模就能知道应该存储的实例。
|
||||
|
|
|
|||
|
|
@ -20,6 +20,7 @@
|
|||
* [可串行化（SERIALIZABLE）](#可串行化serializable)
|
||||
* [五、多版本并发控制](#五多版本并发控制)
|
||||
* [版本号](#版本号)
|
||||
* [隐藏的列](#隐藏的列)
|
||||
* [Undo 日志](#undo-日志)
|
||||
* [实现过程](#实现过程)
|
||||
* [快照读与当前读](#快照读与当前读)
|
||||
|
|
@ -58,9 +59,7 @@
|
|||
|
||||
### 2. 一致性（Consistency）
|
||||
|
||||
数据库在事务执行前后都保持一致性状态。
|
||||
|
||||
在一致性状态下，所有事务对一个数据的读取结果都是相同的。
|
||||
数据库在事务执行前后都保持一致性状态。在一致性状态下，所有事务对一个数据的读取结果都是相同的。
|
||||
|
||||
### 3. 隔离性（Isolation）
|
||||
|
||||
|
|
@ -78,10 +77,10 @@
|
|||
|
||||
- 只有满足一致性，事务的执行结果才是正确的。
|
||||
- 在无并发的情况下，事务串行执行，隔离性一定能够满足。此时只要能满足原子性，就一定能满足一致性。
|
||||
- 在并发的情况下，多个事务并发执行，事务不仅要满足原子性，还需要满足隔离性，才能满足一致性。
|
||||
- 在并发的情况下，多个事务并行执行，事务不仅要满足原子性，还需要满足隔离性，才能满足一致性。
|
||||
- 事务满足持久化是为了能应对数据库崩溃的情况。
|
||||
|
||||
<div align="center"> <img src="../pics//a58e294a-615d-4ea0-9fbf-064a6daec4b2.png" width="400"/> </div><br>
|
||||
<div align="center"> <img src="../pics//a58e294a-615d-4ea0-9fbf-064a6daec4b2.png" width="450"/> </div><br>
|
||||
|
||||
## AUTOCOMMIT
|
||||
|
||||
|
|
@ -95,25 +94,25 @@ MySQL 默认采用自动提交模式。也就是说，如果不显式使用`STAR
|
|||
|
||||
T<sub>1</sub> 和 T<sub>2</sub> 两个事务都对一个数据进行修改，T<sub>1</sub> 先修改，T<sub>2</sub> 随后修改，T<sub>2</sub> 的修改覆盖了 T<sub>1</sub> 的修改。
|
||||
|
||||
<div align="center"> <img src="../pics//88ff46b3-028a-4dbb-a572-1f062b8b96d3.png" width="300"/> </div><br>
|
||||
<div align="center"> <img src="../pics//88ff46b3-028a-4dbb-a572-1f062b8b96d3.png" width="350"/> </div><br>
|
||||
|
||||
## 读脏数据
|
||||
|
||||
T<sub>1</sub> 修改一个数据，T<sub>2</sub> 随后读取这个数据。如果 T<sub>1</sub> 撤销了这次修改，那么 T<sub>2</sub> 读取的数据是脏数据。
|
||||
|
||||
<div align="center"> <img src="../pics//dd782132-d830-4c55-9884-cfac0a541b8e.png" width="300"/> </div><br>
|
||||
<div align="center"> <img src="../pics//dd782132-d830-4c55-9884-cfac0a541b8e.png" width="400"/> </div><br>
|
||||
|
||||
## 不可重复读
|
||||
|
||||
T<sub>2</sub> 读取一个数据，T<sub>1</sub> 对该数据做了修改。如果 T<sub>2</sub> 再次读取这个数据，此时读取的结果和第一次读取的结果不同。
|
||||
|
||||
<div align="center"> <img src="../pics//c8d18ca9-0b09-441a-9a0c-fb063630d708.png" width="300"/> </div><br>
|
||||
<div align="center"> <img src="../pics//c8d18ca9-0b09-441a-9a0c-fb063630d708.png" width="350"/> </div><br>
|
||||
|
||||
## 幻影读
|
||||
|
||||
T<sub>1</sub> 读取某个范围的数据，T<sub>2</sub> 在这个范围内插入新的数据，T<sub>1</sub> 再次读取这个范围的数据，此时读取的结果和和第一次读取的结果不同。
|
||||
|
||||
<div align="center"> <img src="../pics//72fe492e-f1cb-4cfc-92f8-412fb3ae6fec.png" width="300"/> </div><br>
|
||||
<div align="center"> <img src="../pics//72fe492e-f1cb-4cfc-92f8-412fb3ae6fec.png" width="350"/> </div><br>
|
||||
|
||||
----
|
||||
|
||||
|
|
@ -123,7 +122,6 @@ T<sub>1</sub> 读取某个范围的数据，T<sub>2</sub> 在这个范围内插
|
|||
|
||||
## 封锁粒度
|
||||
|
||||
|
||||
MySQL 中提供了两种封锁粒度：行级锁以及表级锁。
|
||||
|
||||
应该尽量只锁定需要修改的那部分数据，而不是所有的资源。锁定的数据量越少，发生锁争用的可能就越小，系统的并发程度就越高。
|
||||
|
|
@ -150,8 +148,8 @@ MySQL 中提供了两种封锁粒度：行级锁以及表级锁。
|
|||
|
||||
| - | X | S |
|
||||
| :--: | :--: | :--: |
|
||||
|X|NO|NO|
|
||||
|S|NO|YES|
|
||||
|X|×|×|
|
||||
|S|×|√|
|
||||
|
||||
### 2. 意向锁
|
||||
|
||||
|
|
@ -170,10 +168,10 @@ MySQL 中提供了两种封锁粒度：行级锁以及表级锁。
|
|||
|
||||
| - | X | IX | S | IS |
|
||||
| :--: | :--: | :--: | :--: | :--: |
|
||||
|X |NO |NO |NO | NO|
|
||||
|IX |NO |YES |NO | YES|
|
||||
|S |NO |NO |YES | YES|
|
||||
|IS |NO |YES |YES | YES|
|
||||
|X |× |× |× | ×|
|
||||
|IX |× |√ |× | √|
|
||||
|S |× |× |√ | √|
|
||||
|IS |× |√ |√ | √|
|
||||
|
||||
解释如下：
|
||||
|
||||
|
|
@ -298,32 +296,30 @@ SELECT ... FOR UPDATE;
|
|||
|
||||
| 隔离级别 | 脏读 | 不可重复读 | 幻影读 |
|
||||
| :---: | :---: | :---:| :---: |
|
||||
| 未提交读 | YES | YES | YES |
|
||||
| 提交读 | NO | YES | YES |
|
||||
| 可重复读 | NO | NO | YES |
|
||||
| 可串行化 | NO | NO | NO |
|
||||
| 未提交读 | √ | √ | √ |
|
||||
| 提交读 | × | √ | √ |
|
||||
| 可重复读 | × | × | √ |
|
||||
| 可串行化 | × | × | × |
|
||||
|
||||
# 五、多版本并发控制
|
||||
|
||||
多版本并发控制（Multi-Version Concurrency Control, MVCC）是 MySQL 的 InnoDB 存储引擎实现隔离级别的一种具体方式，用于实现提交读和可重复读这两种隔离级别。
|
||||
|
||||
而未提交读隔离级别总是读取最新的数据行，无需使用 MVCC。
|
||||
|
||||
可串行化隔离级别需要对所有读取的行都加锁，单纯使用 MVCC 无法实现。
|
||||
多版本并发控制（Multi-Version Concurrency Control, MVCC）是 MySQL 的 InnoDB 存储引擎实现隔离级别的一种具体方式，用于实现提交读和可重复读这两种隔离级别。而未提交读隔离级别总是读取最新的数据行，无需使用 MVCC。可串行化隔离级别需要对所有读取的行都加锁，单纯使用 MVCC 无法实现。
|
||||
|
||||
## 版本号
|
||||
|
||||
- 系统版本号：是一个递增的数字，每开始一个新的事务，系统版本号就会自动递增。
|
||||
- 事务版本号：事务开始时的系统版本号。
|
||||
|
||||
InooDB 的 MVCC 在每行记录后面都保存着两个隐藏的列，用来存储两个版本号：
|
||||
## 隐藏的列
|
||||
|
||||
MVCC 在每行记录后面都保存着两个隐藏的列，用来存储两个版本号：
|
||||
|
||||
- 创建版本号：指示创建一个数据行的快照时的系统版本号；
|
||||
- 删除版本号：如果该快照的删除版本号大于当前事务版本号表示该快照有效，否则表示该快照已经被删除了。
|
||||
|
||||
## Undo 日志
|
||||
|
||||
InnoDB 的 MVCC 使用到的快照存储在 Undo 日志中，该日志通过回滚指针把一个数据行（Record）的所有快照连接起来。
|
||||
MVCC 使用到的快照存储在 Undo 日志中，该日志通过回滚指针把一个数据行（Record）的所有快照连接起来。
|
||||
|
||||
<div align="center"> <img src="../pics//e41405a8-7c05-4f70-8092-e961e28d3112.jpg" width=""/> </div><br>
|
||||
|
||||
|
|
@ -331,15 +327,13 @@ InnoDB 的 MVCC 使用到的快照存储在 Undo 日志中，该日志通过回
|
|||
|
||||
以下实现过程针对可重复读隔离级别。
|
||||
|
||||
### 1. SELECT
|
||||
|
||||
当开始新一个事务时，该事务的版本号肯定会大于当前所有数据行快照的创建版本号，理解这一点很关键。
|
||||
|
||||
### 1. SELECT
|
||||
|
||||
多个事务必须读取到同一个数据行的快照，并且这个快照是距离现在最近的一个有效快照。但是也有例外，如果有一个事务正在修改该数据行，那么它可以读取事务本身所做的修改，而不用和其它事务的读取结果一致。
|
||||
|
||||
把没有对一个数据行做修改的事务称为 T，T 所要读取的数据行快照的创建版本号必须小于 T 的版本号，因为如果大于或者等于 T 的版本号，那么表示该数据行快照是其它事务的最新修改，因此不能去读取它。
|
||||
|
||||
除了上面的要求，T 所要读取的数据行快照的删除版本号必须大于 T 的版本号，因为如果小于等于 T 的版本号，那么表示该数据行快照是已经被删除的，不应该去读取它。
|
||||
把没有对一个数据行做修改的事务称为 T，T 所要读取的数据行快照的创建版本号必须小于 T 的版本号，因为如果大于或者等于 T 的版本号，那么表示该数据行快照是其它事务的最新修改，因此不能去读取它。除此之外，T 所要读取的数据行快照的删除版本号必须大于 T 的版本号，因为如果小于等于 T 的版本号，那么表示该数据行快照是已经被删除的，不应该去读取它。
|
||||
|
||||
### 2. INSERT
|
||||
|
||||
|
|
@ -385,7 +379,7 @@ MVCC 不能解决幻读的问题，Next-Key Locks 就是为了解决这个问题
|
|||
|
||||
锁定一个记录上的索引，而不是记录本身。
|
||||
|
||||
如果表没有设置索引，InnoDB 会自动在主键上创建隐藏的聚集索引，因此 Record Locks 依然可以使用。
|
||||
如果表没有设置索引，InnoDB 会自动在主键上创建隐藏的聚簇索引，因此 Record Locks 依然可以使用。
|
||||
|
||||
## Gap Locks
|
||||
|
||||
|
|
@ -397,7 +391,7 @@ SELECT c FROM t WHERE c BETWEEN 10 and 20 FOR UPDATE;
|
|||
|
||||
## Next-Key Locks
|
||||
|
||||
它是 Record Locks 和 Gap Locks 的结合，不仅锁定一个记录上的索引，也锁定范围内的索引。例如一个索引包含以下值：10, 11, 13, and 20，那么就需要锁定以下区间：
|
||||
它是 Record Locks 和 Gap Locks 的结合，不仅锁定一个记录上的索引，也锁定索引之间的间隙。例如一个索引包含以下值：10, 11, 13, and 20，那么就需要锁定以下区间：
|
||||
|
||||
```sql
|
||||
(negative infinity, 10]
|
||||
|
|
@ -432,10 +426,10 @@ SELECT c FROM t WHERE c BETWEEN 10 and 20 FOR UPDATE;
|
|||
|
||||
不符合范式的关系，会产生很多异常，主要有以下四种异常：
|
||||
|
||||
- 冗余数据：例如 学生-2 出现了两次。
|
||||
- 冗余数据：例如 `学生-2` 出现了两次。
|
||||
- 修改异常：修改了一个记录中的信息，但是另一个记录中相同的信息却没有被修改。
|
||||
- 删除异常：删除一个信息，那么也会丢失其它信息。例如如果删除了 课程-1，需要删除第一行和第三行，那么 学生-1 的信息就会丢失。
|
||||
- 插入异常，例如想要插入一个学生的信息，如果这个学生还没选课，那么就无法插入。
|
||||
- 删除异常：删除一个信息，那么也会丢失其它信息。例如删除了 `课程-1` 需要删除第一行和第三行，那么 `学生-1` 的信息就会丢失。
|
||||
- 插入异常：例如想要插入一个学生的信息，如果这个学生还没选课，那么就无法插入。
|
||||
|
||||
## 范式
|
||||
|
||||
|
|
@ -506,7 +500,11 @@ Sname, Sdept 和 Mname 都部分依赖于键码，当一个学生选修了多门
|
|||
|
||||
非主属性不传递函数依赖于键码。
|
||||
|
||||
上面的 关系-1 中存在以下传递函数依赖：Sno -> Sdept -> Mname，可以进行以下分解：
|
||||
上面的 关系-1 中存在以下传递函数依赖：
|
||||
|
||||
- Sno -> Sdept -> Mname
|
||||
|
||||
可以进行以下分解：
|
||||
|
||||
关系-11
|
||||
|
||||
|
|
@ -533,13 +531,19 @@ Entity-Relationship，有三个组成部分：实体、属性、联系。
|
|||
|
||||
包含一对一，一对多，多对多三种。
|
||||
|
||||
如果 A 到 B 是一对多关系，那么画个带箭头的线段指向 B；如果是一对一，画两个带箭头的线段；如果是多对多，画两个不带箭头的线段。下图的 Course 和 Student 是一对多的关系。
|
||||
- 如果 A 到 B 是一对多关系，那么画个带箭头的线段指向 B；
|
||||
- 如果是一对一，画两个带箭头的线段；
|
||||
- 如果是多对多，画两个不带箭头的线段。
|
||||
|
||||
下图的 Course 和 Student 是一对多的关系。
|
||||
|
||||
<div align="center"> <img src="../pics//292b4a35-4507-4256-84ff-c218f108ee31.jpg" width=""/> </div><br>
|
||||
|
||||
## 表示出现多次的关系
|
||||
|
||||
一个实体在联系出现几次，就要用几条线连接。下图表示一个课程的先修关系，先修关系出现两个 Course 实体，第一个是先修课程，后一个是后修课程，因此需要用两条线来表示这种关系。
|
||||
一个实体在联系出现几次，就要用几条线连接。
|
||||
|
||||
下图表示一个课程的先修关系，先修关系出现两个 Course 实体，第一个是先修课程，后一个是后修课程，因此需要用两条线来表示这种关系。
|
||||
|
||||
<div align="center"> <img src="../pics//8b798007-e0fb-420c-b981-ead215692417.jpg" width=""/> </div><br>
|
||||
|
||||
|
|
@ -549,7 +553,7 @@ Entity-Relationship，有三个组成部分：实体、属性、联系。
|
|||
|
||||
<div align="center"> <img src="../pics//423f2a40-bee1-488e-b460-8e76c48ee560.png" width=""/> </div><br>
|
||||
|
||||
一般只使用二元联系，可以把多元关系转换为二元关系。
|
||||
一般只使用二元联系，可以把多元联系转换为二元联系。
|
||||
|
||||
<div align="center"> <img src="../pics//de9b9ea0-1327-4865-93e5-6f805c48bc9e.png" width=""/> </div><br>
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue
Block a user