1.主键、外键、超键、候选键
超键：在关系中能惟一标识元组的属性集称为关系模式的超键。一个属性能够为做为一个超键，多个属性组合在一块儿也能够做为一个超键。超键包含候选键和主键。html
候选键：是最小超键，即没有冗余元素的超键。前端
主键： 表中对储存数据对象予以惟一和完整标识的数据列或属性的组合。一个数据列只能有一个主键，且主键的取值不能缺失，即不能为空值（Null）。
外键：在一个表中存在的另外一个表的主键称此表的外键。java
2.为何用自增列做为主键
若是没有显式定义主键，则InnoDB会选择第一个不包含有NULL值的惟一索引做为主键索引、面试
若是也没有这样的惟一索引，则InnoDB会选择内置6字节长的ROWID做为隐含的汇集索引(ROWID随着行记录的写入而主键递增，这个ROWID不像ORACLE的ROWID那样可引用，是隐含的)。算法
数据记录自己被存于主索引（一颗B+Tree）的叶子节点上。这就要求同一个叶子节点内（大小为一个内存页或磁盘页）的各条数据记录按主键顺序存放，所以每当有一条新的记录插入时，MySQL会根据其主键将其插入适当的节点和位置，若是页面达到装载因子（InnoDB默认为15/16），则开辟一个新的页（节点）sql
若是表使用自增主键，那么每次插入新的记录，记录就会顺序添加到当前索引节点的后续位置，当一页写满，就会自动开辟一个新的页数据库
若是使用非自增主键（若是身份证号或学号等），因为每次插入主键的值近似于随机，所以每次新纪录都要被插到现有索引页得中间某个位置，此时MySQL不得不为了将新记录插到合适位置而移动数据，甚至目标页面可能已经被回写到磁盘上而从缓存中清掉，此时又要从磁盘上读回来，这增长了不少开销，同时频繁的移动、分页操做形成了大量的碎片，获得了不够紧凑的索引结构，后续不得不经过OPTIMIZE
TABLE来重建表并优化填充页面。缓存
触发器是一种特殊的存储过程，主要是经过事件来触发而被执行的。它能够强化约束，来维护数据的完整性和一致性，能够跟踪数据库内的操做从而不容许未经许可的更新和变化。能够联级运算。如，某表上的触发器上包含对另外一个表的数据操做，而该操做又会致使该表触发器被触发。安全
4.什么是存储过程？用什么来调用？
存储过程是一个预编译的SQL语句，优势是容许模块化的设计，就是说只需建立一次，之后在该程序中就能够调用屡次。若是某次操做须要执行屡次SQL，使用存储过程比单纯SQL语句执行要快。
1）能够用一个命令对象来调用存储过程。
2）能够供外部程序调用，好比： 程序。
5.存储过程的优缺点？
1）存储过程是预编译过的，执行效率高。
2）存储过程的代码直接存放于数据库中，经过存储过程名直接调用，减小网络通信。
3）安全性高，执行存储过程须要有必定权限的用户。
4）存储过程能够重复使用，可减小数据库开发人员的工做量。
6.存储过程与函数的区别
7.什么叫视图？游标是什么？
是一种虚拟的表，具备和物理表相同的功能。能够对视图进行增，改，查，操做，试图一般是有一个表或者多个表的行或列的子集。对视图的修改会影响基本表。它使得咱们获取数据更容易，相比多表查询。
是对查询出来的结果集做为一个单元来有效的处理。游标能够定在该单元中的特定行，从结果集的当前行检索一行或多行。能够对结果集当前行作修改。通常不使用游标，可是须要逐条处理数据的时候，游标显得十分重要。
1对数据库的访问，由于视图能够有选择性的选取数据库里的一部分。
2)用户经过简单的查询能够从复杂查询中获得结果。
3)维护数据的独立性，试图可从多个表检索数据。
4)对于相同的数据可产生不一样的视图。
性能：查询视图时，必须把视图的查询转化成对基本表的查询，若是这个视图是由一个复杂的多表查询所定义，那么，那么就没法更改数据
- truncate删除表中数据，再插入时自增加id又从1开始。
- delete删除表中数据，能够加where字句。
（1） DELETE语句执行删除的过程是每次从表中删除一行，而且同时将该行的删除操做做为事务记录在日志中保存以便进行进行回滚操做。TRUNCATE TABLE 则一次性地从表中删除全部的数据并不把单独的删除操做记录记入日志保存，删除行是不能恢复的。而且在删除的过程当中不会激活与表有关的删除触发器。执行速度快。
（2） 表和索引所占空间。当表被TRUNCATE 后，这个表和索引所占用的空间会恢复到初始大小，而DELETE操做不会减小表或索引所占用的空间。drop语句将表所占用的空间全释放掉。
（5） TRUNCATE 和DELETE只删除数据，而DROP则删除整个表（结构和数据）。
（6） truncate与不带where的delete ：只删除数据，而不删除表的结构（定义）drop语句将删除表的结构被依赖的约束（constrain),触发器（trigger)索引（index);依赖于该表的存储过程/函数将被保留，但其状态会变为：invalid。
（9） 在没有备份状况下，谨慎使用 drop 与 truncate。要删除部分数据行采用delete且注意结合where来约束影响范围。回滚段要足够大。要删除表用drop;若想保留表而将表中数据删除，若是于事务无关，用truncate便可实现。若是和事务有关，或老师想触发trigger,仍是用delete。
经过释放存储表数据所用的数据页来删除数据，而且只在事务日志中记录页的释放。
（11） TRUNCATE TABLE 删除表中的全部行，但表结构及其列、约束、索引等保持不变。新行标识所用的计数值重置为该列的种子。若是想保留标识计数值，请改用 DELETE。若是要删除表定义及其数据，请使用 DROP TABLE 语句。
10.什么是临时表，临时表何时删除?
临时表只在当前链接可见，当关闭链接时，MySQL会自动删除表并释放全部空间。所以在不一样的链接中能够建立同名的临时表，而且操做属于本链接的临时表。
建立临时表的语法与建立表语法相似，不一样之处是增长关键字TEMPORARY，
11.非关系型数据库和关系型数据库区别，优点比较?
非关系型数据库的优点：
-
性能：NOSQL是基于键值对的，能够想象成表中的主键和值的对应关系，并且不须要通过SQL层的解析，因此性能很是高。
-
可扩展性：一样也是由于基于键值对，数据之间没有耦合性，因此很是容易水平扩展。
-
复杂查询：能够用SQL语句方便的在一个表以及多个表之间作很是复杂的数据查询。
-
事务支持：使得对于安全性能很高的数据访问要求得以实现。
1.对于这两类数据库，对方的优点就是本身的弱势，反之亦然。
2.NOSQL数据库慢慢开始具有SQL数据库的一些复杂查询功能，好比MongoDB。
3.对于事务的支持也能够用一些系统级的原子操做来实现例如乐观锁之类的方法来曲线救国，好比 set nx。
12.数据库范式，根据某个场景设计数据表?
第一范式:(确保每列保持原子性)全部字段值都是不可分解的原子值。
第一范式是最基本的范式。若是数据库表中的全部字段值都是不可分解的原子值，就说明该数据库表知足了第一范式。
第一范式的合理遵循须要根据系统的实际需求来定。好比某些数据库系统中须要用到“地址”这个属性，原本直接将“地址”属性设计成一个数据库表的字段就行。可是若是系统常常会访问“地址”属性中的“城市”部分，那么就非要将“地址”这个属性从新拆分为省份、城市、详细地址等多个部分进行存储，这样在对地址中某一部分操做的时候将很是方便。这样设计才算知足了数据库的第一范式，以下表所示。
上表所示的用户信息遵循了第一范式的要求，这样在对用户使用城市进行分类的时候就很是方便，也提升了数据库的性能。
第二范式:(确保表中的每列都和主键相关)在一个数据库表中，一个表中只能保存一种数据，不能够把多种数据保存在同一张数据库表中。
第二范式在第一范式的基础之上更进一层。第二范式须要确保数据库表中的每一列都和主键相关，而不能只与主键的某一部分相关（主要针对联合主键而言）。也就是说在一个数据库表中，一个表中只能保存一种数据，不能够把多种数据保存在同一张数据库表中。
好比要设计一个订单信息表，由于订单中可能会有多种商品，因此要将订单编号和商品编号做为数据库表的联合主键。
第三范式:(确保每列都和主键列直接相关,而不是间接相关) 数据表中的每一列数据都和主键直接相关，而不能间接相关。
第三范式须要确保数据表中的每一列数据都和主键直接相关，而不能间接相关。
好比在设计一个订单数据表的时候，能够将客户编号做为一个外键和订单表创建相应的关系。而不能够在订单表中添加关于客户其它信息（好比姓名、所属公司等）的字段。
BCNF:符合3NF，而且，主属性不依赖于主属性。
若关系模式属于第二范式，且每一个属性都不传递依赖于键码，则R属于BC范式。
一般BC范式的条件有多种等价的表述：每一个非平凡依赖的左边必须包含键码；每一个决定因素必须包含键码。
BC范式既检查非主属性，又检查主属性。当只检查非主属性时，就成了第三范式。知足BC范式的关系都必然知足第三范式。
还能够这么说：若一个关系达到了第三范式，而且它只有一个候选码，或者它的每一个候选码都是单属性，则该关系天然达到BC范式。
通常，一个数据库设计符合3NF或BCNF就能够了。
第四范式:要求把同一表内的多对多关系删除。
第五范式:从最终结构从新创建原始结构。
13.什么是 内链接、外链接、交叉链接、笛卡尔积等?
内链接: 只链接匹配的行
左外链接: 包含左边表的所有行（无论右边的表中是否存在与它们匹配的行），以及右边表中所有匹配的行
右外链接: 包含右边表的所有行（无论左边的表中是否存在与它们匹配的行），以及左边表中所有匹配的行
全外链接: 包含左、右两个表的所有行，无论另一边的表中是否存在与它们匹配的行。
交叉链接: 生成笛卡尔积－它不使用任何匹配或者选取条件，而是直接将一个数据源中的每一个行与另外一个数据源的每一个行都一一匹配
不少公司都只是考察是否知道其概念，可是也有不少公司须要不只仅知道概念，还须要动手写sql,通常都是简单的链接查询，具体关于链接查询的sql练习，参见如下连接：
1.char的长度是不可变的，而varchar的长度是可变的。
若是存进去的是‘csdn’,那么char所占的长度依然为10，除了字符‘csdn’外，后面跟六个空格，varchar就立马把长度变为4了，取数据的时候，char类型的要用trim()去掉多余的空格，而varchar是不须要的。
2.char的存取数度仍是要比varchar要快得多，由于其长度固定，方便程序的存储与查找。
char也为此付出的是空间的代价，由于其长度固定，因此不免会有多余的空格占位符占据空间，可谓是以空间换取时间效率。
varchar是以空间效率为首位。
3.char的存储方式是：对英文字符（ASCII）占用1个字节，对一个汉字占用两个字节。
varchar的存储方式是：对每一个英文字符占用2个字节，汉字也占用2个字节。
4.二者的存储数据都非unicode的字符数据。
SQL语言共分为四大类：
数据查询语言DQL基本结构是由SELECT子句，FROM子句，WHERE子句组成的查询块：
数据操纵语言DML主要有三种形式：
表 视图 索引 同义词 簇
数据控制语言DCL用来授予或回收访问数据库的某种特权，并控制数据库操纵事务发生的时间及效果，对数据库实行监视等。如：
在数据库的插入、删除和修改操做时，只有当事务在提交到数据
库时才算完成。在事务提交前，只有操做数据库的这我的才能有权看
到所作的事情，别人只有在最后提交完成后才能够看到。
提交数据有三种类型：显式提交、隐式提交及自动提交。下面分
用COMMIT命令直接完成的提交为显式提交。其格式为：
若把AUTOCOMMIT设置为ON，则在插入、修改、删除语句执行后，
系统将自动进行提交，这就是自动提交。其格式为：
%百分号通配符:表示任何字符出现任意次数(能够是0次).
**_下划线通配符:**表示只能匹配单个字符,不能多也不能少,就是一个字符.
like操做符: LIKE做用是指示mysql后面的搜索模式是利用通配符而不是直接相等匹配进行比较.
- 注意大小写,在使用模糊匹配时,也就是匹配文本时,mysql是可能区分大小的,也多是不区分大小写的,这个结果是取决于用户对MySQL的配置方式.若是是区分大小写,那么像YvesHe这样记录是不能被"yves__"这样的匹配条件匹配的.
正如所见， MySQL的通配符颇有用。但这种功能是有代价的：通配符搜索的处理通常要比前面讨论的其余搜索所花时间更长。这里给出一些使用通配符要记住的技巧。
- 不要过分使用通配符。若是其余操做符能达到相同的目的，应该 使用其余操做符。
- 在确实须要使用通配符时，除非绝对有必要，不然不要把它们用 在搜索模式的开始处。把通配符置于搜索模式的开始处，搜索起 来是最慢的。
- 仔细注意通配符的位置。若是放错地方，可能不会返回想要的数.
为了提升搜索效率，咱们须要考虑运用多列索引,因为索引文件以B－Tree格式保存，因此咱们不用扫描任何记录，便可获得最终结果。
注：在mysql中执行查询时，只能使用一个索引，若是咱们在lname,fname,age上分别建索引,执行查询时，只能使用一个索引，mysql会选择一个最严格(得到结果集记录数最少)的索引。
数据库索引，是数据库管理系统中一个排序的数据结构，索引的实现一般使用B树及其变种B+树。
在数据以外，数据库系统还维护着知足特定查找算法的数据结构，这些数据结构以某种方式引用（指向）数据，这样就能够在这些数据结构上实现高级查找算法。这种数据结构，就是索引。
2.索引的做用？它的优势缺点是什么？
协助快速查询、更新数据库表中数据。
为表设置索引要付出代价的：
建立索引能够大大提升系统的性能（优势）：
1.经过建立惟一性索引，能够保证数据库表中每一行数据的惟一性。
2.能够大大加快数据的检索速度，这也是建立索引的最主要的缘由。
3.能够加速表和表之间的链接，特别是在实现数据的参考完整性方面特别有意义。
4.在使用分组和排序子句进行数据检索时，一样能够显著减小查询中分组和排序的时间。
5.经过使用索引，能够在查询的过程当中，使用优化隐藏器，提升系统的性能。
增长索引也有许多不利的方面(缺点)：
1.建立索引和维护索引要耗费时间，这种时间随着数据量的增长而增长。
2.索引须要占物理空间，除了数据表占数据空间以外，每个索引还要占必定的物理空间，若是要创建聚簇索引，那么须要的空间就会更大。
3.当对表中的数据进行增长、删除和修改的时候，索引也要动态的维护，这样就下降了数据的维护速度。
4.哪些列适合创建索引、哪些不适合建索引？
索引是创建在数据库表中的某些列的上面。在建立索引的时候，应该考虑在哪些列上能够建立索引，在哪些列上不能建立索引。
通常来讲，应该在这些列上建立索引：
（1）在常常须要搜索的列上，能够加快搜索的速度；
（2）在做为主键的列上，强制该列的惟一性和组织表中数据的排列结构；
（3）在常常用在链接的列上，这些列主要是一些外键，能够加快链接的速度；
（4）在常常须要根据范围进行搜索的列上建立索引，由于索引已经排序，其指定的范围是连续的；
（5）在常常须要排序的列上建立索引，由于索引已经排序，这样查询能够利用索引的排序，加快排序查询时间；
（6）在常用在WHERE子句中的列上面建立索引，加快条件的判断速度。
对于有些列不该该建立索引：
（1）对于那些在查询中不多使用或者参考的列不该该建立索引。
这是由于，既然这些列不多使用到，所以有索引或者无索引，并不能提升查询速度。相反，因为增长了索引，反而下降了系统的维护速度和增大了空间需求。
（2）对于那些只有不多数据值的列也不该该增长索引。
这是由于，因为这些列的取值不多，例如人事表的性别列，在查询的结果中，结果集的数据行占了表中数据行的很大比例，即须要在表中搜索的数据行的比例很大。增长索引，并不能明显加快检索速度。
（3）对于那些定义为text, image和bit数据类型的列不该该增长索引。
这是由于，这些列的数据量要么至关大，要么取值不多。
(4)当修改性能远远大于检索性能时，不该该建立索引。
这是由于，修改性能和检索性能是互相矛盾的。当增长索引时，会提升检索性能，可是会下降修改性能。当减小索引时，会提升修改性能，下降检索性能。所以，当修改性能远远大于检索性能时，不该该建立索引。
5.什么样的字段适合建索引
惟1、不为空、常常被查询的字段
Hash索引和B+树索引的特色：
为何不都用Hash索引而使用B+树索引？
-
Hash索引仅仅能知足"=","IN"和""查询，不能使用范围查询,由于通过相应的Hash算法处理以后的Hash值的大小关系，并不能保证和Hash运算前彻底同样；
-
Hash索引没法被用来避免数据的排序操做，由于Hash值的大小关系并不必定和Hash运算前的键值彻底同样；
-
Hash索引不能利用部分索引键查询，对于组合索引，Hash索引在计算Hash值的时候是组合索引键合并后再一块儿计算Hash值，而不是单独计算Hash值，因此经过组合索引的前面一个或几个索引键进行查询的时候，Hash索引也没法被利用；
-
Hash索引在任什么时候候都不能避免表扫描，因为不一样索引键存在相同Hash值，因此即便取知足某个Hash键值的数据的记录条数，也没法从Hash索引中直接完成查询，仍是要回表查询数据；
-
Hash索引遇到大量Hash值相等的状况后性能并不必定就会比B+树索引高。
2.经常使用的InnoDB引擎中默认使用的是B+树索引，它会实时监控表上索引的使用状况，若是认为创建哈希索引能够提升查询效率，则自动在内存中的“自适应哈希索引缓冲区”创建哈希索引（在InnoDB中默认开启自适应哈希索引），经过观察搜索模式，MySQL会利用index key的前缀创建哈希索引，若是一个表几乎大部分都在缓冲池中，那么创建一个哈希索引可以加快等值查询。
B+树索引和哈希索引的明显区别是：
3.若是是等值查询，那么哈希索引明显有绝对优点，由于只须要通过一次算法便可找到相应的键值；固然了，这个前提是，键值都是惟一的。若是键值不是惟一的，就须要先找到该键所在位置，而后再根据链表日后扫描，直到找到相应的数据；
4.若是是范围查询检索，这时候哈希索引就毫无用武之地了，由于原先是有序的键值，通过哈希算法后，有可能变成不连续的了，就没办法再利用索引完成范围查询检索；
同理，哈希索引没办法利用索引完成排序，以及like ‘xxx%’ 这样的部分模糊查询（这种部分模糊查询，其实本质上也是范围查询）；
5.哈希索引也不支持多列联合索引的最左匹配规则；
6.B+树索引的关键字检索效率比较平均，不像B树那样波动幅度大，在有大量重复键值状况下，哈希索引的效率也是极低的，由于存在所谓的哈希碰撞问题。
7.在大多数场景下，都会有范围查询、排序、分组等查询特征，用B+树索引就能够了。
7.B树和B+树的区别
- B树，每一个节点都存储key和data，全部节点组成这棵树，而且叶子节点指针为nul，叶子结点不包含任何关键字信息。
- B+树，全部的叶子结点中包含了所有关键字的信息，及指向含有这些关键字记录的指针，且叶子结点自己依关键字的大小自小而大的顺序连接，全部的非终端结点能够当作是索引部分，结点中仅含有其子树根结点中最大（或最小）关键字。 (而B 树的非终节点也包含须要查找的有效信息)
8.为何说B+比B树更适合实际应用中操做系统的文件索引和数据库索引？
1.B+的磁盘读写代价更低
B+的内部结点并无指向关键字具体信息的指针。所以其内部结点相对B树更小。若是把全部同一内部结点的关键字存放在同一盘块中，那么盘块所能容纳的关键字数量也越多。一次性读入内存中的须要查找的关键字也就越多。相对来讲IO读写次数也就下降了。
2.B+tree的查询效率更加稳定
因为非终结点并非最终指向文件内容的结点，而只是叶子结点中关键字的索引。因此任何关键字的查找必须走一条从根结点到叶子结点的路。全部关键字查询的路径长度相同，致使每个数据的查询效率至关。
9.汇集索引和非汇集索引区别?
汇集索引表记录的排列顺序和索引的排列顺序一致，因此查询效率快，只要找到第一个索引值记录，其他就连续性的记录在物理也同样连续存放。汇集索引对应的缺点就是修改慢，由于为了保证表中记录的物理和索引顺序一致，在记录插入的时候，会对数据页从新排序。
汇集索引相似于新华字典中用拼音去查找汉字，拼音检索表于书记顺序都是按照a~z排列的，就像相同的逻辑顺序于物理顺序同样，当你须要查找a,ai两个读音的字，或是想一次寻找多个傻(sha)的同音字时，也许向后翻几页，或紧接着下一行就获得结果了。
非汇集索引指定了表中记录的逻辑顺序，可是记录的物理和索引不必定一致，两种索引都采用B+树结构，非汇集索引的叶子层并不和实际数据页相重叠，而采用叶子层包含一个指向表中的记录在数据页中的指针方式。非汇集索引层次多，不会形成数据重排。
非汇集索引相似在新华字典上经过偏旁部首来查询汉字，检索表也许是按照横、竖、撇来排列的，可是因为正文中是a~z的拼音顺序，因此就相似于逻辑地址于物理地址的不对应。同时适用的状况就在于分组，大数目的不一样值，频繁更新的列中，这些状况即不适合汇集索引。
汇集索引和非汇集索引的根本区别是表记录的排列顺序和与索引的排列顺序是否一致。
事务是对数据库中一系列操做进行统一的回滚或者提交的操做，主要用来保证数据的完整性和一致性。
2.事务四大特性（ACID）原子性、一致性、隔离性、持久性?
原子性是指事务包含的全部操做要么所有成功，要么所有失败回滚，所以事务的操做若是成功就必需要彻底应用到数据库，若是操做失败则不能对数据库有任何影响。
事务开始前和结束后，数据库的完整性约束没有被破坏。好比A向B转帐，不可能A扣了钱，B却没收到。
隔离性是当多个用户并发访问数据库时，好比操做同一张表时，数据库为每个用户开启的事务，不能被其余事务的操做所干扰，多个并发事务之间要相互隔离。同一时间，只容许一个事务请求同一数据，不一样的事务之间彼此没有任何干扰。好比A正在从一张银行卡中取钱，在A取钱的过程结束前，B不能向这张卡转帐。
持久性是指一个事务一旦被提交了，那么对数据库中的数据的改变就是永久性的，即使是在数据库系统遇到故障的状况下也不会丢失提交事务的操做。
3.事务的并发?事务隔离级别，每一个级别会引起什么问题，MySQL默认是哪一个级别?
从理论上来讲, 事务应该彼此彻底隔离, 以免并发事务所致使的问题，然而, 那样会对性能产生极大的影响, 由于事务必须按顺序运行， 在实际开发中, 为了提高性能, 事务会以较低的隔离级别运行， 事务的隔离级别能够经过隔离事务属性指定。
一、脏读：事务A读取了事务B更新的数据，而后B回滚操做，那么A读取到的数据是脏数据
二、不可重复读：事务 A 屡次读取同一数据，事务 B 在事务A屡次读取的过程当中，对数据做了更新并提交，致使事务A屡次读取同一数据时，结果所以本事务前后两次读到的数据结果会不一致。
三、幻读：幻读解决了不重复读，保证了同一个事务里，查询的结果都是事务开始时的状态（一致性）。
例如：事务T1对一个表中全部的行的某个数据项作了从“1”修改成“2”的操做 这时事务T2又对这个表中插入了一行数据项，而这个数据项的数值仍是为“1”而且提交给数据库。 而操做事务T1的用户若是再查看刚刚修改的数据，会发现还有跟没有修改同样，其实这行是从事务T2中添加的，就好像产生幻觉同样，这就是发生了幻读。
小结：不可重复读的和幻读很容易混淆，不可重复读侧重于修改，幻读侧重于新增或删除。解决不可重复读的问题只需锁住知足条件的行，解决幻读须要锁表。
读未提交：另外一个事务修改了数据，但还没有提交，而本事务中的SELECT会读到这些未被提交的数据脏读
不可重复读：事务 A 屡次读取同一数据，事务 B 在事务A屡次读取的过程当中，对数据做了更新并提交，致使事务A屡次读取同一数据时，结果所以本事务前后两次读到的数据结果会不一致。
可重复读：在同一个事务里，SELECT的结果是事务开始时时间点的状态，所以，一样的SELECT操做读到的结果会是一致的。可是，会有幻读现象
串行化：最高的隔离级别，在这个隔离级别下，不会产生任何异常。并发的事务，就像事务是在一个个按照顺序执行同样
事务的隔离级别要获得底层数据库引擎的支持, 而不是应用程序或者框架的支持.
SQL规范所规定的标准，不一样的数据库具体的实现可能会有些差别
MySQL中默认事务隔离级别是“可重复读”时并不会锁住读取到的行
事务隔离级别：未提交读时，写数据只会锁住相应的行。
事务隔离级别为：可重复读时，写数据会锁住整张表。
事务隔离级别为：串行化时，读写数据都会锁住整张表。
隔离级别越高，越能保证数据的完整性和一致性，可是对并发性能的影响也越大，鱼和熊掌不可兼得啊。对于多数应用程序，能够优先考虑把数据库系统的隔离级别设为Read Committed，它可以避免脏读取，并且具备较好的并发性能。尽管它会致使不可重复读、幻读这些并发问题，在可能出现这类问题的个别场合，能够由应用程序采用悲观锁或乐观锁来控制。
1.PROPAGATION_REQUIRED：若是当前没有事务，就建立一个新事务，若是当前存在事务，就加入该事务，该设置是最经常使用的设置。
2.PROPAGATION_SUPPORTS：支持当前事务，若是当前存在事务，就加入该事务，若是当前不存在事务，就以非事务执行。
3.PROPAGATION_MANDATORY：支持当前事务，若是当前存在事务，就加入该事务，若是当前不存在事务，就抛出异常。
5.PROPAGATION_NOT_SUPPORTED：以非事务方式执行操做，若是当前存在事务，就把当前事务挂起。
6.PROPAGATION_NEVER：以非事务方式执行，若是当前存在事务，则抛出异常。
嵌套是子事务套在父事务中执行，子事务是父事务的一部分，在进入子事务以前，父事务创建一个回滚点，叫save point，而后执行子事务，这个子事务的执行也算是父事务的一部分，而后子事务执行结束，父事务继续执行。重点就在于那个save point。看几个问题就明了了：
若是子事务回滚，会发生什么？
父事务会回滚到进入子事务前创建的save point，而后尝试其余的事务或者其余的业务逻辑，父事务以前的操做不会受到影响，更不会自动回滚。
若是父事务回滚，会发生什么？
父事务回滚，子事务也会跟着回滚！为何呢，由于父事务结束以前，子事务是不会提交的，咱们说子事务是父事务的一部分，正是这个道理。那么：
事务的提交，是什么状况？
是父事务先提交，而后子事务提交，仍是子事务先提交，父事务再提交？答案是第二种状况，仍是那句话，子事务是父事务的一部分，由父事务统一提交。
两种存储引擎的大体区别表如今：
1.InnoDB支持事务，MyISAM不支持， 这一点是很是之重要。事务是一种高级的处理方式，如在一些列增删改中只要哪一个出错还能够回滚还原，而MyISAM就不能够了。
2.MyISAM适合查询以及插入为主的应用。
3.InnoDB适合频繁修改以及涉及到安全性较高的应用。
7.InnoDB中不保存表的行数，如select count() from table时，InnoDB须要扫描一遍整个表来计算有多少行，可是MyISAM只要简单的读出保存好的行数便可。注意的是，当count()语句包含where条件时MyISAM也须要扫描整个表。
8.对于自增加的字段，InnoDB中必须包含只有该字段的索引，可是在MyISAM表中能够和其余字段一块儿创建联合索引。
虽然MySQL里的存储引擎不仅是MyISAM与InnoDB这两个，但经常使用的就是两个。
关于MySQL数据库提供的两种存储引擎，MyISAM与InnoDB选择使用：
- 1.INNODB会支持一些关系数据库的高级功能，如事务功能和行级锁，MyISAM不支持。
- 2.MyISAM的性能更优，占用的存储空间少，因此，选择何种存储引擎，视具体应用而定。
若是你的应用程序必定要使用事务，毫无疑问你要选择INNODB引擎。但要注意，INNODB的行级锁是有条件的。在where条件没有使用主键时，照样会锁全表。好比DELETE FROM mytable这样的删除语句。
若是你的应用程序对查询性能要求较高，就要使用MyISAM了。MyISAM索引和数据是分开的，并且其索引是压缩的，能够更好地利用内存。因此它的查询性能明显优于INNODB。压缩后的索引也能节约一些磁盘空间。MyISAM拥有全文索引的功能，这能够极大地优化LIKE查询的效率。
有人说MyISAM只能用于小型应用，其实这只是一种偏见。若是数据量比较大，这是须要经过升级架构来解决，好比分表分库，而不是单纯地依赖存储引擎。
如今通常都是选用innodb了，主要是MyISAM的全表锁，读写串行问题，并发效率锁表，效率低，MyISAM对于读写密集型应用通常是不会去选用的。
MEMORY是MySQL中一类特殊的存储引擎。它使用存储在内存中的内容来建立表，并且数据所有放在内存中。这些特性与前面的两个很不一样。
每一个基于MEMORY存储引擎的表实际对应一个磁盘文件。该文件的文件名与表名相同，类型为frm类型。该文件中只存储表的结构。而其数据文件，都是存储在内存中，这样有利于数据的快速处理，提升整个表的效率。值得注意的是，服务器须要有足够的内存来维持MEMORY存储引擎的表的使用。若是不须要了，能够释放内存，甚至删除不须要的表。
MEMORY默认使用哈希索引。速度比使用B型树索引快。固然若是你想用B型树索引，能够在建立索引时指定。
注意，MEMORY用到的不多，由于它是把数据存到内存中，若是内存出现异常就会影响数据。若是重启或者关机，全部数据都会消失。所以，基于MEMORY的表的生命周期很短，通常是一次性的。
3.MySQL的MyISAM与InnoDB两种存储引擎在，事务、锁级别，各自的适用场景?
关于存储引擎MyISAM和InnoDB的其余参考资料以下：
其中select和from是必须的，其余关键词是可选的，这六个关键词的执行顺序 与sql语句的书写顺序并非同样的，而是按照下面的顺序来执行
from:须要从哪一个数据表检索数据
where:过滤表中数据的条件
group by:如何将上面过滤出的数据分组
having:对上面已经分组的数据进行过滤的条件
select:查看结果集中的哪一个列，或列的计算结果
order by :按照什么样的顺序来查看返回的数据
- 2.from后面的表关联，是自右向左解析 而where条件的解析顺序是自下而上的。
也就是说，在写SQL语句的时候，尽可能把数据量小的表放在最右边来进行关联（用小表去匹配大表），而把能筛选出小量数据的条件放在where语句的最左边 （用小表去匹配大表）
对于复杂、效率低的sql语句，咱们一般是使用explain sql 来分析sql语句，这个语句能够打印出，语句的执行。这样方便咱们分析，进行优化
table：显示这一行的数据是关于哪张表的
type：这是重要的列，显示链接使用了何种类型。从最好到最差的链接类型为const、eq_reg、ref、range、index和ALL
range：索引范围扫描，对索引的扫描开始于某一点，返回匹配值的行，常见与between ，等查询；
ref：非惟一性索引扫描，返回匹配某个单独值的全部行，常见于使用非惟一索引即惟一索引的非惟一前缀进行查找；
eq_ref：惟一性索引扫描，对于每一个索引键，表中只有一条记录与之匹配，经常使用于主键或者惟一索引扫描；
const，system：当MySQL对某查询某部分进行优化，并转为一个常量时，使用这些访问类型。若是将主键置于where列表中，MySQL就能将该查询转化为一个常量。
possible_keys：显示可能应用在这张表中的索引。若是为空，没有可能的索引。能够为相关的域从WHERE语句中选择一个合适的语句
key： 实际使用的索引。若是为NULL，则没有使用索引。不多的状况下，MySQL会选择优化不足的索引。这种状况下，能够在SELECT语句中使用USE INDEX（indexname）来强制使用一个索引或者用IGNORE INDEX（indexname）来强制MySQL忽略索引
key_len：使用的索引的长度。在不损失精确性的状况下，长度越短越好
ref：显示索引的哪一列被使用了，若是可能的话，是一个常数
rows：MySQL认为必须检查的用来返回请求数据的行数
Extra：关于MySQL如何解析查询的额外信息。将在表4.3中讨论，但这里能够看到的坏的例子是Using temporary和Using filesort，意思MySQL根本不能使用索引，结果是检索会很慢。
1.mysql都有什么锁，死锁断定原理和具体场景，死锁怎么解决?
MySQL有三种锁的级别：页级、表级、行级。
-
表级锁：开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的几率最高,并发度最低。
-
行级锁：开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的几率最低,并发度也最高。
-
页面锁：开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度通常
什么状况下会形成死锁?
死锁: 是指两个或两个以上的进程在执行过程当中。因争夺资源而形成的一种互相等待的现象,若无外力做用,它们都将没法推动下去。此时称系统处于死锁状态或系统产生了死锁,这些永远在互相等竺的进程称为死锁进程。
表级锁不会产生死锁.因此解决死锁主要仍是针对于最经常使用的InnoDB。
死锁的关键在于：两个(或以上)的Session加锁的顺序不一致。
那么对应的解决死锁问题的关键就是：让不一样的session加锁有次序。
Innodb 行锁的等待时间，单位秒。可在会话级别设置，RDS 实例该参数的默认值为 50（秒）。
该参数支持在会话级别修改，方便应用在会话级别单独设置某些特殊操做的行锁等待超时时间，以下：
2.有哪些锁（乐观锁悲观锁），select 时怎么加排它锁?
悲观锁特色:先获取锁，再进行业务操做。
即“悲观”的认为获取锁是很是有可能失败的，所以要先确保获取锁成功再进行业务操做。一般所说的“一锁二查三更新”即指的是使用悲观锁。一般来说在数据库上的悲观锁须要数据库自己提供支持，即经过经常使用的select … for update操做来实现悲观锁。当数据库执行select for
update时会获取被select中的数据行的行锁，所以其余并发执行的select for update若是试图选中同一行则会发生排斥（须要等待行锁被释放），所以达到锁的效果。select for update获取的行锁会在当前事务结束时自动释放，所以必须在事务中使用。
不一样的数据库对select for update的实现和支持都是有所区别的，
- MySQL还有个问题是select for update语句执行中全部扫描过的行都会被锁上，这一点很容易形成问题。所以若是在MySQL中用悲观锁务必要肯定走了索引，而不是全表扫描。
1.乐观锁，也叫乐观并发控制，它假设多用户并发的事务在处理时不会彼此互相影响，各事务可以在不产生锁的状况下处理各自影响的那部分数据。在提交数据更新以前，每一个事务会先检查在该事务读取数据后，有没有其余事务又修改了该数据。若是其余事务有更新的话，那么当前正在提交的事务会进行回滚。
2.乐观锁的特色先进行业务操做，不到万不得已不去拿锁。即“乐观”的认为拿锁多半是会成功的，所以在进行完业务操做须要实际更新数据的最后一步再去拿一下锁就好。
乐观锁在数据库上的实现彻底是逻辑的，不须要数据库提供特殊的支持。
3.通常的作法是在须要锁的数据上增长一个版本号，或者时间戳，
乐观锁（给表加一个版本号字段） 这个并非乐观锁的定义，给表加版本号，是数据库实现乐观锁的一种方式。
// 乐观锁获取成功，操做完成
// 乐观锁获取失败，回滚并重试
- 乐观锁在不发生取锁失败的状况下开销比悲观锁小，可是一旦发生失败回滚开销则比较大，所以适合用在取锁失败几率比较小的场景，能够提高系统并发性能
- 乐观锁还适用于一些比较特殊的场景，例如在业务操做过程当中没法和数据库保持链接等悲观锁没法适用的地方。
悲观锁和乐观锁是数据库用来保证数据并发安全防止更新丢失的两种方法，例子在select ... for update前加个事务就能够防止更新丢失。悲观锁和乐观锁大部分场景下差别不大，一些独特场景下有一些差异，通常咱们能够从以下几个方面来判断。
所谓的同步复制，意思是master的变化，必须等待slave-1,slave-2,...,slave-n完成后才能返回。 这样，显然不可取，也不是MySQL复制的默认设置。好比，在WEB前端页面上，用户增长了条记录，须要等待很长时间。
如同AJAX请求同样。master只须要完成本身的数据库操做便可。至于slaves是否收到二进制日志，是否完成操做，不用关心,MySQL的默认设置。
master只保证slaves中的一个操做成功，就返回，其余slave无论。 这个功能，是由google为MySQL引入的。
2.数据库主从复制分析的 7 个问题?
问题1：master的写操做，slaves被动的进行同样的操做，保持数据一致性，那么slave是否能够主动的进行写操做？
假设slave能够主动的进行写操做，slave又没法通知master，这样就致使了master和slave数据不一致了。所以slave不该该进行写操做，至少是slave上涉及到复制的数据库不能够写。实际上，这里已经揭示了读写分离的概念。
问题2：主从复制中，能够有N个slave,但是这些slave又不能进行写操做，要他们干吗？
相似于高可用的功能，一旦master挂了，可让slave顶上去，同时slave提高为master。
异地容灾:好比master在北京，地震挂了，那么在上海的slave还能够继续。
主要用于实现scale out,分担负载,能够将读的任务分散到slaves上。
【极可能的状况是，一个系统的读操做远远多于写操做，所以写操做发向master，读操做发向slaves进行操做】
select用connection(for slaves)进行操做。那咱们的应用程序还要完成怎么从slaves选择一个来执行select，例如使用简单的轮循算法。
这样的话，至关于应用程序完成了SQL语句的路由，并且与MySQL的主从复制架构很是关联，一旦master挂了，某些slave挂了，那么应用程序就要修改了。能不能让应用程序与MySQL的主从复制架构没有什么太多关系呢？
找一个组件，application program只须要与它打交道，用它来完成MySQL的代理，实现SQL语句的路由。
MySQL proxy并不负责，怎么从众多的slaves挑一个？能够交给另外一个组件(好比haproxy)来完成。
总统通常都会弄个副总统，以防不测。一样的，能够给这些关键的节点来个备份。
问题5：当master的二进制日志每产生一个事件，都须要发往slave，若是咱们有N个slave,那是发N次，仍是只发一次？若是只发一次，发给了slave-1，那slave-2,slave-3,...它们怎么办？
显 然，应该发N次。实际上，在MySQL master内部，维护N个线程，每个线程负责将二进制日志文件发往对应的slave。master既要负责写操做，还的维护N个线程，负担会很重。能够这样，slave-1是master的从，slave-1又是slave-2,slave-3,...的主，同时slave-1再也不负责select。
slave-1将master的复制线程的负担，转移到本身的身上。这就是所谓的多级复制的概念。
问题6：当一个select发往MySQL proxy，可能此次由slave-2响应，下次由slave-3响应，这样的话，就没法利用查询缓存了。
问题7：随着应用的日益增加，读操做不少，咱们能够扩展slave，可是若是master知足不了写操做了，怎么办呢？
scale on ?更好的服务器？ 没有最好的，只有更好的，太贵了。。。
scale out ? 主从复制架构已经知足不了。
能够分库【垂直拆分】，分表【水平拆分】。
MySQL 高并发环境解决方案： 分库 分表 分布式 增长二级缓存。。。。。
需求分析：互联网单位 天天大量数据读取，写入，并发性高。
现有解决方式：水平分库分表，由单点分布到多点数据库中，从而下降单点数据库压力。
集群方案：解决DB宕机带来的单点DB不能访问问题。
读写分离策略：极大限度提升了应用中Read数据的速度和并发量。没法解决高写入压力。
4.数据库崩溃时事务的恢复机制（REDO日志和UNDO日志）?
Undo Log是为了实现事务的原子性，在MySQL数据库InnoDB存储引擎中，还用了Undo Log来实现多版本并发控制(简称：MVCC)。
事务的原子性(Atomicity)事务中的全部操做，要么所有完成，要么不作任何操做，不能只作部分操做。若是在执行的过程当中发生了错误，要回滚(Rollback)到事务开始前的状态，就像这个事务历来没有执行过。
原理Undo Log的原理很简单，为了知足事务的原子性，在操做任何数据以前，首先将数据备份到一个地方（这个存储数据备份的地方称为UndoLog）。而后进行数据的修改。若是出现了错误或者用户执行了ROLLBACK语句，系统能够利用Undo Log中的备份将数据恢复到事务开始以前的状态。
之因此能同时保证原子性和持久化，是由于如下特色：
为了保证持久性，必须将数据在事务提交前写到磁盘。只要事务成功提交，数据必然已经持久化。
Undo log必须先于数据持久化到磁盘。若是在G,H之间系统崩溃，undo log是完整的， 能够用来回滚事务。
若是在A-F之间系统崩溃,由于数据没有持久化到磁盘。因此磁盘上的数据仍是保持在事务开始前的状态。
缺陷：每一个事务提交前将数据和Undo Log写入磁盘，这样会致使大量的磁盘IO，所以性能很低。
若是可以将数据缓存一段时间，就能减小IO提升性能。可是这样就会丧失事务的持久性。所以引入了另一种机制来实现持久化，即Redo Log。
原理和Undo Log相反，Redo Log记录的是新数据的备份。在事务提交前，只要将Redo Log持久化便可，不须要将数据持久化。当系统崩溃时，虽然数据没有持久化，可是Redo Log已经持久化。系统能够根据Redo Log的内容，将全部数据恢复到最新的状态。
