MySQL小结

1 列举常见的关系型数据库和非关系型都有哪些？

1.1 关系型数据库(须要有表结构)

表和表、表和字段、数据和数据存在着关系。经常使用的有MySQL、oracle、SQL server、db二、sybase等

优势：

• 易于维护：都是使用表结构，格式一致；
• 使用方便：SQL语言通用，可用于复杂查询；
• 复杂操做：支持SQL。可用一个表以及多个表之间很是复杂的查询。

缺点：

• 读写性能比较差，尤为是海量数据的高效率读写；
• 固定的表结构，灵活度稍欠；
• 高并发读写需求，对传统关系型数据库来讲，硬盘I/O是一个很大的麻烦

1.2 非关系数据库

严格上不是一种数据库，应该是一种数据结构化存储方法的集合，能够是文档或者键值对等。

优势：

• 格式灵活：存储数据的格式能够是key:value形式、文档形式、图片形式等等，使用灵活，应用场景普遍，而关系型数据库则只支持基础类型；
• 速度快：nosql可使用硬盘或者随机存储器做为载体，而关系数据库只能使用硬盘；
• 高扩展性；
• 成本低：nosql数据库部署简单，基本都是开源软件。

缺点：

• 不提供SQL支持，学习和使用成本较高；
• 无事务处理；
• 数据结构相对复杂，复杂查询方面稍欠。

非关系型数据库的分类比较：

• 文档型

  

• key-value型

  

• 列式数据库

  

• 图形数据库

  

2 什么是数据库,数据库管理系统,数据库系统,数据库管理员?

• 数据库:数据库(DataBase简称DB)就是信息的集合或者说数据库是由数据库管理系统管理的数据的集合。
• 数据库管理系统 : 数据库管理系统(Database Management System 简称DBMS)是一种操纵和管理数据库的大型软件，一般用语用于创建、使用和维护数据库。
• 数据库系统 : 数据库系统(Data Base System，简称DBS)一般由软件、数据库和数据管理员(DBA)组成。
• 数据库管理员 : 数据库管理员(Database Administrator,简称DBA)负责全面管理和控制数据库系统。 数据库系统基本构成以下图所示：

3 什么是元组,码,候选码,主码,外码,主属性,非主属性？

• 元组 ： 元组（tuple）是关系数据库中的基本概念，关系是一张表，表中的每行（即数据库中的每条记录）就是一个元组，每列就是一个属性。 在二维表里，元组也称为行。 码 ：码就是能惟一标识实体的属性，对应表中的列。
• 候选码 ： 若关系中的某一属性或属性组的值能惟一的标识一个元组，而其任何、子集都不能再标识，则称该属性组为候选码。例如：在学生实体中，“学号”是能惟一的区分学生实体的，同时又假设“姓名”、“班级”的属性组合足以区分学生实体，那么{学号}和{姓名，班级}都是候选码。
• 主码 : 主码也叫主键。主码是从候选码中选出来的。 一个实体集中只能有一个主码，但能够有多个候选码。
• 外码 : 外码也叫外键。若是一个关系中的一个属性是另一个关系中的主码则这个属性为外码。
• 主属性 ： 候选码中出现过的属性称为主属性。好比关系 工人（工号，身份证号，姓名，性别，部门）.显然工号和身份证号都可以惟一标示这个关系，因此都是候选码。工号、身份证号这两个属性就是主属性。若是主码是一个属性组，那么属性组中的属性都是主属性。
• 非主属性： 不包含在任何一个候选码中的属性称为非主属性。好比在关系——学生（学号，姓名，年龄，性别，班级）中，主码是“学号”，那么其余的“姓名”、“年龄”、“性别”、“班级”就均可以称为非主属性。

4 主键和外键有什么区别?

• 主键(主码) ：主键用于惟一标识一个元组，不能有重复，不容许为空。一个表只能有一个主键。
• 外键(外码) ：外键用来和其余表创建联系用，外键是另外一表的主键，外键是能够有重复的，能够是空值。一个表能够有多个外键。

5 内链接与外链接

5.1 MySQL内链接(inner join on)

MySQL的内链接使用inner join on,它的效果跟使用where是同样的,若是联结的是两个表,那么须要左右的条件或者说字段是须要彻底匹配的。

5.2 MySQL外链接(left,right)

• 外链接包含左右链接
• 左链接的结果是除了匹配条件的数据还包含左边表中的全部数据
• 右链接的结果是除了匹配条件的数据还包含右边表中的全部数据

6 什么是ER图？

E-R图也称实体-联系图(Entity Relationship Diagram)，提供了表示实体类型、属性和联系的方法，用来描述现实世界的概念模型。 它是描述现实世界关系概念模型的有效方法。 是表示概念关系模型的一种方式。

下图是一个学生选课的ER图，每一个学生能够选若干门课程，同一门课程也能够被若干人选择，因此它们之间的关系是多对多（M:N）。另外，还有其余两种关系是：1对1（1:1）、1对多（1:N）。

咱们试着将上面的ER图转换成数据库实际的关系模型(实际设计中，咱们一般会将任课教师也做为一个实体来处理)：

7 数据库范式了解吗?

7.1 一些重要的概念：

• 函数依赖（functional dependency）

  若在一张表中，在属性（或属性组）X的值肯定的状况下，一定能肯定属性Y的值，那么就能够说Y函数依赖于X，写做 X → Y。

• 部分函数依赖（partial functional dependency）

  若是X→Y，而且存在X的一个真子集X0，使得X0→Y，则称Y对X部分函数依赖。好比学生基本信息表R中（学号，身份证号，姓名）固然学号属性取值是惟一的，在R关系中，（学号，身份证号）->（姓名），（学号）->（姓名），（身份证号）->（姓名）；因此姓名部分函数依赖与（学号，身份证号）；

• 彻底函数依赖(Full functional dependency)

  在一个关系中，若某个非主属性数据项依赖于所有关键字称之为彻底函数依赖。好比学生基本信息表R（学号，班级，姓名）假设不一样的班级学号有相同的，班级内学号不能相同，在R关系中，（学号，班级）->（姓名），可是（学号）->(姓名)不成立，（班级）->(姓名)不成立，因此姓名彻底函数依赖与（学号，班级）；

• 传递函数依赖

  在关系模式R(U)中，设X，Y，Z是U的不一样的属性子集，若是X肯定Y、Y肯定Z，且有X不包含Y，Y不肯定X，（X∪Y）∩Z=空集合，则称Z传递函数依赖(transitive functional dependency) 于X。传递函数依赖会致使数据冗余和异常。传递函数依赖的Y和Z子集每每同属于某一个事物，所以可将其合并放到一个表中。好比在关系R(学号 ,姓名, 系名，系主任)中，学号 → 系名，系名 → 系主任，因此存在非主属性系主任对于学号的传递函数依赖。

7.2 1NF(第一范式)

属性（对应于表中的字段）不能再被分割，也就是这个字段只能是一个值，不能再分为多个其余的字段了。1NF是全部关系型数据库的最基本要求 ，也就是说关系型数据库中建立的表必定知足第一范式。

7.3 2NF(第二范式)

2NF在1NF的基础之上，消除了非主属性对于码的部分函数依赖。以下图所示，展现了第一范式到第二范式的过渡。第二范式在第一范式的基础上增长了一个列，这个列称为主键，非主属性都依赖于主键。

7.4 3NF(第三范式)

3NF在2NF的基础之上，消除了非主属性对于码的传递函数依赖 。符合3NF要求的数据库设计，基本上解决了数据冗余过大，插入异常，修改异常，删除异常的问题。好比在关系R(学号 ,姓名, 系名，系主任)中，学号 → 系名，系名 → 系主任，因此存在非主属性系主任对于学号的传递函数依赖，因此该表的设计，不符合3NF的要求。

7.5 总结

• 1NF：属性不可再分。
• 2NF：1NF的基础之上，消除了非主属性对于码的部分函数依赖。
• 3NF：3NF在2NF的基础之上，消除了非主属性对于码的传递函数依赖 。

8 数据库三大特性：

• 实体 ：表
• 属性：表中的数据(字段)
• 关系 ：表与表之间的关系

9 数据库五大约束:

• primary key：设置主键约束；
• UNIQUE：设置惟一性约束，不能有重复值；
• DEFAULT：默认值约束；
• NOT NULL：设置非空约束，该字段你能为空；
• FOREIGN KEY：设置外键约束。

10 MySQL常见的数据库引擎及比较？

• InnoDB 支持事务；支持表锁、行锁(for update) 表锁：select * from tb for update 行锁：select id,name from tb where id=2 for update
• Myisam：查询速度快；全文索引；支持表锁；
• NDB： 高可用、高性能、高可扩展性的数据库集群系统；
• Memory：默认使用的是哈希索引；
• BDB： 可替代InnoDB的事务引擎，支持COMMIT、ROLLBACK和其余事务特性；
• Merge： 容许MySQL DBA或开发人员将一系列等同的MyISAM表以逻辑方式组合在一块儿，并做为一个对象引用他们。对于诸如数据仓储等VLDB环境十分适合。
• Achive：为大量不多引用的历史、归档、或安全设计信息的存储和检索提供了完美的解决方案；
• Federated：可以将多个分离的MySQL服务器链接起来，从多个物理服务器建立一个逻辑数据库。十分适合于分布式环境或数据集市环境；
• Cluster：MySQL的簇式数据库引擎，尤为适合于具备高性能查找要求的应用程序，这类查找需求还要求具备更高的正常工做时间和可用性；
• Other： 其余存储引擎包括CSV(引用由逗号隔开的用做数据库表的文件)，Blackhole(用于临时禁止对数据库的应用程序输入)，以及Example引擎(可谓快速建立定制的插件式存储引擎提供帮助)。

InnoDB和MyisSam对比

MyISAM是MySQL的默认数据库引擎（5.5版以前），由早期的 ISAM （Indexed Sequential Access Method：有索引的顺序访问方法）所改良。虽然性能极佳，并且提供了大量的特性，包括全文索引、压缩、空间函数等，但MyISAM不支持事务和行级锁，并且最大的缺陷就是崩溃后没法安全恢复。不过，5.5版本以后，MySQL引入了InnoDB（另外一种数据库引擎）。

大多数时候咱们使用的都是InnoDB存储引擎，可是在某些状况下使用 MyISAM 也是合适的好比读密集的状况下。（若是你不介意 MyISAM 崩溃回复问题的话）。

二者的对比：

• 是否支持行级锁 : MyISAM 只有表级锁(table-level locking)，而InnoDB 支持行级锁(row-level locking)和表级锁,默认为行级锁。
• 是否支持事务和崩溃后的安全恢复： MyISAM 强调的是性能，每次查询具备原子性,其执行数度比InnoDB类型更快，可是不提供事务支持。可是InnoDB 提供事务支持事务，外部键等高级数据库功能。 具备事务(commit)、回滚(rollback)和崩溃修复能力(crash recovery capabilities)的事务安全(transaction-safe (ACID compliant))型表。
• 是否支持外键： MyISAM不支持，而InnoDB支持。
• 是否支持MVCC ：仅 InnoDB 支持。应对高并发事务, MVCC比单纯的加锁更高效;MVCC只在 READ COMMITTED 和 REPEATABLE READ 两个隔离级别下工做;MVCC可使用 乐观(optimistic)锁 和 悲观(pessimistic)锁来实现;各数据库中MVCC实现并不统一。(MVCC出门左转)

11 事务相关

事务用于将某些操做的多个SQL做为原子性操做，一旦有某一个出现错误，便可滚回到原来的状态，从而保证数据库的数据完整性。

11.1 事务的特性：

• 原子性(Atomicity)：事务包含的全部操做要么所有成功，要么所有失败回滚，所以事务的操做若是成功必须所有应用到数据库，若是数据操做失败则不能对数据库有任何的影响；
• 一致性(Consistency)：是指事务必须使数据库从一个一致性状态变换到另外一个一致性状态，也就是说一个事务执行以前和执行以后都必须处于一致状态(确保数据库正确地改变状态后，成功提交事务)；
• 隔离性(Isolation)：是当多个用户并发访问数据库时，数据库为每个用户开启的事务不能被其余事务的操做所干扰，多个并发事务之间要相互隔离(使事务操做彼此独立和透明的)；
• 持久性(Durability)：是指一个事务一旦被提交了，那么对数据库中的数据的改变就是永久性的，即使是数据库系统遇到故障的状况下也不会丢失提交事务的操做(确保提交的事务的结果或效果的系统出现故障的状况下仍然存在)；

11.2 并发事务带来哪些问题？

在典型的应用程序中，多个事务并发运行，常常会操做相同的数据来完成各自的任务（多个用户对统一数据进行操做）。并发虽然是必须的，但可能会致使如下的问题。

• 脏读（Dirty read）: 当一个事务正在访问数据而且对数据进行了修改，而这种修改尚未提交到数据库中，这时另一个事务也访问了这个数据，而后使用了这个数据。由于这个数据是尚未提交的数据，那么另一个事务读到的这个数据是“脏数据”，依据“脏数据”所作的操做多是不正确的。
• 丢失修改（Lost to modify）: 指在一个事务读取一个数据时，另一个事务也访问了该数据，那么在第一个事务中修改了这个数据后，第二个事务也修改了这个数据。这样第一个事务内的修改结果就被丢失，所以称为丢失修改。 例如：事务1读取某表中的数据A=20，事务2也读取A=20，事务1修改A=A-1，事务2也修改A=A-1，最终结果A=19，事务1的修改被丢失。
• 不可重复读（Unrepeatableread）: 指在一个事务内屡次读同一数据。在这个事务尚未结束时，另外一个事务也访问该数据。那么，在第一个事务中的两次读数据之间，因为第二个事务的修改致使第一个事务两次读取的数据可能不太同样。这就发生了在一个事务内两次读到的数据是不同的状况，所以称为不可重复读。
• 幻读（Phantom read）: 幻读与不可重复读相似。它发生在一个事务（T1）读取了几行数据，接着另外一个并发事务（T2）插入了一些数据时。在随后的查询中，第一个事务（T1）就会发现多了一些本来不存在的记录，就好像发生了幻觉同样，因此称为幻读。

不可重复度和幻读区别：

不可重复读的重点是修改，幻读的重点在于新增或者删除。

11.3 事务隔离级别有哪些?MySQL的默认隔离级别是?

11.3.1 四个隔离级别：

• READ-UNCOMMITTED(读取未提交)： 最低的隔离级别，容许读取还没有提交的数据变动，可能会致使脏读、幻读或不可重复读。
• READ-COMMITTED(读取已提交)： 容许读取并发事务已经提交的数据，能够阻止脏读，可是幻读或不可重复读仍有可能发生。
• REPEATABLE-READ(可重复读)： 对同一字段的屡次读取结果都是一致的，除非数据是被自己事务本身所修改，能够阻止脏读和不可重复读，但幻读仍有可能发生。
• SERIALIZABLE(可串行化)： 最高的隔离级别，彻底服从ACID的隔离级别。全部的事务依次逐个执行，这样事务之间就彻底不可能产生干扰，也就是说，该级别能够防止脏读、不可重复读以及幻读。

隔离级别	脏读	不可重复读	幻读
READ-UNCOMMITTED(读取未提交)	√	√	√
READ-COMMITTED(读取已提交)	×	√	√
REPEATABLE-READ(可重复读)	×	×	√
SERIALIZABLE(可串行化)	×	×	×

MySQL InnoDB 存储引擎的默认支持的隔离级别是 REPEATABLE-READ（可重读）。咱们能够经过SELECT @@tx_isolation;命令来查看.

11.3.2 注意

与 SQL 标准不一样的地方在于InnoDB 存储引擎在 REPEATABLE-READ（可重读）事务隔离级别下使用的是Next-Key Lock 锁算法，所以能够避免幻读的产生，这与其余数据库系统(如 SQL Server)是不一样的。因此说InnoDB 存储引擎的默认支持的隔离级别是 REPEATABLE-READ（可重读）** 已经能够彻底保证事务的隔离性要求，即达到了 SQL标准的SERIALIZABLE(可串行化)隔离级别。

由于隔离级别越低，事务请求的锁越少，因此大部分数据库系统的隔离级别都是READ-COMMITTED(读取提交内容):，可是你要知道的是InnoDB 存储引擎默认使用 REPEATABLE-READ（可重读）并不会有任何性能损失。

InnoDB 存储引擎在 分布式事务 的状况下通常会用到SERIALIZABLE(可串行化)隔离级别。

12 简述数据库设计中一对多和多对多的应用场景？

• FK(一对多)：下拉框里面的数据就须要用FK关联另外一张表； 实例：一个学生只属于一个班每个班有多个学生
• M2M(多对多)：多选的下拉框，或者CheckBox。 实例：一个学生能够选多门课程，一门课程也有多名学生

13 简述触发器、函数、视图、存储过程

• 触发器：对数据库某张表的增长、删除、修改先后定义一些操做；
• 函数：
  • 触发函数：select
  • 聚合函数：max/min/sum/avg
  • 时间格式化：date_format
  • 字符串拼接：concat
  • 截取字符串：substring
  • 返回字节个数：length
• 存储过程：将SQL语句保存到数据库中，并命名，之后在代码调用时，直接调用名称便可；
  • 参数类型：
    1. in 只将参数穿进去
    2. out 只拿结果
    3. inout 既能够传，也能够取

存储过程在互联网公司应用很少，由于存储过程难以调试和扩展，并且没有移植性，还会消耗数据库资源。

• 函数和存储过程区别：

本质上没区别。只是函数有如：只能返回一个变量的限制。而存储过程能够返回多个。而函数是能够嵌入SQL中使用的，能够在select中调用，而存储过程不行。

• 视图：视图是一个虚拟表，不是真实存在的(只能查，不能改)

14 MySQL索引

因为索引的知识点太多，后期我在单独用写一篇博客来详细分析。

15 如何开启慢日志查询？

• 修改配置文件

slow_query_log = OFF  # 是否开启慢日志记录
long_query_time = 2   # 时间限制，超过此时间，则记录
slow_query_log_file = /usr/slow.log  # 日志文件
log_queries_not_using_indexes = OFF  # 未使用索引的搜索是否记录
复制代码

• 下面是开启

slow_query_log = ON
long_query_time = 2
log_queries_not_using_indexes = OFF
log_queries_not_using_indexes = ON
复制代码

• 注意：

查看当前配置信息：show variables like '%query%'
修改当前配置：set global 变量名 = 值
复制代码

16 数据库导入导出命令(结构+数据)？

• 导出现有数据库数据：(当有提示输入密码，-p就不用加密码)

mysqldump -u用户名 -p密码 数据库名称 > 导出文件路径  # 结构+数据
mysqldump -u用户名 -p密码 -d 数据库名称 > 导出文件 路径 # 结构
'--no-defaults'：解决"unknown option --no-beep"错误
复制代码

• 导入现有数据库数据：

mysqldump -uroot -p密码 数据库名称 < 文件路径
或者：进入数据库； source + 要导入数据库文件路径
复制代码

17 数据库优化方案

• 建立数据表时把固定长度的放在前面
• 将固定数据放入内存：

例如 choice字段(django中有用到，数字一、二、3...对应相应内容)

• char 和 varchar 的区别(char可变，varchar不可变)
• 联合索引遵循最左前缀(从最左侧开始检索)
• 避免使用select *
• 读写分离
  • 实现：两台服务器同步数据
  • 利用数据库的主从分离：主，用于删除、修改、更新；从，用于查；
• 分库

当数据库中的表太多，将某些表分到不一样的数据库，例如：1w张表时；
代价：连表查询

• 分表
  • 水平分表：将某些列拆分到另外一张表，例如：博客+博客详情；
  • 垂直分表：将某些历史信息分到另一张表中，例如：支付宝帐单
• 加缓存

利用redis、memcache(经常使用数据放到缓存里，提升去取数据速度)

• 若是只想得到一条数据 select * from tb1 where name='alex' limit 1

下面补充一下数据库分片的两种常见方案：

• 客户端代理： 分片逻辑在应用端，封装在jar包中，经过修改或者封装JDBC层来实现。 当当网的 Sharding-JDBC 、阿里的TDDL是两种比较经常使用的实现。
• 中间件代理： 在应用和数据中间加了一个代理层。分片逻辑统一维护在中间件服务中。 咱们如今谈的 Mycat 、360的Atlas、网易的DDB等等都是这种架构的实现。

18 简述MySQL的执行计划

explain + SQL语句
复制代码

• 查看有没有命中索引，让数据库帮看看运行速度快不快
• SQL在数据库中的表现状况，一般用于SQL性能分析、优化等场景

19 在对name作了惟一索引的前提下，简述如下区别：

select * from tb1 where name = '小明' select * from tb1 where name = '小明' limit 1 没作惟一索引的话，前者查询会全表扫描，效率低些； limit 1，只要找到对应一条数据，就不继续往下扫描； 然而name字段添加惟一索引了，加不加limit 1，意义都不大。

20 1000w条数据，使用limit offset分页时，为何越日后返越慢？如何解决？

例如：

limit 100000,20;  # 从第十万开始日后取二十条，
limit 20 offset 100000; # limit 后面是取20条数据，offset后面是从10w条数据开始读
复制代码

由于当一个数据表过于庞大，LIMIT offset，length中的offset值过大，则SQL查询语句会很是缓慢

• 优化一：先看主键，再分页：

select * from tb where id in (select id from tb where limit 10 offset 30)
复制代码

• 优化二： 记录当前页，数据、ID、最大值和最小值(用于where查询) 在翻页时，根据条件进行筛选，筛选完毕后，再根据limit offset 查询

select * from (select * from tb where id > 2222) as B limit 10 offset 0;
复制代码

• 优化三： 能够按照当前业务需求，看是否能够设置只容许看前200页； 通常状况下，没人会咔咔看个几十上百页的。

21 悲观锁和乐观锁

21.1 悲观锁和乐观锁的区别？

• 悲观锁

会从数据开始更改时就将数据锁住，直到更改完成才释放；
会形成数据库访问时间较长，并发性很差，特别是长事务。
传统的关系型数据库里边就用到了不少这种锁机制，好比行锁，表锁等，读锁，写锁等，都是在作操做以前先上锁。
Java中synchronized和ReentrantLock等独占锁就是悲观锁思想的实现。

• 乐观锁

直到修改完成，准备提交修改到数据库时才会锁住数据，完成更改后释放；
乐观锁适用于多读的应用类型，这样能够提升吞吐量，像数据库提供的相似于write_condition机制，其实都是提供的乐观锁。
在Java中java.util.concurrent.atomic包下面的原子变量类就是使用了乐观锁的一种实现方式CAS实现的。

21.2 两种锁的使用场景

从上面对两种锁的介绍，咱们知道两种锁各有优缺点，不可认为一种好于另外一种，像乐观锁适用于写比较少的状况下（多读场景），即冲突真的不多发生的时候，这样能够省去了锁的开销，加大了系统的整个吞吐量。但若是是多写的状况，通常会常常产生冲突，这就会致使上层应用会不断的进行retry，这样反却是下降了性能，因此通常多写的场景下用悲观锁就比较合适。

21.3 乐观锁常见的两种实现方式

版本号机制

通常是在数据表中加上一个数据版本号version字段，表示数据被修改的次数，当数据被修改时，version值会加一。当线程A要更新数据值时，在读取数据的同时也会读取version值，在提交更新时，若刚才读取到的version值为当前数据库中的version值相等时才更新，不然重试更新操做，直到更新成功。

CAS算法

即compare and swap（比较与交换），是一种有名的无锁算法。无锁编程，即不使用锁的状况下实现多线程之间的变量同步，也就是在没有线程被阻塞的状况下实现变量的同步，因此也叫非阻塞同步（Non-blocking Synchronization）。CAS算法涉及到三个操做数

• 须要读写的内存值 V
• 进行比较的值 A
• 拟写入的新值 B

当且仅当 V 的值等于 A时，CAS经过原子方式用新值B来更新V的值，不然不会执行任何操做（比较和替换是一个原子操做）。通常状况下是一个自旋操做，即不断的重试。

21.4 乐观锁的缺点

• ABA 问题
  

  • ABA 问题是乐观锁一个常见的问题。若是一个变量V初次读取的时候是A值，而且在准备赋值的时候检查到它仍然是A值，那咱们就能说明它的值没有被其余线程修改过了吗？很明显是不能的，由于在这段时间它的值可能被改成其余值，而后又改回A，那CAS操做就会误认为它历来没有被修改过。这个问题被称为CAS操做的 "ABA"问题。
  • JDK 1.5 之后的 AtomicStampedReference 类就提供了此种能力，其中的 compareAndSet 方法就是首先检查当前引用是否等于预期引用，而且当前标志是否等于预期标志，若是所有相等，则以原子方式将该引用和该标志的值设置为给定的更新值。

• 循环时间长开销大

  自旋CAS（也就是不成功就一直循环执行直到成功）若是长时间不成功，会给CPU带来很是大的执行开销。 若是JVM能支持处理器提供的pause指令那么效率会有必定的提高，pause指令有两个做用，第一它能够延迟流水线执行指令（de-pipeline）,使CPU不会消耗过多的执行资源，延迟的时间取决于具体实现的版本，在一些处理器上延迟时间是零。第二它能够避免在退出循环的时候因内存顺序冲突（memory order violation）而引发CPU流水线被清空（CPU pipeline flush），从而提升CPU的执行效率。

• 只能保证一个共享变量的原子操做

  CAS 只对单个共享变量有效，当操做涉及跨多个共享变量时 CAS 无效。
  可是从 JDK 1.5开始，提供了AtomicReference类来保证引用对象之间的原子性，你能够把多个变量放在一个对象里来进行 CAS 操做.因此咱们可使用锁或者利用AtomicReference类把多个共享变量合并成一个共享变量来操做。

22 锁机制与InnoDB锁算法

22.1 MyISAM和InnoDB存储引擎使用的锁：

• MyISAM 采用表级锁(table-level locking)。
• InnoDB 支持行级锁(row-level locking)和表级锁,默认为行级锁

22.2 表级锁和行级锁对比：

• 表级锁：

  Mysql中锁定 粒度最大 的一种锁，对当前操做的整张表加锁，实现简单，资源消耗也比较少，加锁快，不会出现死锁。其锁定粒度最大，触发锁冲突的几率最高，并发度最低，MyISAM和 InnoDB引擎都支持表级锁。

• 行级锁：

  Mysql中锁定 粒度最小 的一种锁，只针对当前操做的行进行加锁。 行级锁能大大减小数据库操做的冲突。其加锁粒度最小，并发度高，但加锁的开销也最大，加锁慢，会出现死锁。

22.3 InnoDB存储引擎的锁的算法有三种：

• Record lock：单个行记录上的锁
• Gap lock：间隙锁，锁定一个范围，不包括记录自己
• Next-key lock：record+gap 锁定一个范围，包含记录自己
• 相关知识点：
  
  • innodb对于行的查询使用next-key lock
  • Next-locking keying为了解决Phantom Problem幻读问题
  • 当查询的索引含有惟一属性时，将next-key lock降级为record key
  • Gap锁设计的目的是为了阻止多个事务将记录插入到同一范围内，而这会致使幻读问题的产生
  • 有两种方式显式关闭gap锁：（除了外键约束和惟一性检查外，其他状况仅使用record lock）

    A. 将事务隔离级别设置为RC B. 将参数innodb_locks_unsafe_for_binlog设置为1

23 drop、delete与truncate区别？

23.1 用法不一样

• drop(丢弃数据): drop table 表名 ，直接将表都删除掉，在删除表的时候使用。
• truncate (清空数据) : truncate table 表名 ，只删除表中的数据，再插入数据的时候自增加id又从1开始，在清空表中数据的时候使用。
• delete（删除数据） : delete from 表名 where 列名=值，删除某一列的数据，若是不加 where 子句和truncate table 表名做用相似。

truncate 和不带 where 子句的 delete、以及 drop 都会删除表内的数据，可是 truncate 和 delete 只删除数据不删除表的结构(定义)，执行drop语句，此表的结构也会删除，也就是执行 drop 以后对应的表不复存在。

23.2 属于不一样的数据库语言

truncate和drop 属于DDL(数据定义语言)语句，操做当即生效，原数据不放到 rollback segment 中，不能回滚，操做不触发 trigger。而 delete 语句是DML (数据库操做语言)语句，这个操做会放到 rollback segement 中，事务提交以后才生效。

DML 语句和 DDL 语句区别：

• DML是数据库操做语言（Data Manipulation Language ）的缩写，是指对数据库中表记录的操做，主要包括表记录的插入（insert）、更新（update）、删除（delete）和查询（select），是开发人员平常使用最频繁的操做。
• DDL是数据定义语言（Data Definition Language）的缩写，简单来讲，就是对数据库内部的对象进行建立、删除、修改的操做语言。它和 DML 语言的最大区别是 DML 只是对表内部数据的操做，而不涉及到表的定义、结构的修改，更不会涉及到其余对象。DDL 语句更多的被数据库管理员（DBA）所使用，通常的开发人员不多使用。

23.3 执行速度不一样

通常来讲:drop>truncate>delete。

24 数据库设计一般分为哪几步?

• 需求分析 : 分析用户的需求，包括数据、功能和性能需求。
• 概念结构设计 : 主要采用E-R模型进行设计，包括画E-R图。
• 逻辑结构设计 : 经过将E-R图转换成表，实现从E-R模型到关系模型的转换。
• 物理结构设计 : 主要是为所设计的数据库选择合适的存储结构和存取路径。
• 数据库实施 : 包括编程、测试和试运行
• 数据库的运行和维护 : 系统的运行与数据库的平常维护。

参考：

• 剖析面试最多见问题之数据库知识基础
• 剖析面试最多见问题之MySQL
• 315道Python面试题答案