什么是存储过程？有哪些优缺点？
存储过程简单来说就是为了以后使用而保存的一条或多条预编译SQL语句，这些语句块像一个方法一样执行一些功能。
优点：
- 类似于封装，简化操作；
- 不用反复建立一系列处理步骤，保证了数据的完整性；
- 通过存储过程能够使没有权限的用户在控制之下间接地存取数据库，从而确保数据的安全。
- 简化对变动的管理，安全；
- 存储过程是一个编译过的代码块，速度快，性能高；
缺点：
- SQL本身是一种结构化查询语言，但不是OO的，本质上还是过程化的，面对复杂的业务逻辑，过程化的处理会很吃力；
- 存储过程的编写比基本SQL语句复杂，需要较高的技能
- 可能没有创建存储过程的权限
索引是什么？有什么作用？以及优缺点？使用索引查询一定能提高查询性能吗？
索引是存储引擎用于快速找到记录的一种数据结构,索引类似一本书的目录,我们根据目录可以快速的查找到我们感兴趣的内容。索引就是存储引擎的目录,如果没有索引存储引擎必须遍历整个数据库表来查询符合条件的记录。一般来说，索引的建立和优化应该是提升查询性能最有效的手段。
优点：
（1）通过创建唯一性索引，可以保证数据库表中每一行数据的唯一性。
（2）可以大大加快 数据的检索速度，这也是创建索引的最主要的原因。
（3）可以加速表和表之间的连接，特别是在实现数据的参考完整性方面特别有意义。
（4）在使用分组和排序 子句进行数据检索时，同样可以显著减少查询中分组和排序的时间。
（5）通过使用索引，可以在查询的过程中，使用优化隐藏器，提高系统的性能。
缺点：
（1）创建索引和维护索引要耗费时间，这种时间随着数据 量的增加而增加。
（2）索引需要占物理空间，除了数据表占数据空间之外，每一个索引还要占一定的物理空间，如果要建立聚簇索引，那么需要的空间就会更大。
（3）当对表中的数据进行增加、删除和修改的时候，索引也要动态的维护，这样就降低了数据的维护速度。
既然索引可以加快查询速度，那么是不是只要是查询语句需要，就建上索引？答案是否定的。因为索引虽然加快了查询速度，但索引也是有代价的：索引文件本身要消耗存储空间，同时索引会加重插入、删除和修改记录时的负担，另外，MySQL在运行时也要消耗资源维护索引，因此索引并不是越多越好。一般两种情况下不建议建索引。
第一种情况是表记录比较少，例如一两千条甚至只有几百条记录的表，没必要建索引，让查询做全表扫描就好了。至于多少条记录才算多，这个个人有个人的看法，我个人的经验是以2000作为分界线，记录数不超过 2000可以考虑不建索引，超过2000条可以酌情考虑索引。
另一种不建议建索引的情况是索引的选择性较低。所谓索引的选择性（Selectivity），是指不重复的索引值（也叫基数，Cardinality）与表记录数（#T）的比值：
Index Selectivity = Cardinality / #T
显然选择性的取值范围为(0, 1]，选择性越高的索引价值越大。
什么是事务？
事务（Transaction）是并发控制的基本单位。所谓的事务，它是一个操作序列，这些操作要么都执行，要么都不执行，它是一个不可分割的工作单位。事务是数据库维护数据一致性的单位，在每个事务结束时，都能保持数据一致性。满足ACID特性。
数据库的乐观锁和悲观锁？
数据库管理系统（DBMS）中的并发控制的任务是确保在多个事务同时存取数据库中同一数据时不破坏事务的隔离性和统一性以及数据库的统一性。
乐观并发控制(乐观锁)和悲观并发控制（悲观锁）是并发控制主要采用的技术手段。
- 悲观锁：假定会发生并发冲突，屏蔽一切可能违反数据完整性的操作
- 乐观锁：假设不会发生并发冲突，只在提交操作时检查是否违反数据完整性。
悲观锁：
在对任意记录进行修改前，先尝试为该记录加上排他锁（exclusive locking）。
如果加锁失败，说明该记录正在被修改，那么当前查询可能要等待或者抛出异常。 具体响应方式由开发者根据实际需要决定。
如果成功加锁，那么就可以对记录做修改，事务完成后就会解锁了。
其间如果有其他对该记录做修改或加排他锁的操作，都会等待我们解锁或直接抛出异常。
优点与不足
悲观并发控制实际上是“先取锁再访问”的保守策略，为数据处理的安全提供了保证。但是在效率方面，处理加锁的机制会让数据库产生额外的开销，还有增加产生死锁的机会；另外，在只读型事务处理中由于不会产生冲突，也没必要使用锁，这样做只能增加系统负载；还有会降低了并行性，一个事务如果锁定了某行数据，其他事务就必须等待该事务处理完才可以处理那行数
乐观锁:
在关系数据库管理系统里，乐观并发控制是一种并发控制的方法。它假设多用户并发的事务在处理时不会彼此互相影响，各事务能够在不产生锁的情况下处理各自影响的那部分数据。在提交数据更新之前，每个事务会先检查在该事务读取数据后，有没有其他事务又修改了该数据。如果其他事务有更新的话，正在提交的事务会进行回滚。
相对于悲观锁，在对数据库进行处理的时候，乐观锁并不会使用数据库提供的锁机制。一般的实现乐观锁的方式就是记录数据版本。数据版本,为数据增加的一个版本标识。当读取数据时，将版本标识的值一同读出，数据每更新一次，同时对版本标识进行更新。当我们提交更新的时候，判断数据库表对应记录的当前版本信息与第一次取出来的版本标识进行比对，如果数据库表当前版本号与第一次取出来的版本标识值相等，则予以更新，否则认为是过期数据。实现数据版本有两种方式，第一种是使用版本号，第二种是使用时间戳。
优点与不足
乐观并发控制相信事务之间的数据竞争(data race)的概率是比较小的，因此尽可能直接做下去，直到提交的时候才去锁定，所以不会产生任何锁和死锁。但如果直接简单这么做，还是有可能会遇到不可预期的结果，例如两个事务都读取了数据库的某一行，经过修改以后写回数据库，这时就遇到了问题。
简单说一下DROP, DELETE, TRUNCATE的区别？
- DELETE：执行删除的过程是每次从表中删除一行，并且同时将该行的删除操作作为事务记录在日志中保存以便进行进行回滚操作。DELETE只是删除表中的数据，并不删除表本身； 可以回滚撤销。
- TRUNCATE ：TRUNCATE与DELETE语句执行相同的功能，但是在删除的过程中不会激活与表有关的删除触发器，速度更快，实际是删除原来的表并重新创建一个新的表，不是逐行删除；删除所有的数据时并不把单独的删除操作记录记入日志保存，删除行是不能恢复的。TRUNCATE只是删除表中的数据，并不删除表本身；不可以回滚撤销。
- DROP：drop语句删除表结构及所有数据，并将表所占用的空间全部释放。drop是DDL，会隐式提交，所以，不能回滚，不会触发触发器。drop语句将删除表的结构所依赖的约束，触发器，索引，依赖于该表的存储过程/函数将保留,但是变为invalid状态。不可以回滚撤销。
速度：DROP > TRUNCATE > DELETE
只能对table使用TRUNCATE；
可以对table和view使用DELETE;
DROP, DELETE, TRUNCATE 分别在什么场景下使用？
如果想完全删除数据表，使用DROP；
如果想删除表中的所有数据，但是保留表结构，使用TRUNCATE TABLE；
其他使用DELETE，但是要带上where语句
超键，主键，外键，候选键分别是什么？
假设有如下两个表：
学生（学号，姓名，性别，身份证号，教师编号） 教师（教师编号，姓名，工资）
- 主键(primary key)：对数据库表中的每一行数据进行唯一标识的字段。
- 外键(foreign key)：是表中的一列，其值必须在另一个表的主键中。外键主要是用来描述两个表的关系。
- 超键(super key)：在关系中能唯一标识元组的属性集称为关系模式的超键。 比如一张学生信息表，学生表中含有学号或者身份证号的任意组合都为此表的超键。如：（学号）、（学号，姓名）、（身份证号，性别）等。
- 候选键(candidate key)：不含有多余属性的超键称为候选键，也称为最小超键 候选键属于超键，它是最小的超键，就是说如果再去掉候选键中的任何一个属性它就不再是超键了。学生表中的候选键为：（学号）、（身份证号）。
什么是视图？视图的优缺点？以及视图的使用场景？
视图是基于 SQL 语句的结果集的可视化的虚拟表。与包含数据的表不同，视图只包含使用时动态检索数据的查询。视图是基于表或另一个视图的逻辑表,视图没有自己的数据，它自己没有存储的段。通过创建表的视图可以显示数据的逻辑子集或组合，视图可以按每个用户不同的视角去纵向或者横向查询和显示数据子集。
视图的优点：
（1）简化用户操作：
视图不仅可以简化用户对数据的理解，也可以简化他们的操作。视图机制使用户可以将注意力集中在所关心地数据上。如果这些数据不是直接来自基本表，则可以通过定义视图，使数据库看起来结构简单、清晰，并且可以简化用户的的数据查询操作。
（2）用户能以多种角度看待同一数据：
使不同的用户以不同的方式看待同一数据，当许多不同种类的用户共享同一个数据库时，这种灵活性是非常必要的。
（3）对重构数据库提供了一定程度的逻辑独立性：
视图可以使应用程序和数据库表在一定程度上独立。数据的物理独立性是指用户的应用程序不依赖于数据库的物理结构。数据的逻辑独立性是指当数据库重构造时，如增加新的关系或对原有的关系增加新的字段，用户的应用程序不会受影响。层次数据库和网状数据库一般能较好地支持数据的物理独立性，而对于逻辑独立性则不能完全的支持。
（4）安全性，对机密数据提供安全保护：
通过视图用户只能查询和修改他们所能见到的数据。
视图的缺点：
（1）性能差：
把视图查询转化成对基本表的查询，如果这个视图是由一个复杂的多表查询所定义，那么，即使是视图的一个简单查询，sql server也要把它变成一个复杂的结合体，需要花费一定的时间。
（2）修改限制：
当用户试图修改试图的某些信息时，数据库必须把它转化为对基本表的某些信息的修改，对于简单的试图来说，这是很方便的，但是，对于比较复杂的试图，可能是不可修改的。
视图使用场景：
（1）权限控制的时候。当用户需要查询未授权的数据表且又需要部分数据表的部分列进行逻辑处理，不希望用户访问表中某些含敏感信息的列。
（2）关键信息来源于多个复杂关联表，可以创建视图提取我们需要的信息，简化操作；
视图的分类：
（1）关系视图：
它属于数据库对象的一种，也就是最常见的一种关联查询；
（2）内嵌视图：
它不属于任何用户，也不是对象，创建方式与普通视图完全不同，不具有可复用性，不能通过数据字典获取数据；
（3）对象视图：
它是基于表对象类型的视图，特性是继承、封装等可根据需要构建对象类型封装复杂查询(官方:为了迎合对象类型而重建数据表是不实现的)；
（4）物化视图：
它主要用于数据库的容灾(备份)，实体化的视图可存储和查询，通过DBLink连接在主数据库物化视图中复制，当主库异常备库接管实现容灾；
三个范式？
待补充。。。