数据库

常见通用的Join查询

存储引擎

概念

数据库存储引擎是数据库底层软件组织，数据库管理系统（DBMS）使用数据引擎进行创建、查询、更新和删除数据。不同的存储引擎提供不同的存储机制、索引技巧、锁定水平等功能，使用不同的存储引擎，还可以获得特定的功能。现在许多不同的数据库管理系统都支持多种不同的数据引擎。存储引擎主要有： 1. MyIsam , 2. InnoDB, 3. Memory, 4. Archive, 5. Federated 。

1. InnoDB存储引擎
   InnoDB是MySQL的默认事务型引擎，它被设计用来处理大量的短期(short-lived)事务。除非有非常特别的原因需要使用其他的存储引擎，否则应该优先考虑InnoDB引擎。

2. MyIsam存储引擎
   MyIsam提供了大量的特性，包括全文索引、压缩、空间函数(GIS)等，但MyIsam不支持事务和行级锁，有一个毫无疑问的缺陷就是崩溃后无法安全恢复。

InnoDB（B+树）

InnoDB 底层存储结构为B+树， B树的每个节点对应InnoDB的一个page， page大小是固定的，一般设为 16k。其中非叶子节点只有键值，叶子节点包含完成数据。

适用场景：
1）经常更新的表，适合处理多重并发的更新请求。
2）支持事务。
3）可以从灾难中恢复（通过 bin-log 日志等）。
4）外键约束。只有他支持外键。
5）支持自动增加列属性 auto_increment。

InnoDB 和 MyIsam 对比

索引优化

简介

MySQL官方对索引的定义为：索引（Index）是帮助MySQL高效获取数据的数据结构。
可以得到索引的本质：索引是数据结构。

可以简单理解为“排好序的快速查找数据结构”。

在数据之外，数据库系统还维护着满足特定查找算法的数据结构，这些数据结构以某种方式引用（指向）数据，这样就可以在这些数据结构上实现高级查找算法。这种数据结构，就是索引。

例如：

左边是数据表，一共有两列七条记录，最左边的是数据记录的物理地址为了加快Col2的查找，可以维护一个右边所示的二叉查找树，每个节点分别包含索引键值和一个指向对应数据记录物理地址的指针，这样就可以运用二叉查找在一定的复杂度内获取到相应数据，从而快速的检索出符合条件的记录。

总结：

数据本身之外，数据库还维护着一个满足特定查找算法的数据结构，这些数据结构以某种方式指向数据，这样就可以在这些数据结构的基础上实现高级查找算法，这种数据结构就是索引。一般来说索引本身也很大，不可能全部存储在内存中，因此索引往往以索引文件的形式存储的磁盘上。

MySQL索引结构

BTree索引

【初始化介绍】
一颗b树，浅蓝色的块我们称之为一个磁盘块，可以看到每个磁盘块包含几个数据项（深蓝色所示）和指针（黄色所示），
如磁盘块1包含数据项17和35，包含指针P1、P2、P3，
P1表示小于17的磁盘块，P2表示在17和35之间的磁盘块，P3表示大于35的磁盘块。
真实的数据存在于叶子节点即3、5、9、10、13、15、28、29、36、60、75、79、90、99。
非叶子节点只不存储真实的数据，只存储指引搜索方向的数据项，如17、35并不真实存在于数据表中。

【查找过程】
如果要查找数据项29，那么首先会把磁盘块1由磁盘加载到内存，此时发生一次IO，在内存中用二分查找确定29在17和35之间，锁定磁盘块1的P2指针，内存时间因为非常短（相比磁盘的IO）可以忽略不计，通过磁盘块1的P2指针的磁盘地址把磁盘块3由磁盘加载到内存，发生第二次IO，29在26和30之间，锁定磁盘块3的P2指针，通过指针加载磁盘块8到内存，发生第三次IO，同时内存中做二分查找找到29，结束查询，总计三次IO。

真实的情况是，3层的b+树可以表示上百万的数据，如果上百万的数据查找只需要三次IO，性能提高将是巨大的，如果没有索引，每个数据项都要发生一次IO，那么总共需要百万次的IO，显然成本非常非常高。

B+Tree索引

B+Tree与B-Tree 的区别

　 1）B-树的关键字和记录是放在一起的，叶子节点可以看作外部节点，不包含任何信息；B+树的非叶子节点中只有关键字和指向下一个节点的索引，记录只放在叶子节点中。
　 2）在B-树中，越靠近根节点的记录查找时间越快，只要找到关键字即可确定记录的存在；而B+树中每个记录的查找时间基本是一样的，都需要从根节点走到叶子节点，而且在叶子节点中还要再比较关键字。从这个角度看B-树的性能好像要比B+树好，而在实际应用中却是B+树的性能要好些。因为B+树的非叶子节点不存放实际的数据，这样每个节点可容纳的元素个数比B-树多，树高比B-树小，这样带来的好处是减少磁盘访问次数。尽管B+树找到一个记录所需的比较次数要比B-树多，但是一次磁盘访问的时间相当于成百上千次内存比较的时间，因此实际中B+树的性能可能还会好些，而且B+树的叶子节点使用指针连接在一起，方便顺序遍历（例如查看一个目录下的所有文件，一个表中的所有记录等），这也是很多数据库和文件系统使用B+树的缘故。
　
思考：为什么说B+树比B-树更适合实际应用中操作系统的文件索引和数据库索引？

1) B+树的磁盘读写代价更低
　　B+树的内部结点并没有指向关键字具体信息的指针。因此其内部结点相对B 树更小。如果把所有同一内部结点的关键字存放在同一盘块中，那么盘块所能容纳的关键字数量也越多。一次性读入内存中的需要查找的关键字也就越多。相对来说IO读写次数也就降低了。
2) B+树的查询效率更加稳定
　　由于非终结点并不是最终指向文件内容的结点，而只是叶子结点中关键字的索引。所以任何关键字的查找必须走一条从根结点到叶子结点的路。所有关键字查询的路径长度相同，导致每一个数据的查询效率相当。

聚簇索引与非聚簇索引

聚簇索引并不是一种单独的索引类型，而是一种数据存储方式。
术语‘聚簇’表示数据行和相邻的键值聚簇的存储在一起。如下图，左侧的索引就是聚簇索引，因为数据行在磁盘的排列和索引排序保持一致。

聚簇索引的好处：
按照聚簇索引排列顺序，查询显示一定范围数据的时候，由于数据都是紧密相连，数据库不不用从多个数据块中提取数据，所以节省了大量的io操作。

聚簇索引的限制：

对于MySQL数据库目前只有InnoDB数据引擎支持聚簇索引，而MyIsam并不支持聚簇索引。由于数据物理存储排序方式只能有一种，所以每个MySQL的表只能有一个聚簇索引。一般情况下就是该表的主键。为了充分利用聚簇索引的聚簇的特性，所以InnoDB表的主键列尽量选用有序的顺序id，而不建议用无序的id，比如uuid这种。

常见索引原则有

1. 选择唯一性索引
   唯一性索引的值是唯一的，可以更快速的通过该索引来确定某条记录。

2. 为经常需要排序、分组和联合操作的字段建立索引。

3. 为常作为查询条件的字段建立索引。

4. 限制索引的数目：
   越多的索引，会使更新表变得很浪费时间。

5. 尽量使用数据量少的索引

6. 如果索引的值很长，那么查询的速度会受到影响。尽量使用前缀来索引

7. 如果索引字段的值很长，最好使用值的前缀来索引。

8. 删除不再使用或者很少使用的索引

9. 最左前缀匹配原则，非常重要的原则。

10. 尽量选择区分度高的列作为索引,区分度的公式是表示字段不重复的比例

11. 索引列不能参与计算，保持列“干净”：带函数的查询不参与索引。

12. 尽量的扩展索引，不要新建索引。

基本语法

# 查看
show index from t_emp ;

# 创建
create index idx_name on t_emp (name);

# 创建唯一索引
create unique index idx_empno on t_emp (empno);

# 删除
drop index idx_name on t_emp;

使用ALTER命令：

有四种方式来添加数据表的索引：

ALTER TABLE tbl_name ADD PRIMARY KEY (column_list)

该语句添加一个主键，这意味着索引值必须是唯一的，且不能为NULL。

ALTER TABLE tbl_name ADD UNIQUE index_name (column_list)

这条语句创建索引的值必须是唯一的（除了NULL外，NULL可能会出现多次）。

ALTER TABLE tbl_name ADD INDEX index_name (column_list)

添加普通索引，索引值可出现多次。

ALTER TABLE tbl_name ADD FULLTEXT index_name (column_list)

该语句指定了索引为 FULLTEXT ，用于全文索引。

索引性能分析

Explain

使用 EXPLAIN 关键字可以模拟优化器执行SQL查询语句，从而知道MySQL是
如何处理你的SQL语句的。分析你的查询语句或是表结构的性能瓶颈

作用：
EXPLAIN 可以查看表的读取顺序、哪些索引可以使用、数据读取操作的操作类型、哪些索引被实际使用、表之间的引用、每张表有多少行被物理查询。

使用方法：Explain + SQL语句

执行计划包含的信息：

主要字段解释：

1. id :

   • select查询的序列号,包含一组数字，表示查询中执行select子句或操作表的顺序。

   • 三种情况

     • id相同，执行顺序由上至下
     • id不同，如果是子查询，id的序号会递增，id值越大优先级越高，越先被执行。
     • id如果相同，可以认为是一组，从上往下顺序执行；在所有组中，id值越大，优先级越高，越先执行

     id 号每个号码，表示一趟独立的查询。一个sql 的查询趟数越少越好。

2. select_type : 查询类型说明

3. table : 显示这一行的数据是关于哪张表的

4. type : 显示查询使用了何种类型 （重要）

   

   • type显示的是访问类型，是较为重要的一个指标，结果值从最好到最坏依次是：
     system > const>eq_ref > ref > range > index > ALL

     1. ALL :
        Full Table Scan，将遍历全表以找到匹配的行,这是最坏的情况,此时必须进行建立索引。
        EXPLAIN select * from t_dept where CEO is not null

     

     2. index :
        出现index是sql使用了索引但是没用通过索引进行过滤，一般是使用了覆盖索引或者是利用索引进行了排序分组
        EXPLAIN select * from t_dept where CEO is not null order by id;
        

     3. range:
        只检索给定范围的行,使用一个索引来选择行。key 列显示使用了哪个索引。
        一般就是在你的where语句中出现了between、<、>、in 等的查询,这种范围扫描索引扫描比全表扫描要好，因为它只需要开始于索引的某一点，而结束语另一点，不用扫描全部索引。
        EXPLAIN select * from t_dept where CEO is not null;
        

     4. Extra :
        包含不适合在其他列中显示但十分重要的额外信息

     • Using filesort : “文件排序” ,未对排序条件添加索引
     • Using temporary : 使了用临时表保存中间结果,MySQL在对查询结果排序时使用临时表。常见于排序 order by 和分组查询 group by。即 分组查询未使用索引。
     • using join buffer :使用了连接缓存,即关联查询，关联字段未使用索引。

     总结：

     一般来说，得保证查询至少达到 range 级别，最好能达到 ref。

查询优化

单表案例(索引失效)

1. 最佳左前缀法则：
   如果索引了多列，要遵守最左前缀法则。指的是查询从索引的最左前列开始并且不跳过索引中的列。

2. 不在索引列上做任何操作（计算、函数、(自动or手动)类型转换），会导致索引失效而转向全表扫描

3. 存储引擎不能使用索引中范围条件右边的列

4. mysql 在使用不等于(!= 或者<>)的时候无法使用索引会导致全表扫描

5. is not null 也无法使用索引,但是is null是可以使用索引的

6. like以通配符开头(‘%abc…’)mysql索引失效会变成全表扫描的操作

单表索引总结:

假设index(a,b,c)

单表一般性建议

• 对于单键索引，尽量选择针对当前 query过滤性更好的索引
• 在选择组合索引的时候，当前Query中过滤性最好的字段在索引字段顺序中，位置越靠前越好。
• 在选择组合索引的时候，尽量选择可以能够包含当前query中的where字句中更多字段的索引
• 在选择组合索引的时候，如果某个字段可能出现范围查询时，尽量把这个字段放在索引次序的最后面
• 书写sql语句时，尽量避免造成索引失效的情况。

关联查询优化

1. 保证被驱动表的join字段已经被索引
2. left join时，选择小表作为驱动表，大表作为被驱动表。
3. Inner join时，mysq会自己帮你把小结果集的表选为驱动表
4. 子查询尽量不要放在被驱动表，有可能使用不到索引。
5. 能够直接多表关联的尽量直接关联，不用子查询。

子查询优化

尽量不要使用not in 或者 not exists，用left outer join on xxx is null 替代。

排序分组优化

• ORDER BY子句，尽量使用Index方式排序,避免使用FileSort方式排序
• 索引的选择： 当范围条件和group by 或者 order by 的字段出现二选一时 ，优先观察条件字段的过滤数量，如果过滤的数据足够多，而需要排序的数据并不多时，优先把索引放在范围字段上。反之，亦然。
• GROUP BY关键字优化：group by 使用索引的原则几乎跟order by一致 ，唯一区别是groupby 即使没有过滤条件用到索引，也可以直接使用索引。

数据库三范式

范式是具有最小冗余的表结构。

第一范式(1st NF －列都是不可再分)

第一范式的目标是确保每列的原子性:如果每列都是不可再分的最小数据单元（也称为最小的原子单元），则满足第一范式（1NF）

第二范式(2nd NF－每个表只描述一件事情)

首先满足第一范式，并且表中非主键列不存在对主键的部分依赖。 第二范式要求每个表只描述一件事情。

第三范式(3rd NF－ 不存在对非主键列的传递依赖)

第三范式定义是，满足第二范式，并且表中的列不存在对非主键列的传递依赖。
如：除了主键订单编号外，顾客姓名依赖于非主键顾客编号。

数据库事务

事务(TRANSACTION)是作为单个逻辑工作单元执行的一系列操作， 这些操作作为一个整体一起向系统提交，要么都执行、要么都不执行 。 事务是一个不可分割的工作逻辑单元事务必须具备以下四个属性，简称 ACID 。

属性：

原子性（Atomicity）

事务是一个完整的操作。事务的各步操作是不可分的（原子的）；要么都执行，要么都不执行。

一致性（Consistency）

当事务完成时，数据必须处于一致状态。

隔离性（Isolation）

对数据进行修改的所有并发事务是彼此隔离的， 这表明事务必须是独立的，它不应以任何方式依赖于或影响其他事务。

永久性（Durability）

事务完成后，它对数据库的修改被永久保持，事务日志能够保持事务的永久性。

数据库并发策略

并发控制一般采用三种方法，分别是乐观锁和悲观锁以及时间戳。

乐观锁

乐观锁认为一个用户读数据的时候，别人不会去写自己所读的数据；悲观锁就刚好相反，觉得自己读数据库的时候，别人可能刚好在写自己刚读的数据，其实就是持一种比较保守的态度；时间戳就是不加锁，通过时间戳来控制并发出现的问题。

悲观锁

悲观锁就是在读取数据的时候，为了不让别人修改自己读取的数据，就会先对自己读取的数据加锁，只有自己把数据读完了，才允许别人修改那部分数据，或者反过来说，就是自己修改某条数据的时候，不允许别人读取该数据，只有等自己的整个事务提交了，才释放自己加上的锁，才允许其他用户访问那部分数据。

时间戳

时间戳就是在数据库表中单独加一列时间戳，比如“TimeStamp”， 每次读出来的时候，把该字段也读出来，当写回去的时候，把该字段加 1，提交之前 ，跟数据库的该字段比较一次，如果比数
据库的值大的话，就允许保存，否则不允许保存，这种处理方法虽然不使用数据库系统提供的锁机制，但是这种方法可以大大提高数据库处理的并发量。

以上悲观锁所说的加“锁”，其实分为几种锁，分别是： 排它锁（写锁） 和共享锁（读锁）。

脏读,不可重复读,幻读

脏读

脏读又称无效数据读出。一个事务读取另外一个事务还没有提交的数据叫脏读。

例如：事务T1修改了一行数据，但是还没有提交，这时候事务T2读取了被事务T1修改后的数据，之后事务T1因为某种原因Rollback了，那么事务T2读取的数据就是脏的。

解决办法：把数据库的事务隔离级别调整到 READ_COMMITTED

不可重复读

不可重复读是指在同一个事务内，两个相同的查询返回了不同的结果。

例如：事务T1读取某一数据，事务T2读取并修改了该数据，T1为了对读取值进行检验而再次读取该数据，便得到了不同的结果。

解决办法：把数据库的事务隔离级别调整到 REPEATABLE_READ （Mysql 默认隔离级别）

幻读

幻读是指当事务不是独立执行时发生的一种现象。

例如：系统管理员A将数据库中所有学生的成绩从具体分数改为ABCDE等级，但是系统管理员B就在这个时候插入了一条具体分数的记录，当系统管理员A改结束后发现还有一条记录没有改过来，就好像发生了幻觉一样。这就叫幻读。

解决办法：把数据库的事务隔离级别调整到 SERIALIZABLE_READ ( Oracle 默认隔离级别)

注意：

脏读、不可重复读、幻读的级别高低是：脏读 < 不可重复读 < 幻读。所以，设置了最高级别的SERIALIZABLE_READ就不用在设置REPEATABLE_READ和READ_COMMITTED了，不可重复读重点是修改；幻读重点是新增、删除。