使用SQL时必须考虑的五个关键因素
使用SQL时必须考虑的关键因素
一，获得结果集所需访问的数据量，在没有确定目标容量之前，很难断定查询执行的效率；
二，定义结果集所需的查询条件，也就是如何限定结果集，如何合理的使用sql子句；
三，结果集的大小，取决于表的大小和过滤条件的细节，但不都是这样，典型的情况是，若干个独立使用时效率不高的条件，结合起来使用时会产生很高的效率。比如说：“是不否获得理科学位或文科学位”作为查询学生姓名的条件，结果集很大。但同时使用这两个条件（双学位），则产生的结果集大小就会大幅缩小。还有一个很意思的地方，用户最终的感觉也非常重要，用户的耐心，在很大程度上和预期返回的记录条数有关：用户只检索一条记录，则他期望非常快，而有时检索一条记录也需要访问整个数据库，令最终用户沮丧的事情莫过于等了很久却看到“无相符数据”的结果，所以好的开发者应该让返回少量记录或不返回记录的查询尽量快，原则就是，无论何时，只要查询有可能返回零结果集时，都应该先检查那个最大可能导致空结果集的条件。
四，获得结果集所涉及的表的数量，表的数量影响最大的无疑是join操作。其实，现代DBMS都能比较高效地连接很多表，这可能会当前许多初学者的认识相悖。当然连接大量表时会产生一些额外的问题，
1）当需要连接很多表时，按常理你应该怀疑你的设计的正确性；
2）对于优化器来说，随着表数量的增加，复杂度将呈指数增长。
3）编写涉及多表的复杂查询，若可以进行连接的方式有好多种，增加了分析优化器进行优化的难度，最终选择出的连接路径很可能是错误的。
当有还有一个问题需要注意，有时我们需要在使用复杂查询时，如果既可以通过已定义的视图来获得数据，也可以通过分解视图，将其组成部分变成sql语句加到查询主体中，那么常常应该采用后者，因为这样可以减少不必要的联接视图的操作，尽管需要sql编程技巧有所要求。（其实，oracle中的物化视图中查询重写中用到了跟这相反的机制，当然这二者的目的是不一样的。）
五，多少用户会同时修改这些数据。也就是说写数据库操作必须关注并发性，是否存在block的访问争用、阻塞，或者闩定（DBMS内部资源阻塞）。还有一种情况，比如说，排序操作可能会没有足够内存可用，于是转而求助于磁盘，引发新的资源争用。
相关文档：
1.查询的模糊匹配
尽量避免在一个复杂查询里面使用 LIKE '%parm1%'—— 红色标识位置的百分号会导致相关列的索引无法使用，最好不要用。
解决办法:
其实只需要对该脚本略做改进，查询速度便会提高近百倍。改进方法如下：
a、修改前台程序—&mdas ......
问题描述：有以下2张表，
a_id a_name ......
3。表内容如下
-----------------------------
ID LogTime
1 2008/10/10 10:00:00
1 2008/10/1 ......
如何使用 SSL 来确保与 SQL Server 2000 安全通信
更新日期： 2004年04月20日
本页内容
目标
适用范围
如何使用本章内容
摘要
您必须了解的背景知识
安装服务器验证证书
验证证书是否已安装
在客户端安装 CA 颁发的证书
强制所有客户端使用 SSL
允许客户端决定是否使用 SSL
验证通信是否已加密
其他� ......
1、 sql查询最后一条数据select * from table order by id DESC limit 1
2、select top1 * from tablename where order by id desc
通过在mysql中测试，只有第一种可以使用，不知道其他数据库是否支持第二种方法，网上很多人说用第二种方法 ......
