1,统一SQL语句的写法
对于以下两句SQL语句,程序员认为是相同的,数据库查询优化器认为是不同的。 所以封装成复用方法,用标准模板来控制。
select*from dual
select*From dual
其实就是大小写不同,查询分析器就认为是两句不同的SQL语句,必须进行两次解析。生成2个执行计划
2,不要把SQL语句写得太复杂
我经常看到,从数据库中捕捉到的一条SQL语句打印出来有2张A4纸这么长。一般来说这么复杂的语句通常都是有问题的。我拿着这2页长的SQL语句去请教原作者,结果他说时间太长,他一时也看不懂了。可想而知,连原作者都有可能看糊涂的SQL语句,数据库也一样会看糊涂。
比如 Select语句的结果作为子集
简化SQL语句的重要方法就是采用临时表暂存中间结果,但是,临时表的好处远远不止这些,将临时结果暂存在临时表,后面的查询就在tempdb中了,这可以避免程序中多次扫描主表 也大大减少了程序执行中“共享锁”阻塞“更新锁”,减少了阻塞,提高了并发性能。
3,必须采用绑定变量
select*from orderheader where changetime >'2010-10-20 00:00:01'
select*from orderheader where changetime >'2010-09-22 00:00:01'
select*from orderheader where changetime >'2010-09-22 00:00:01'
以上两句语句,查询优化器认为是不同的SQL语句,需要解析两次。如果采用绑定变量
select*from orderheader where changetime >@chgtime
4,使用like进行模糊查询时应注意
有的时候会需要进行一些模糊查询比如
select*from contact where username like ‘%yue%’
关键词%yue%,由于yue前面用到了“%”,因此该查询必然走全表扫描,除非必要,否则不要在关键词前加%,
5,联表查询
(1) 连接字段尽量选择聚集索引所在的字段
(2) 仔细考虑where条件,尽量减小A、B表的结果集
6,索引,
看sql 的性能,主要看执行计划,还有cpu成本,io成本等。这里就以一个简单的表为例。
首先,创建一个简单的表,一般会先建个主键,系统自动以主键建聚集索引。
判断是否需要优化sql的一个简单规则是:看执行计划中的操作是seek(搜索)还是scan(扫描)
是scan的话就要索引。
使用场景:
当一个系统查询比较频繁,而新建,修改等操作比较少时,可以创建覆盖索引,将查询字段和where子句里的字段全部包含在内,这样查询的速度会比以前快很多,同时也带来弊端,就是新建或修改等操作时,比没有索引或没有建立覆盖索引时的要慢。读写数据库分离也能解决问题
经常对Creator_Id字段查询,就做个索引。
对表Article的Creator_Id字段建索引
CREATE INDEX Ix_article_creatorid ON Article(Creator_Id)
set statistics io 和 set statistics,这是性能调优时查看相关cpu占用时间,IO资源数据的两个比较重要的命令
记得Order by 语句加索引
7,读写分离
当主数据库进行写操作时,数据要同步到从的数据库,这样才能有效保证数据库完整性
主从分离,对数据库层面就是数据同步或者是数据复制;从应用层讲就是请求的分离:增删改请求主库,查询请求从库
8,尽量不用select * from …..
,而要写字段名 select field1,field2,…这条没什么好说的,主要是按需查询,不要返回不必要的列和行。
9 任何对列的操作都将导致表扫描,
它包括数据库函数、计算表达式等,查询时要尽可能将操作移至等号右边
10 In 、or子句常会使索引失效
显而易见的,IN,OR扩大的查询范围。
11通常情况下,连接比子查询效率要高
必然的,需要子查询时,也是用临时表暂存中间结果