1、存储过程的优点是什么？ 存储过程的优点： 1.提高性能 2.减轻网络拥塞 3.一致性较好 4.改善安全机制

一个触发器是由T-SQL语句集组成的代码块，在响应某些动作时激活该语句集        

有insert,delete,update触发器 

它防止了对数据的不正确、未授权的和不一致的改变

3、常见的几种约束有哪些？分别代表什么意思？如何使用？ 

1)实体完整性：主键保证了实体完整性，一个表只有一个主键，但一个主键可有包含多个字段，主键字段不能为空 

2)参照完整性：外键保证了引用完整性，一个表可以有多个外键 

3)用户定义完整性：CHECK保证了域完整性， 一个表中可以有多个检查性约束 

4、事务：是一系列的数据库操作，是数据库应用的基本逻辑单位。

事务性质：ACID特性
原子性(Atomicity):事务的所有操作在数据库中要么全部正确的反映出来，要么完全不反映；

一致性(Consistency)：执行前后数据保持一致，比如，转帐系统执行前后，两者的总钱数保持一致；

隔离性(Isolation)：尽管多个事务可能并发执行，但执行的结果与某个串行执行相同，因此，每个事务都感觉不到系统中其他事务在并发执行，隔离性是并发控制的主要任务；

持久性(Durability)一个事务成功执行完成后，它对数据库的改变必须是永久的，即使出现系统故障，持久性是恢复系统的主要任务

5、内联接与外联接
内连接是保证两个表中所有的行都要满足连接条件，而外连接则不然。在外连接中，某些不满条件的列也会显示出来，也就是说，只限制其中一个表的行，而不限制另一个表的行。分左连接、右连接、全连接三种

6、视图

视图是数据库数据的特定子集。可以禁止所有用户访问数据库表，而要求用户只能通过视图操作数据，这种方法可以保护用户和应用程序不受某些数据库修改的影响。2.视图是抽象的，他在使用时，从表里提取出数据，形成虚的表。 视图没有自己的数据，当用户操作视图时，数据库才把相应的操作转化为对应表的操作，视图仅仅是预先定义好的一些SQL操作，它是在基本表之上建立的表，它的结构（即所定义的列）和内容（即所有数据行）都来自基本表，它依据基本表存在而存在。一个视图可以对应一个基本表，也可以对应多个基本表。

7、索引：参考文献

优点：

第一，可以大大加快 数据的检索速度，这也是创建索引的最主要的原因。

第二，通过创建唯一性索引，可以保证数据库表中每一行数据的唯一性。 

缺点：

第一，创建索引和维护索引要耗费时间，这种时间随着数据 量的增加而增加。 
第二，索引需要占物理空间，除了数据表占数据空间之外，每一个索引还要占一定的物理空间，如果要建立聚簇索引，那么需要的空间就会更大。 
第三，当对表中的数据进行增加、删除和修改的时候，索引也要动态的维护，这样就降低了数据的维护速度。

索引是建立在数据库表中的某些列的上面。因此，在创建索引的时候，应该仔细考虑在哪些列上可以创建索引，在哪些列上不能创建索引。一般来说，应该在这些列 上创建索引，例如：

在经常需要搜索的列上，可以加快搜索的速度； 
在作为主键的列上，强制该列的唯一性和组织表中数据的排列结构； 
在经常用在连接的列上，这 些列主要是一些外键，可以加快连接的速度； 
在经常需要根据范围进行搜索的列上创建索引，因为索引已经排序，其指定的范围是连续的； 
在经常需要排序的列上创 建索引，因为索引已经排序，这样查询可以利用索引的排序，加快排序查询时间； 
在经常使用在WHERE子句中的列上面创建索引，加快条件的判断速度。

同样，对于有些列不应该创建索引。一般来说，不应该创建索引的的这些列具有下列特点：

第一，对于那些在查询中很少使用或者参考的列不应该创建索引。这是因 为，既然这些列很少使用到，因此有索引或者无索引，并不能提高查询速度。相反，由于增加了索引，反而降低了系统的维护速度和增大了空间需求。 
第二，对于那 些只有很少数据值的列也不应该增加索引。这是因为，由于这些列的取值很少，例如人事表的性别列，在查询的结果中，结果集的数据行占了表中数据行的很大比 例，即需要在表中搜索的数据行的比例很大。增加索引，并不能明显加快检索速度。 
第三，对于那些定义为text, image和bit数据类型的列不应该增加索引。这是因为，这些列的数据量要么相当大，要么取值很少。 
第四，当修改性能远远大于检索性能时，不应该创建索 引。这是因为，修改性能和检索性能是互相矛盾的。当增加索引时，会提高检索性能，但是会降低修改性能。当减少索引时，会提高修改性能，降低检索性能。因 此，当修改性能远远大于检索性能时，不应该创建索引。

索引的几种方式

8、SQL标准定义的四个隔离级别(都是与事务相关的)   参考

通过一些现象，可以反映出隔离级别的效果。这些现象有：

1、更新丢失（lost update）：当系统允许两个事务同时更新同一数据是，发生更新丢失。

3、非重复读（nonrepeatableread）：同一查询在同一事务中多次进行，由于其他提交事务所做的修改或删除，每次返回不同的结果集，此时发生非重复读。

4、幻像（phantom read）：同一查询在同一事务中多次进行，由于其他提交事务所做的插入操作，每次返回不同的结果集，此时发生幻像读。

下面是隔离级别及其对应的可能出现或不可能出现的现象

ORACLE的隔离级别  ORACLE提供了SQL92标准中的readcommitted和serializable

mysql的InnoDB存储引擎默认支持的隔离级别是Repeatable read

在标准SQL规范中，定义了4个事务隔离级别，不同的隔离级别对事务的处理不同:

◆未授权读取（Read Uncommitted）：允许脏读取，但不允许更新丢失。如果一个事务已经开始写数据，则另外一个事务则不允许同时进行写操作，但允许其他事务读此行数据。该隔离级别可以通过“排他写锁”实现。

◆授权读取（Read Committed）：允许不可重复读取，但不允许脏读取。这可以通过“瞬间共享读锁”和“排他写锁”实现。读取数据的事务允许其他事务继续访问该行数据，但是未提交的写事务将会禁止其他事务访问该行。

◆可重复读取（Repeatable Read）：禁止不可重复读取和脏读取，但是有时可能出现幻影数据。这可以通过“共享读锁”和“排他写锁”实现。读取数据的事务将会禁止写事务（但允许读事务），写事务则禁止任何其他事务。

◆序列化（Serializable）：提供严格的事务隔离。它要求事务序列化执行，事务只能一个接着一个地执行，但不能并发执行。如果仅仅通过“行级锁”是无法实现事务序列化的，必须通过其他机制保证新插入的数据不会被刚执行查询操作的事务访问到。

隔离级别越高，越能保证数据的完整性和一致性，但是对并发性能的影响也越大，通过选用不同的隔离等级就可以在不同程度上避免前面所提及的在事务处理中所面临的各种问题。所以，数据库隔离级别的选取就显得尤为重要，在选取数据库的隔离级别时，应该注意以下几个处理的原则：

首先，必须排除“未授权读取”，因为在多个事务之间使用它将会是非常危险的。事务的回滚操作或失败将会影响到其他并发事务。第一个事务的回滚将会完全将其他事务的操作清除，甚至使数据库处在一个不一致的状态。很可能一个已回滚为结束的事务对数据的修改最后却修改提交了，因为“未授权读取”允许其他事务读取数据，最后整个错误状态在其他事务之间传播开来。

其次，绝大部分应用都无须使用“序列化”隔离（一般来说，读取幻影数据并不是一个问题），此隔离级别也难以测量。目前使用序列化隔离的应用中，一般都使用悲观锁，这样强行使所有事务都序列化执行。

剩下的也就是在“授权读取”和“可重复读取”之间选择了。我们先考虑可重复读取。如果所有的数据访问都是在统一的原子数据库事务中，此隔离级别将消除一个事务在另外一个并发事务过程中覆盖数据的可能性（第二个事务更新丢失问题）。这是一个非常重要的问题，但是使用可重复读取并不是解决问题的唯一途径。

9、聚集索引与非聚集索引 

聚簇索引是一种对磁盘上实际数据重新组织以按指定的一个或多个列的值排序。由于聚簇索引的索引页面指针指向数据页面，所以使用聚簇索引查找数据几乎总是比使用非聚簇索引快。每张表只能建一个聚簇索引，在聚簇索引下，数据在物理上按顺序排在数据页上，重复值也排在一起，因而在那些包含范围检查(between、<、<=、& gt;、>=)或使用groupby或order by的查询时，一旦找到具有范围中第一个键值的行，具有后续索引值的行保证物理上毗连在一起而不必进一步搜索，避免了大范围扫描，可以大大提高查询速度。

10、日志文件 redo 和 undo的作用

在事务T开始开始之前，日志中写入记录<T start>，执行过程中，T执行任何write(X)操作前先要向日志中写入适当的新的记录，当T提交时，日志中写入记录<T commit>，总的来说就是先写日志，后更新记录。

在这里我们先说恢复的一般方法：
(1）正向扫描日志文件（从头到尾），找出故障发生前已经提交的事务（存在begin transaction和commit记录），将其标识记入重做（redo）队列。同时找出故障发生时未完成的事务（只有begin transaction，没commit），将其标识记入（undo）队列
(2）对undo队列的各事务进行撤销处理。进行undo的处理方法是，反向扫描日志文件，对每个undo事务的更新操作执行反操作，即将日志记录中“更新前的值”写入数据库。

(3）对重做日志中的各事务进行重做操作。进行redo的处理方法是，正向扫描日志，对每个redo事务重新执行日志文件登记操作。即将日志中“更新后的值”写入数据库。

数据库经典问题