mysql高级

时间 2019-11-21

标签 mysql 高级栏目 MySQL 繁體版

原文原文链接

1、存储引擎
- InnoDB
- MyISAM
- 比较
2、数据类型
- 整型
- 浮点数
- 字符串
- 时间和日期
3、索引
- 索引分类
- 索引的优势
- 索引优化
- B-Tree 和 B+Tree 原理
4、查询性能优化
5、切分
- 垂直切分
- 水平切分
- 切分的选择
- 存在的问题
6、故障转移和故障恢复
参考资料

1、存储引擎

InnoDB

InnoDB 是 MySQL 默认的事务型存储引擎，只有在须要 InnoDB 不支持的特性时，才考虑使用其它存储引擎。html

采用 MVCC 来支持高并发，而且实现了四个标准的隔离级别，默认级别是可重复读（REPEATABLE READ），而且经过间隙锁（next-key locking）策略防止幻读的出现。间隙锁使得 InnoDB 不只仅锁定查询涉及的行，还会对索引中的间隙进行锁定，以防止幻影行的插入。mysql

表是基于聚簇索引创建的，它对主键的查询性能有很高的提高。算法

内部作了不少优化，包括从磁盘读取数据时采用的可预测性读、可以自动在内存中建立哈希索引以加速读操做的自适应哈希索引、可以加速插入操做的插入缓冲区等。sql

经过一些机制和工具支持真正的热备份。其它存储引擎不支持热备份，要获取一致性视图须要中止对全部表的写入，而在读写混合场景中，中止写入可能也意味着中止读取。数据库

MyISAM

MyISAM 提供了大量的特性，包括全文索引、压缩表、空间数据索引等。应该注意的是，MySQL 5.6.4 也添加了对 InnoDB 存储引擎的全文索引支持。编程

不支持事务。缓存

不支持行级锁，只能对整张表加锁，读取时会对须要读到的全部表加共享锁，写入时则对表加排它锁。但在表有读取查询的同时，也能够往表中插入新的记录，这被称为并发插入（CONCURRENT INSERT）。性能优化

能够手工或者自动执行检查和修复操做，可是和事务恢复以及崩溃恢复不一样，可能致使一些数据丢失，并且修复操做是很是慢的。服务器

若是指定了 DELAYKEYWRITE 选项，在每次修改执行完成时，不会当即将修改的索引数据写入磁盘，而是会写到内存中的键缓冲区，只有在清理键缓冲区或者关闭表的时候才会将对应的索引块写入磁盘。这种方式能够极大的提高写入性能，可是在数据库或者主机崩溃时会形成索引损坏，须要执行修复操做。数据结构

MyISAM 设计简单，数据以紧密格式存储。对于只读数据，或者表比较小、能够容忍修复操做，则依然能够继续使用 MyISAM。

比较

事务：InnoDB 是事务型的。
备份：InnoDB 支持在线热备份。
崩溃恢复：MyISAM 崩溃后发生损坏的几率比 InnoDB 高不少，并且恢复的速度也更慢。
并发：MyISAM 只支持表级锁，而 InnoDB 还支持行级锁。
其它特性：MyISAM 支持压缩表和空间数据索引。

2、数据类型

整型

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 提供了两种类似的日期时间类型：DATATIME 和 TIMESTAMP。

1. DATATIME

可以保存从 1001 年到 9999 年的日期和时间，精度为秒，使用 8 字节的存储空间。

它与时区无关。

默认状况下，MySQL 以一种可排序的、无歧义的格式显示 DATATIME 值，例如“2008-01-16 22:37:08”，这是 ANSI 标准定义的日期和时间表示方法。

2. TIMESTAMP

和 UNIX 时间戳相同，保存从 1970 年 1 月 1 日午夜（格林威治时间）以来的秒数，使用 4 个字节，只能表示从 1970 年到 2038 年。

它和时区有关。

MySQL 提供了 FROMUNIXTIME() 函数把 UNIX 时间戳转换为日期，并提供了 UNIXTIMESTAMP() 函数把日期转换为 UNIX 时间戳。

默认状况下，若是插入时没有指定 TIMESTAMP 列的值，会将这个值设置为当前时间。

应该尽可能使用 TIMESTAMP，由于它比 DATETIME 空间效率更高。

3、索引

索引是在存储引擎层实现的，而不是在服务器层实现的，因此不一样存储引擎具备不一样的索引类型和实现。

索引可以轻易将查询性能提高几个数量级。

对于很是小的表、大部分状况下简单的全表扫描比创建索引更高效。对于中到大型的表，索引就很是有效。可是对于特大型的表，创建和使用索引的代价将会随之增加。这种状况下，须要用到一种技术能够直接区分出须要查询的一组数据，而不是一条记录一条记录地匹配，例如可使用分区技术。

索引分类

1. B+Tree 索引

《高性能 MySQL》一书使用 B-Tree 进行描述，其实从技术上来讲这种索引是 B+Tree。

B+Tree 索引是大多数 MySQL 存储引擎的默认索引类型。

由于再也不须要进行全表扫描，只须要对树进行搜索便可，所以查找速度快不少。

能够指定多个列做为索引列，多个索引列共同组成键。B+Tree 索引适用于全键值、键值范围和键前缀查找，其中键前缀查找只适用于最左前缀查找。

除了用于查找，还能够用于排序和分组。

若是不是按照索引列的顺序进行查找，则没法使用索引。

2. 哈希索引

基于哈希表实现，优势是查找很是快。

在 MySQL 中只有 Memory 引擎显式支持哈希索引。

InnoDB 引擎有一个特殊的功能叫“自适应哈希索引”，当某个索引值被使用的很是频繁时，会在 B+Tree 索引之上再建立一个哈希索引，这样就让 B+Tree 索引具备哈希索引的一些优势，好比快速的哈希查找。

限制：

哈希索引只包含哈希值和行指针，而不存储字段值，因此不能使用索引中的值来避免读取行。不过，访问内存中的行的速度很快，因此大部分状况下这一点对性能影响并不明显；
没法用于分组与排序；
只支持精确查找，没法用于部分查找和范围查找；
若是哈希冲突不少，查找速度会变得很慢。

3. 空间数据索引（R-Tree）

MyISAM 存储引擎支持空间索引，能够用于地理数据存储。

空间索引会从全部维度来索引数据，能够有效地使用任意维度来进行组合查询。

必须使用 GIS 相关的函数来维护数据。

4. 全文索引

MyISAM 存储引擎支持全文索引，用于查找文本中的关键词，而不是直接比较索引中的值。

使用 MATCH AGAINST，而不是普通的 WHERE。

索引的优势

大大减小了服务器须要扫描的数据量；
帮助服务器避免进行排序和建立临时表（B+Tree 索引是有序的，能够用来作 ORDER BY 和 GROUP BY 操做）；
将随机 I/O 变为顺序 I/O（B+Tree 索引是有序的，也就将相邻的列值都存储在一块儿）。

索引优化

1. 独立的列

在进行查询时，索引列不能是表达式的一部分，也不能是函数的参数，不然没法使用索引。

例以下面的查询不能使用 actor_id 列的索引：

SELECT actor_id FROM sakila.actor WHERE actor_id + 1 = 5;

2. 前缀索引

对于 BLOB、TEXT 和 VARCHAR 类型的列，必须使用前缀索引，只索引开始的部分字符。

对于前缀长度的选取须要根据 索引选择性 来肯定：不重复的索引值和记录总数的比值。选择性越高，查询效率也越高。最大值为 1，此时每一个记录都有惟一的索引与其对应。

3. 多列索引

在须要使用多个列做为条件进行查询时，使用多列索引比使用多个单列索引性能更好。例以下面的语句中，最好把 actorid 和 filmid 设置为多列索引。

SELECT film_id, actor_id FROM sakila.film_actor
WhERE actor_id = 1 AND film_id = 1;

4. 索引列的顺序

让选择性最强的索引列放在前面，例以下面显示的结果中 customerid 的选择性比 staffid 更高，所以最好把 customer_id 列放在多列索引的前面。

SELECT COUNT(DISTINCT staff_id)/COUNT(*) AS staff_id_selectivity,
COUNT(DISTINCT customer_id)/COUNT(*) AS customer_id_selectivity,
COUNT(*)
FROM payment;

staff_id_selectivity: 0.0001
customer_id_selectivity: 0.0373
               COUNT(*): 16049

5. 聚簇索引

聚簇索引并非一种索引类型，而是一种数据存储方式。

术语“聚簇”表示数据行和相邻的键值紧密地存储在一块儿，InnoDB 的聚簇索引在同一个结构中保存了 B+Tree 索引和数据行。

由于没法把数据行存放在两个不一样的地方，因此一个表只能有一个聚簇索引。

优势

能够把相关数据保存在一块儿，减小 I/O 操做。例如电子邮件表能够根据用户 ID 来汇集数据，这样只须要从磁盘读取少数的数据也就能获取某个用户的所有邮件，若是没有使用聚聚簇索引，则每封邮件均可能致使一次磁盘 I/O。
数据访问更快。

缺点

聚簇索引最大限度提升了 I/O 密集型应用的性能，可是若是数据所有放在内存，就不必用聚簇索引。
插入速度严重依赖于插入顺序，按主键的顺序插入是最快的。
更新操做代价很高，由于每一个被更新的行都会移动到新的位置。
当插入到某个已满的页中，存储引擎会将该页分裂成两个页面来容纳该行，页分裂会致使表占用更多的磁盘空间。
若是行比较稀疏，或者因为页分裂致使数据存储不连续时，聚簇索引可能致使全表扫描速度变慢。

6. 覆盖索引

索引包含全部须要查询的字段的值。

优势

由于索引条目一般远小于数据行的大小，因此若只读取索引，能大大减小数据访问量。
一些存储引擎（例如 MyISAM）在内存中只缓存索引，而数据依赖于操做系统来缓存。所以，只访问索引能够不使用系统调用（一般比较费时）。
对于 InnoDB 引擎，若二级索引可以覆盖查询，则无需访问聚簇索引。

B-Tree 和 B+Tree 原理

1. B-Tree

为了描述 B-Tree，首先定义一条数据记录为一个二元组 [key, data]。

B-Tree 是知足下列条件的数据结构：

全部叶节点具备相同的深度，也就是说 B-Tree 是平衡的；
一个节点中的 key 从左到右非递减排列；
若是某个指针的左右相邻 key 分别是 keyi 和 keyi+1，且不为 null，则该指针指向节点的全部 key 大于等于 keyi 且小于等于 keyi+1。

在 B-Tree 中按 key 检索数据的算法很是直观：首先在根节点进行二分查找，若是找到则返回对应节点的 data，不然在相应区间的指针指向的节点递归进行查找。

因为插入删除新的数据记录会破坏 B-Tree 的性质，所以在插入删除时，须要对树进行一个分裂、合并、转移等操做以保持 B-Tree 性质。

2. B+Tree

与 B-Tree 相比，B+Tree 有如下不一样点：

每一个节点的指针上限为 2d 而不是 2d+1；
内节点不存储 data，只存储 key，叶子节点不存储指针。

3. 带有顺序访问指针的 B+Tree

通常在数据库系统或文件系统中使用的 B+Tree 结构都在经典 B+Tree 基础上进行了优化，在叶子节点增长了顺序访问指针，作这个优化的目的是为了提升区间访问的性能。

4. 为何使用 B-Tree 和 B+Tree

红黑树等数据结构也能够用来实现索引，可是文件系统及数据库系统广泛采用 B-/+Tree 做为索引结构。

页是计算机管理存储器的逻辑块，硬件及操做系统每每将主存和磁盘存储区分割为连续的大小相等的块，每一个存储块称为一页（在许多操做系统中，页的大小一般为 4k），主存和磁盘以页为单位交换数据。

通常来讲，索引自己也很大，不可能所有存储在内存中，所以索引每每以索引文件的形式存储的磁盘上。为了减小磁盘 I/O，磁盘每每不是严格按需读取，而是每次都会预读。这样作的理论依据是计算机科学中著名的局部性原理：当一个数据被用到时，其附近的数据也一般会立刻被使用。数据库系统的设计者巧妙利用了磁盘预读原理，将一个节点的大小设为等于一个页，这样每一个节点只须要一次 I/O 就能够彻底载入。

B-Tree 中一次检索最多须要 h-1 次 I/O（根节点常驻内存），渐进复杂度为 O(h)=O(logdN)。通常实际应用中，出度 d 是很是大的数字，一般超过 100，所以 h 很是小（一般不超过 3）。而红黑树这种结构，h 明显要深的多。而且于逻辑上很近的节点（父子）物理上可能很远，没法利用局部性，效率明显比 B-Tree 差不少。

B+Tree 更适合外存索引，缘由和内节点出度 d 有关。因为 B+Tree 内节点去掉了 data 域，所以能够拥有更大的出度，拥有更好的性能。

4、查询性能优化

Explain

用来分析 SQL 语句，分析结果中比较重要的字段有：

select_type : 查询类型，有简单查询、联合查询和子查询
key : 使用的索引
rows : 扫描的行数

减小返回的列

慢查询主要是由于访问了过多数据，除了访问过多行以外，也包括访问过多列。

最好不要使用 SELECT * 语句，要根据须要选择查询的列。

减小返回的行

最好使用 LIMIT 语句来取出想要的那些行。

还能够创建索引来减小条件语句的全表扫描。例如对于下面的语句，不使用索引的状况下须要进行全表扫描，而使用索引只须要扫描几行记录便可，使用 Explain 语句能够经过观察 rows 字段来看出这种差别。

SELECT * FROM sakila.film_actor WHERE film_id = 1;

拆分大的 DELETE 或 INSERT 语句

若是一次性执行的话，可能一次锁住不少数据、占满整个事务日志、耗尽系统资源、阻塞不少小的但重要的查询。

DELEFT FROM messages WHERE create < DATE_SUB(NOW(), INTERVAL 3 MONTH);

rows_affected = 0
do {
    rows_affected = do_query(
    "DELETE FROM messages WHERE create  < DATE_SUB(NOW(), INTERVAL 3 MONTH) LIMIT 10000")
} while rows_affected > 0

5、切分

随着时间和业务的发展，数据库中的表会愈来愈多，而且表中的数据量也会愈来愈大，那么读写操做的开销也会随着增大。

垂直切分

将表按功能模块、关系密切程度划分出来，部署到不一样的库上。例如，咱们会创建商品数据库 payDB、用户数据库 userDB 等，分别用来存储项目与商品有关的表和与用户有关的表。

水平切分

把表中的数据按照某种规则存储到多个结构相同的表中，例如按 id 的散列值、性别等进行划分。

切分的选择

若是数据库中的表太多，而且项目各项业务逻辑清晰，那么垂直切分是首选。

若是数据库的表很少，可是单表的数据量很大，应该选择水平切分。

存在的问题

1. 事务问题

在执行分库分表以后，因为数据存储到了不一样的库上，数据库事务管理出现了困难。若是依赖数据库自己的分布式事务管理功能去执行事务，将付出高昂的性能代价；若是由应用程序去协助控制，造成程序逻辑上的事务，又会形成编程方面的负担。

2. 跨库跨表链接问题

在执行了分库分表以后，难以免会将本来逻辑关联性很强的数据划分到不一样的表、不一样的库上。这时，表的链接操做将受到限制，咱们没法链接位于不一样分库的表，也没法链接分表粒度不一样的表，致使本来只须要一次查询就可以完成的业务须要进行屡次才能完成。

3. 额外的数据管理负担和数据运算压力

最显而易见的就是数据的定位问题和数据的增删改查的重复执行问题，这些均可以经过应用程序解决，但必然引发额外的逻辑运算。

6、故障转移和故障恢复

故障转移也叫作切换，当主库出现故障时就切换到备库，使备库成为主库。故障恢复顾名思义就是从故障中恢复过来，而且保证数据的正确性。

提高备库或切换角色

提高一台备库为主库，或者在一个主-主复制结构中调整主动和被动角色。

虚拟 IP 地址和 IP 托管

为 MySQL 实例指定一个逻辑 IP 地址，当 MySQL 实例失效时，能够将 IP 地址转移到另外一台 MySQL 服务器上。

中间件解决方案

经过代理，能够路由流量到可使用的服务器上。

在应用中处理故障转移

将故障转移整合到应用中可能致使应用变得太过笨拙。

参考资料

BaronScbwartz, PeterZaitsev, VadimTkacbenko, 等. 高性能 MySQL[M]. 电子工业出版社, 2013.
How Sharding Works
MySQL 索引背后的数据结构及算法原理
20+ 条 MySQL 性能优化的最佳经验
数据库为何分库分表？mysql的分库分表方案