3，SQL语句及数据库优化

时间：2016-05-19 23:10:52 阅读：188 评论：0 收藏：0 [点我收藏+]

标签：

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‘

以上两句语句，查询优化器认为是不同的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通常情况下，连接比子查询效率要高

必然的，需要子查询时，也是用临时表暂存中间结果

3，SQL语句及数据库优化

标签：

原文地址：http://www.cnblogs.com/zkp2010/p/5510506.html

踩

(0)

评论一句话评论（0）

分享档案

更多>

2021年07月29日 (22)
2021年07月28日 (40)
2021年07月27日 (32)
2021年07月26日 (79)
2021年07月23日 (29)
2021年07月22日 (30)
2021年07月21日 (42)
2021年07月20日 (16)
2021年07月19日 (90)
2021年07月16日 (35)

周排行