怎么成为仲裁员:数据库的查询优化方法分析

数据库的查询优化方法分析

1. 尽量不要使用 or，使用or会引起全表扫描，将大大降低查询效率。

2.alice like '%"&abigale&"%' 会使索引不起作用(针对sqlserver)

3.经过实践验证，charindex()并不比前面加%的like更能提高查询效率，并且charindex()会使索引失去作用（指sqlserver数据库）

4.字段提取要按照“需多少、提多少”的原则，避免“select *”，尽量使用“select 字段1,字段2,字段3........”。实践证明：每少提取一个字段，数据的提取速度就会有相应的提升。提升的速度还要看您舍弃的字段的大小来判断。

5. order by按聚集索引列排序效率最高。一个sqlserver数据表只能建立一个聚集索引，一般默认为ID，也可以改为其它的字段。

6.能使用exists和not exists尽量使用，避免使用in或not in

7.能使用表连接尽量使用，避免使用exists和not exists

 
8.SET NOCOUNT ON

9.正确使用UNION和UNION ALL

10.慎用SELECT DISTINCT

11.少用游标

12. 使用表的别名(Alias)：

当在SQL语句中连接多个表时，请使用表的别名并把别名前缀于每个Column上，这样可以减少解析的时间并减少那些由Column歧义引起的语法错误。

.尽量少使用游标
     原因很简单;就是游标的算法是最原始的计算机算法(和for.if等语句一样,一条条搜索来算;效率极低);
而sql语句用的是集合运算;速度则快的多;如果用索引速度则很快(用了指针).

2.创建索引.
a.聚集索引:
   聚集索引是磁盘存储和逻辑显示是一样的
   mssql表的主键一般是聚集索引;主键(每一条记录唯一确定);
   创建的主键自动会是聚集索引;
   如有一个非常大的表(有百万行);很长时间磁盘存储上会有类似碎片(磁盘填充率效率低;一般是频繁删除造成的);
    要提高它的性能的最简洁办法是:把这个表的主键去掉再保存后;然后重新设主键再保存;
    (这个表就会在磁盘上重新整理排序;性能当然会提高哟)
b.非聚集索引:
   非聚集索引是在外面建立小的附加表(一种树形结构;大多数是B或B+树);
   读(遍历select等sql语句)表特快;但写(update;delete.insert等sql语句)表性能会略微下降.
   针对数据量大的表建议非聚集索引不要超过3个(节省额外磁盘负担).
   不要给类似“性别”列创建索引.

3.死锁:
是指有线程在读一条记录;别的线程读这条记录就要等待;
在mssql中只要长期占那条记录的线程去掉;死锁就会解除.
在mssql中锁是针对每一行记录(所以性能不错).
经常产生锁的原因有:
   a.在sql语句中使用事务语句(特别是事务中当查询比较耗时).
   b.在前台的应用程序的connetion冲突(未关闭).
   c.多表联合查询(尤其是在打开大的数据集时).

4.sql语句优化
a.'is null' 'not' 'or' 'in'不会用索引
b.避免在索引列上使用计算或函数处理(索引会大失性能).还有'%';有的甚至会全失索引性能
c.SELECT中避免使用 ‘ * ‘(宁可把需要字段列出来;而不要用*去把所有的字段都列出来).
d.避免相关子查询(select中套select).
e.where的条件中'=＞exists＞in'(指性能)
f.'order by' 'group by' 'having' 'distinct'等语句要慎用(因为它们效率不高;它们是先把数据到临时表中再进行处理的).
g.聚集索引如有2个字段组成(tt1和tt2);tt1在前面;where的条件中如只用tt1字段来判断;就会用到一半的聚集索引;
   where的条件中如tt1和tt2字段都用来判断了;就会全用到聚集索引;
   where的条件中如只用tt2字段来判断;就会用不到聚集索引了;

5.尽量不要使用TEXT数据类型
   除非你使用TEXT处理一个很大的数据，否则不要使用它。因为它不易于查询，速度慢，用的不好还会浪费大量的空间。
   一般的，VARCHAR可以更好的处理你的数据。

6.尽量不要使用临时表
   尽量不要使用临时表，除非你必须这样做。一般使用子查询可以代替临时表。使用临时表会带来系统开销，
   如果前台的代码你是使用数据库连接池而临时表却自始至终都存在。SQL Server提供了一些替代方案，比如Table数据类型。

7.尽量少使用外键和触发器。
因为在mssql中这些功能的性能做得不是很好;随便动一下表(它就会到相关的表去搞判断;有很多情况并不需要);在后台消耗资源大.
宁可在前台多写些相关表的操作的代码.