数据库设计方面
1. 避免全表扫描
2. 考虑在where以及order by 设计的列上建立索引
3. 尽量避免在where字句上对null值进行判断(否则引擎放弃使用索引而进行全表扫描)
Select id from table where num is null;
可以再num上设置默认值 0 ,确保表中num列没有null 值,然后这样查询
select id from table where num = 0;
4. 并不是所有索引对查询都有效,当索引中有大量数据重复的时候,查询可能不会用索引
5. 索引不是越多越好,索引会降低insert 以及update的效率,一个表的索引最好不要超过6个,不常使用的列应考虑
建索引的必要性
6. 尽量避免更新索引数据列
7. 尽量使用数字型字段
8. 尽量使用varchar/nvarchar代替char/nchar
9. 尽量使用表变量代替临时表,如果表包含大量数据,请注意索引非常有限(只有主键有索引)
10. 避免频繁创建和删除临时表
11. 在新建临时表时,如果一次性插入的数据量很大,就可以使用select into 代替 create table,如果数据量不大,应
先 createtable,再insert
SQL优化
1. 尽量避免在where子句中使用 !=、(<>)操作符
2. 尽量避免在where子句中使用 or 来连接条件
select id from table num = 10 or num = 20;
#尽量改成
Select id from t where num = 10 union all select id from t where num= 20;
3.
Select id from table where num= @num;
#建议改为
Select id from t with(index(索引名)) num = @num;
4. In /not in 要慎用 能用between就不要用in了
Select id from t where num in (1,2,3);
#对于连续的值,可以改为
Select id from t where num between 1 and 3;
5. Select id from t where name like ‘%abc%’可能会搜索全表
6. 尽量避免在where子句中对字段进行表达式操作
7. 尽量避免在where子句中对字段进行函数操作
8. 不要再where 子句中的“=”左边进行函数、算数运算或其他表达式运算
9. 很多时候用 exists 代替 in 是一个好的选择
select num from a where num in(select num from b);
#用下面的语句替换:
select num from a where exists(select 1 from b where num=a.num);
10. 任何地方都不要使用 select * from t ,用具体的字段列表代替“*”,不要返回用不到的任何字段。
11. 尽量避免使用游标,因为游标的效率较差,如果游标操作的数据超过1万行,那么就应该考虑改写。
12. 尽量避免向客户端返回大数据量,若数据量过大,应该考虑相应需求是否合理。
13. 尽量避免大事务操作,提高系统并发能力。
JAVA方面:重点内容
补充
1) 硬件调整性能
最有可能影响性能的是磁盘和网络吞吐量,解决办法扩大虚拟内存,并保证有足够可以扩充的空间;把数据库服务器上的不必要服务关闭掉;把数据库服务器和主域服务器分开;把SQL数据库服务器的吞吐量调为最大;在具有一个以上处理器的机器上运行SQL。
2)调整数据库
若对该表的查询频率比较高,则建立索引;建立索引时,想尽对该表的所有查询搜索操作, 按照where选择条件建立索引,尽量为整型键建立为有且只有一个簇集索引,数据在物理上按顺序在数据页上,缩短查找范围,为在查询经常使用的全部列建立非簇集索引,能最大地覆盖查询;但是索引不可太多,执行UPDATE DELETE INSERT语句需要用于维护这些索引的开销量急剧增加;避免在索引中有太多的索引键;避免使用大型数据类型的列为索引;保证每个索引键值有少数行。
3)使用存储过程
应用程序的实现过程中,能够采用存储过程实现的对数据库的操作尽量通过存储过程来实现,因为存储过程是存放在数据库服务器上的一次性被设计、编码、测试,并被再次使用,需要执行该任务的应用可以简单地执行存储过程,并且只返回结果集或者数值,这样不仅可以使程序模块化,同时提高响应速度,减少网络流量,并且通过输入参数接受输入,使得在应用中完成逻辑的一致性实现。
4)应用程序结构和算法
建立查询条件索引仅仅是提高速度的前提条件,响应速度的提高还依赖于对索引的使用。因为人们在
使用SQL时往往会陷入一个误区,即太关注于所得的结果是否正确,特别是对数据量不是特别大的数据库操作时,是否建立索引和使用索引的好坏对程序的响应速度并不大,因此程序员在书写程序时就忽略了不同的实现方法之间可能存在的性能差异,这种性能差异在数据量特别大时或者大型的或是复杂的数据库环境中(如联机事务处理OLTP或决策支持系统DSS)中表现得尤为明显。在工作实践中发现,不良的SQL往往来自于不恰当的索引设计、不充份的连接条件和不可优化的where子句。在对它们进行适当的优化后,其运行速度有了明显地提高!
--- 【本篇博客非本人原创!】