使用SQL时必须考虑的五个关键因素

 使用SQL时必须考虑的关键因素

一，获得结果集所需访问的数据量，在没有确定目标容量之前，很难断定查询执行的效率；

二，定义结果集所需的查询条件，也就是如何限定结果集，如何合理的使用sql子句；

三，结果集的大小，取决于表的大小和过滤条件的细节，但不都是这样，典型的情况是，若干个独立使用时效率不高的条件，结合起来使用时会产生很高的效率。比如说：“是不否获得理科学位或文科学位”作为查询学生姓名的条件，结果集很大。但同时使用这两个条件（双学位），则产生的结果集大小就会大幅缩小。还有一个很意思的地方，用户最终的感觉也非常重要，用户的耐心，在很大程度上和预期返回的记录条数有关：用户只检索一条记录，则他期望非常快，而有时检索一条记录也需要访问整个数据库，令最终用户沮丧的事情莫过于等了很久却看到“无相符数据”的结果，所以好的开发者应该让返回少量记录或不返回记录的查询尽量快，原则就是，无论何时，只要查询有可能返回零结果集时，都应该先检查那个最大可能导致空结果集的条件。

四，获得结果集所涉及的表的数量，表的数量影响最大的无疑是join操作。其实，现代DBMS都能比较高效地连接很多表，这可能会当前许多初学者的认识相悖。当然连接大量表时会产生一些额外的问题，
 1）当需要连接很多表时，按常理你应该怀疑你的设计的正确性；
 2）对于优化器来说，随着表数量的增加，复杂度将呈指数增长。
 3）编写涉及多表的复杂查询，若可以进行连接的方式有好多种，增加了分析优化器进行优化的难度，最终选择出的连接路径很可能是错误的。
 当有还有一个问题需要注意，有时我们需要在使用复杂查询时，如果既可以通过已定义的视图来获得数据，也可以通过分解视图，将其组成部分变成sql语句加到查询主体中，那么常常应该采用后者，因为这样可以减少不必要的联接视图的操作，尽管需要sql编程技巧有所要求。（其实，oracle中的物化视图中查询重写中用到了跟这相反的机制，当然这二者的目的是不一样的。）

 

五，多少用户会同时修改这些数据。也就是说写数据库操作必须关注并发性，是否存在block的访问争用、阻塞，或者闩定（DBMS内部资源阻塞）。还有一种情况，比如说，排序操作可能会没有足够内存可用，于是转而求助于磁盘，引发新的资源争用。