数据库知识点整理

数据库

• 基础知识点
• • 第一部分
• MySQL
• • 第一部分
• Redis
• session cookie cache token区别

基础知识点

第一部分

1. 数据库事务特性（ACID特性）
   • 原子性（Atomicity）整个事务中的操作要么完成要么不完成。事务执行过程中出错，则回滚(rollback)到事务开始之前的状态。
   • 一致性 (Correspondence) 事务执行前后数据库的状态都是有效的。
   • 隔离性 (Isolation) 隔离状态执行事务，即在相同时间内执行的两个事务相互隔离，不能访问到其他事务操作中的状态。
   • 持久性 (Durability) 事务操作一旦提交，就永久保存在数据库中。
2. 数据库索引及其优缺点
   • 什么是数据库索引
     • 索引是一种数据结构，已排好序，方便查询数据库。
     • 主要采用的数据结构包括，Hash Map， 红黑树，B树， B+树。
   • 优缺点
     • B+树和Hash Map的区别
       • Hash Map适合等值查询，无法进行范围查询
       • Hash Map没办法利用索引完成排序，不支持多列联合
       • 如果有大量重复key的话，哈希索引效率较低，因为存在哈希碰撞问题。
     • 聚集索引和非聚集索引
       • 聚集索引（数据文件就是索引文件）
         • 叶子节点存的是整行数据，可以直接通过聚集索引的key找到某行
         • 数据的物理存放顺序和索引顺序是一致的，只要索引是相邻的，对应的数据在磁盘上也是相邻的
         • 一个表只能有一个聚集索引（数据存放位置只有一个）
       • 非聚集索引
         • 叶子节点存储的是指针，该指针指向表中相应的数据行。需要回表进行二次查询。
     • 辅助索引
       • 非主键索引，允许重复key，叶子节点存储主键或地址（InnoDB和MyISAM不太一样）
     • 覆盖索引
       • 查询列时，从索引中直接获取查询结果。
     • 联合索引及最左前缀匹配
       • 创建（k1, k2, k3）联合索引，相当于创建了（k1）,（k1，k2）,（k1, k2, k3）三个索引，最左匹配原则。

3. 数据库逻辑设计之三大范式（Normal Format）

   参考博文

   数据库设计范式是数据库设计所需要满足的规范。

   • 1NF，字段原子性。字段不可再分割，关系型数据库，默认满足第一范式。
   • 2NF，记录唯一性。要求记录具有唯一性，属性完全依赖于主键，不存在部分依赖。

     反例： 表 学号 课程号 姓名 学分

     学分依赖课程号，姓名依赖学号，存在部分依赖。
     • 可能存在的问题：
       • 数据冗余
       • 删除异常
       • 插入异常
       • 更新异常
   • 3NF，字段不冗余。任何字段不能由其他字段派生出来，不存在传递依赖。

     反例：表 学号 姓名 年龄 学院名称 学院电话

     学院名称和学院电话存在传递依赖
     • 可能存在的问题：
       • 数据冗余
       • 更新异常
   • 反范式化。没有冗余的数据库未必是最好的数据库，有时为了提高运行效率，就必须降低范式标准，适当保留冗余数据。

MySQL

第一部分

1. 多用户并发操作可能出现的问题
   • 脏读：A事务读取了B事务执行过程的中间状态
   • 不可重复读：A事务执行过程多次查询的结果不一样(在A事务执行过程中，B事务修改了数据库)
   • 幻读：A事务执行过程中，B事务修改了数据库，导致幻读。区别于不可重复读，前者针对一批数据（例如数据条目），后者针对同一个数据项。

2. MySQL定义的四种隔离级别

   低级别的隔离一般支持更高的并发处理，并且拥有更低的系统开销。

   • Read UnCommitted：脏读，读到其他事务未提交的数据。
   • Read Committed 不可重复读：大多数数据库系统的默认隔离级别。一个事务提交前不可见。两次读取结果不一致。
   • Repeatable Read 可重复读：MySQL数据库默认的隔离级别。每次读取结果一样（读取的结果不一定是最新事务提交的，但一定是已提交事务），不过，这会导致另外一个棘手问题“幻读”。InnoDB和Falcon存储引擎通过多版本并发控制机制解决了幻读问题。
   • Serializable：它通过强制事务排序，使之不可能相互冲突，从而解决幻读问题。简而言之，SERIALIZABLE是在每个读的数据行上加锁。在这个级别，可能导致大量的超时Timeout和锁竞争Lock Contention现象，实际应用中很少使用到这个级别，但如果用户的应用为了数据的稳定性，需要强制减少并发的话，也可以选择这种隔离级。
3. MySQL的搜索引擎

   功能	MyISAM	MEMORY	InnoDB	Archive
   存储限制	256TB	RAM	64TB	None
   支持事务	No	No	Yes	No
   支持全文索引	Yes	No	No	No
   支持树索引	Yes	Yes	Yes	No
   支持哈希索引	No	Yes	No	No
   支持数据缓存	No	N/A	Yes	No
   支持外键	No	No	Yes	No

   • 如果要提供提交、回滚和恢复的事务安全（ACID 兼容）能力，并要求实现并发控制，InnoDB 是一个很好的选择。
   • 如果数据表主要用来插入和查询记录，则 MyISAM 引擎提供较高的处理效率
   • 如果只是临时存放数据，数据量不大，并且不需要较高的数据安全性，可以选择将数据保存在内存的 MEMORY 引擎中，MySQL 中使用该引擎作为临时表，存放查询的中间结果
   • 如果只有 INSERT 和 SELECT 操作，可以选择Archive 引擎，Archive 存储引擎支持高并发的插入操作，但是本身并不是事务安全的。Archive 存储引擎非常适合存储归档数据，如记录日志信息可以使用 Archive 引擎

4. 索引下推（index condition pushdown ，ICP）

   参考博文 对查询条件包含like的较为适用，无法通过最左匹配原则将查询条件一一等值匹配，则其他条件就需要服务器或搜索引擎来判断。

   • 即索引条件下沉到搜索引擎。
   • 不使用ICP，存储引擎通过索引检索到数据，再返回MySQL服务器，服务器判断是否满足条件
   • 使用ICP，如果存在索引的列为判断条件之一时，服务器将判断条件传递给存储引擎，通过存储引擎判断索引是否符合MySQL服务器传递条件，符合时才传递
   • 索引条件下推优化可以减少存储引擎查询基础表的次数，也可以减少MySQL服务器从存储引擎接收数据的次数，IO操作上的优化。
5. 查询优化器
   • explain查看sql语句执行计划，看有没有走索引查询，分析情况
   • MySQL的查询优化器，优化过程如下：
     • 根据搜索条件，找出所有可能使用的索引
     • 计算全表扫描的代价
     • 计算使用不同索引执行查询的代价
     • 对比各种执行方案的代价，找出成本最低的一个

Redis

session cookie cache token区别