Oracle

1. 什么时候适合建立索引?

   1.表的主键、外键必须有索引；
   2.数据量超过300的表应该有索引；
   3.经常与其他表进行连接的表，在连接字段上应该建立索引；
   4.经常出现在Where子句中的字段，特别是大表的字段，应该建立索引；
   5.索引应该建在选择性高的字段上；
   6.索引应该建在小字段上，对于大的文本字段甚至超长字段，不要建索引；
   7.复合索引的建立需要进行仔细分析；尽量考虑用单字段索引代替.

2. Oracle中function和procedure的区别？

   　相同点：1.创建语法结构相似，都可以携带多个传入参数和传出参数;
   　　　　 2.都是一次编译，多次执行。
   　　不同点：1.存储过程定义关键字用procedure,函数定义用function;
   　　　　　　2.存储过程中不能用return返回值，但函数中可以，而且函数中必须有return子句;
   　　　　　　3.执行方式略有不同，存储过程的执行方式有两种（1.使用execute2.使用begin和end），函数除了存储过程的两种方式外，还可以当做表达式使用，例如放在select中（select f1() form dual;）。
   总结：如果只有一个返回值，用存储函数，否则，一般用存储过程.

3. 怎样优化Oracle数据库，有几种方式？

   物理优化:
   　 1）Oracle的运行环境（网络，硬件等);
   　　2）使用合适的优化器 ;
   　　3）合理配置oracle实例参数 ;
   　　4）建立合适的索引（减少IO);
   　　5）将索引数据和表数据分开在不同的表空间上（降低IO冲突);
   　　6）建立表分区，将数据分别存储在不同的分区上（以空间换取时间，减少IO).

逻辑优化;
　 1）可以对表进行逻辑分割，如中国移动用户表，可以根据手机尾数分成10个表，这样对性能会有一定的作用;
　　2）Sql语句使用占位符语句，并且开发时候必须按照规定编写sql语句（如全部大写，全部小写等）oracle解析语句后会放置到共享池中， 如：
　　select * from Emp where name=？这个语句只会在共享池中有一条，而如果是字符串的话，那就根据不同名字存在不同的语句，所以占位符效率较好;
　　3）数据库不仅仅是一个存储数据的地方，同样是一个编程的地方，一些耗时的操作，可以通过存储过程等在用户较少的情况下执行，从而错开系统使用的高峰时间，提高数据库性能;
　　4）尽量不使用号，如select from Emp，因为要转化为具体的列名是要查数据字典， 比较耗时;
　　5）选择有效的表名
　　对于多表连接查询，可能oracle的优化器并不会优化到这个程度， oracle 中多表查询是根据FROM字句从右到左的数据进行的，那么最好右边的表（也就是基础表）选 择数据较少的表，这样排序更快速，如果有link表（多对多中间表），那么将link表放最右边作为基础表，在默认情况下oracle会自动优化，但是如 果配置了优化器的情况下，可能不会自动优化，所以平时最好能按照这个方式编写sql ;
　　6）Where字句规则：
　　Oracle 中Where字句时从右往左处理的，表之间的连接写在其他条件之前，能过滤掉非常多的数据的条件，放在where的末尾， 另外！=符号比较的列将不使用索引，列经过了计算（如变大写等）不会使用索引（需要建立起函数）， is null、is not null等优化器不会使用索引;
　　7）使用Exits Not Exits 替代 In Not in;
　　8）合理使用事务，合理设置事务隔离性，数据库的数据操作比较消耗数据库资源的，尽量使用批量处理，以降低事务操作次数.

1. Oracle分区是怎样优化数据库的?

   1、调整数据结构的设计。这一部分在开发信息系统之前完成，程序员需要考虑是否使用ORACLE数据库的分区功能，对于经常访问的数据库表是否需要建立索引等;

   2、调整应用程序结构设计。这一部分也是在开发信息系统之前完成，程序员在这一步需要考虑应用程序使用什么样的体系结构，是使用传统的Client/Server两层体系结构，还是使用Browser/Web/Database的三层体系结构。不同的应用程序体系结构要求的数据库资源是不同的;

   3、调整数据库SQL语句。应用程序的执行最终将归结为数据库中的SQL语句执行，因此SQL语句的执行效率最终决定了ORACLE数据库的性能。ORACLE公司推荐使用ORACLE语句优化器（Oracle Optimizer）和行锁管理器（row-level manager）来调整优化SQL语句。

2. 索引的优缺点?

优点:
第一: 通过创建唯一性索引，可以保证数据库表中每一行数据的唯一性;
第二: 可以大大加快数据的检索速度，这也是创建索引的最主要的原因;
第三: 可以加速表和表之间的连接，特别是在实现数据的参考完整性方面特别有意义;
第四: 在使用分组和排序子句进行数据检索时，同样可以显著减少查询中分组和排序的时间;
第五: 通过使用索引可以在查询的过程中使用优化隐藏器提高系统的性能。

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

1. 数据库的三大范式:

   第一范式（1NF）：强调的是列的原子性，即列不能够再分成其他几列。
   考虑这样一个表：【联系人】（姓名，性别，电话）
   如果在实际场景中，一个联系人有家庭电话和公司电话，那么这种表结构设计就没有达到 1NF。要符合 1NF 我们只需把列（电话）拆分，即：【联系人】（姓名，性别，家庭电话，公司电话）。1NF 很好辨别，但是 2NF 和 3NF 就容易搞混淆。

◆ 第二范式（2NF）：首先是 1NF，另外包含两部分内容，一是表必须有一个主键；二是没有包含在主键中的列必须完全依赖于主键，而不能只依赖于主键的一部分。
考虑一个订单明细表：【OrderDetail】（OrderID，ProductID，UnitPrice，Discount，Quantity，ProductName）。
因为我们知道在一个订单中可以订购多种产品，所以单单一个 OrderID 是不足以成为主键的，主键应该是（OrderID，ProductID）。显而易见 Discount（折扣），Quantity（数量）完全依赖（取决）于主键（OderID，ProductID），而 UnitPrice，ProductName 只依赖于 ProductID。所以 OrderDetail 表不符合 2NF。不符合 2NF 的设计容易产生冗余数据。
可以把【OrderDetail】表拆分为【OrderDetail】（OrderID，ProductID，Discount，Quantity）和【Product】（ProductID，UnitPrice，ProductName）来消除原订单表中UnitPrice，ProductName多次重复的情况。

◆ 第三范式（3NF）：首先是 2NF，另外非主键列必须直接依赖于主键，不能存在传递依赖。即不能存在：非主键列 A 依赖于非主键列 B，非主键列 B 依赖于主键的情况。
考虑一个订单表【Order】（OrderID，OrderDate，CustomerID，CustomerName，CustomerAddr，CustomerCity）主键是（OrderID）。
其中 OrderDate，CustomerID，CustomerName，CustomerAddr，CustomerCity 等非主键列都完全依赖于主键（OrderID），所以符合 2NF。不过问题是 CustomerName，CustomerAddr，CustomerCity 直接依赖的是 CustomerID（非主键列），而不是直接依赖于主键，它是通过传递才依赖于主键，所以不符合 3NF。
通过拆分【Order】为【Order】（OrderID，OrderDate，CustomerID）和【Customer】（CustomerID，CustomerName，CustomerAddr，CustomerCity）从而达到 3NF。