SQL SERVER性能优化

1、 用程序中,保证在实现功能的基础上,尽量减少对数据库的访问次数;通过搜索参数,尽量减少对表的访问行数,最小化结果集,从而减轻网络负担;能够分开的操作尽量分开处理,提高每次的响应速度;在数据窗口使用SQL时,尽量把使用的索引放在选择的首列;

  算法的结构尽量简单;在查询时,不要过多地使用通配符如SELECT * FROM T1语句,要用到几列就选择几列如:SELECT COL1,COL2 FROM T1;在可能的情况下尽量限制尽量结果集行数如:SELECT TOP 300 COL1,COL2,COL3 FROM T1,因为某些情况下用户是不需要那么多的数据的。不要在应用中使用数据库游标,游标是非常有用的工具,但比使用常规的、面向集的SQL语句需要更大的开销;按照特定顺序提取数据的查找。

  2、 避免使用不兼容的数据类型。例如float和int、char和varchar、binary和varbinary是不兼容的。数据类型的不兼容可能使优化器无法执行一些本来可以进行的优化操作。例如:

 
 
SELECT name FROM employee WHERE salary > 60000

  在这条语句中,如salary字段是money型的,则优化器很难对其进行优化,因为60000是个整型数。我们应当在编程时将整型转化成为钱币型,而不要等到运行时转化。

  3、 尽量避免在WHERE子句中对字段进行函数或表达式操作,这将导致引擎放弃使用索引而进行全表扫描。如:

 
 
SELECT * FROM T1 WHERE F1 / 2 = 100

  应改为:

 
 
SELECT * FROM T1 WHERE F1 = 100 * 2 SELECT * FROM RECORD WHERE SUBSTRING(CARD_NO, 1 , 4 ) = 5378

  应改为:

 
 
SELECT * FROM RECORD WHERE CARD_NO LIKE ‘ 5378 % ’ SELECT member_number, first_name, last_name FROM members WHERE DATEDIFF(yy,datofbirth,GETDATE()) > 21

  应改为:

 
 
SELECT member_number, first_name, last_name FROM members WHERE dateofbirth < DATEADD(yy, - 21 ,GETDATE())

  即:任何对列的操作都将导致表扫描,它包括数据库函数、计算表达式等等,查询时要尽可能将操作移至等号右边。

  4、 避免使用!=或<>、IS NULL或IS NOT NULL、IN ,NOT IN等这样的操作符,因为这会使系统无法使用索引,而只能直接搜索表中的数据。例如:

 
 
SELECT id FROM employee WHERE id != ' B% '

  优化器将无法通过索引来确定将要命中的行数,因此需要搜索该表的所有行。

  5、 尽量使用数字型字段,一部分开发人员和数据库管理人员喜欢把包含数值信息的字段
设计为字符型,这会降低查询和连接的性能,并会增加存储开销。这是因为引擎在处理查询和连接回逐个比较字符串中每一个字符,而对于数字型而言只需要比较一次就够了。

  6、 合理使用EXISTS,NOT EXISTS子句。如下所示:

 
 
1 .SELECT SUM(T1.C1)FROM T1 WHERE( (SELECT COUNT( * )FROM T2 WHERE T2.C2 = T1.C2 > 0 ) 2 .SELECT SUM(T1.C1) FROM T1WHERE EXISTS( SELECT * FROM T2 WHERE T2.C2 = T1.C2)

  两者产生相同的结果,但是后者的效率显然要高于前者。因为后者不会产生大量锁定的表扫描或是索引扫描。
  如果你想校验表里是否存在某条纪录,不要用count(*)那样效率很低,而且浪费服务器资源。可以用EXISTS代替。如:

 
 
IF (SELECT COUNT( * ) FROM table_name WHERE column_name = ' xxx ' )

  可以写成:

 
 
IF EXISTS (SELECT * FROM table_name WHERE column_name = ' xxx ' )

  经常需要写一个T_SQL语句比较一个父结果集和子结果集,从而找到是否存在在父结果集中有而在子结果集中没有的记录,如:

 
 
1 .SELECT a.hdr_key FROM hdr_tbl a ---- tbl a 表示tbl用别名a代替 WHERE NOT EXISTS (SELECT * FROM dtl_tbl b WHERE a.hdr_key = b.hdr_key) 2 .SELECT a.hdr_key FROM hdr_tbl a LEFT JOIN dtl_tbl b ON a.hdr_key = b.hdr_key WHERE b.hdr_key IS NULL 3 .SELECT hdr_key FROM hdr_tbl WHERE hdr_key NOT IN (SELECT hdr_key FROM dtl_tbl)

  三种写法都可以得到同样正确的结果,但是效率依次降低。

  7、 尽量避免在索引过的字符数据中,使用非打头字母搜索。这也使得引擎无法利用索引。见如下例子:

 
 
SELECT * FROM T1 WHERE NAME LIKE ‘ % L % ’ SELECT * FROM T1 WHERE SUBSTING(NAME, 2 , 1 ) = ’L’ SELECT * FROM T1 WHERE NAME LIKE ‘L %

  即使NAME字段建有索引,前两个查询依然无法利用索引完成加快操作,引擎不得不对全表所有数据逐条操作来完成任务。而第三个查询能够使用索引来加快操作。

  8、 分利用连接条件,在某种情况下,两个表之间可能不只一个的连接条件,这时在 WHERE 子句中将连接条件完整的写上,有可能大大提高查询速度。例:

 
 
SELECT SUM(A.AMOUNT) FROM ACCOUNT A,CARD B WHERE A.CARD_NO = B.CARD_NO SELECT SUM(A.AMOUNT) FROM ACCOUNT A,CARD B WHERE A.CARD_NO = B.CARD_NO AND A.ACCOUNT_NO = B.ACCOUNT_NO

  第二句将比第一句执行快得多。

  9、 消除对大型表行数据的顺序存取

  尽管在所有的检查列上都有索引,但某些形式的WHERE子句强迫优化器使用顺序存取。如:

 
 
SELECT * FROM orders WHERE (customer_num = 104 AND order_num > 1001 ) OR order_num = 1008

  解决办法可以使用并集来避免顺序存取:

 
 
SELECT * FROM orders WHERE customer_num = 104 AND order_num > 1001 UNION SELECT * FROM orders WHERE order_num = 1008

  这样就能利用索引路径处理查询。

  10、 避免困难的正规表达式

  LIKE关键字支持通配符匹配,技术上叫正规表达式。但这种匹配特别耗费时间。例如:SELECT * FROM customer WHERE zipcode LIKE “98_ _ _”

  即使在zipcode字段上建立了索引,在这种情况下也还是采用顺序扫描的方式。如果把语句改为SELECT * FROM customer WHERE zipcode >“98000”,在执行查询时就会利用索引来查询,显然会大大提高速度。

  11、 使用视图加速查询

  把表的一个子集进行排序并创建视图,有时能加速查询。它有助于避免多重排序操作,而且在其他方面还能简化优化器的工作。例如:

 
 
SELECT cust.name,rcvbles.balance,……other columns FROM cust,rcvbles WHERE cust.customer_id = rcvlbes.customer_id AND rcvblls.balance > 0 AND cust.postcode > 98000 ” ORDER BY cust.name

  如果这个查询要被执行多次而不止一次,可以把所有未付款的客户找出来放在一个视图中,并按客户的名字进行排序: 

 
 
CREATE VIEW DBO.V_CUST_RCVLBES AS SELECT cust.name,rcvbles.balance,……other columns FROM cust,rcvbles WHERE cust.customer_id = rcvlbes.customer_id AND rcvblls.balance > 0 ORDER BY cust.name

  然后以下面的方式在视图中查询:

 
 
SELECT * FROM V_CUST_RCVLBES WHERE postcode > 98000

  视图中的行要比主表中的行少,而且物理顺序就是所要求的顺序,减少了磁盘I/O,所以查询工作量可以得到大幅减少。

  12、 能够用BETWEEN的就不要用IN

 
 
SELECT * FROM T1 WHERE ID IN ( 10 , 11 , 12 , 13 , 14 )

  改成:

 
 
SELECT * FROM T1 WHERE ID BETWEEN 10 AND 14

  因为IN会使系统无法使用索引,而只能直接搜索表中的数据。

  13、 DISTINCT的就不用GROUP BY

 
 
SELECT OrderID FROM Details WHERE UnitPrice > 10 GROUP BY OrderID

  可改为:

 
 
SELECT DISTINCT OrderID FROM Details WHERE UnitPrice > 10

  14、 部分利用索引

 
 
1 .SELECT employeeID, firstname, lastname FROM names WHERE dept = ' prod ' or city = ' Orlando ' or division = ' food ' 2 .SELECT employeeID, firstname, lastname FROM names WHERE dept = ' prod ' UNION ALL SELECT employeeID, firstname, lastname FROM names WHERE city = ' Orlando ' UNION ALL SELECT employeeID, firstname, lastname FROM names WHERE division = ' food '

  如果dept 列建有索引则查询2可以部分利用索引,查询1则不能。

  15、 能用UNION ALL就不要用UNION 。UNION ALL不执行SELECT DISTINCT函数,这样就会减少很多不必要的资源

  16、 不要写一些不做任何事的查询,如:

 
 
SELECT COL1 FROM T1 WHERE 1 = 0 SELECT COL1 FROM T1 WHERE COL1 = 1 AND COL1 = 2

  这类死码不会返回任何结果集,但是会消耗系统资源。

  17、 尽量不要用SELECT INTO语句。SELECT INOT 语句会导致表锁定,阻止其他用户访问该表。

  18、 必要时强制查询优化器使用某个索引

 
 
SELECT * FROM T1 WHERE nextprocess = 1 AND processid IN ( 8 , 32 , 45 )

  改成:

 
 
SELECT * FROM T1 (INDEX = IX_ProcessID) WHERE nextprocess = 1 AND processid IN ( 8 , 32 , 45 )

  则查询优化器将会强行利用索引IX_ProcessID 执行查询。

  19、 虽然UPDATE、DELETE语句的写法基本固定,但是还是对UPDATE语句给点建议:

  a) 尽量不要修改主键字段。

  b) 当修改VARCHAR型字段时,尽量使用相同长度内容的值代替。

  c) 尽量最小化对于含有UPDATE触发器的表的UPDATE操作。

  d) 避免UPDATE将要复制到其他数据库的列。

  e) 避免UPDATE建有很多索引的列。

  f) 避免UPDATE在WHERE子句条件中的列。

  上面我们提到的是一些基本的提高查询速度的注意事项,但是在更多的情况下,往往需要反复试验比较不同的语句以得到最佳方案。最好的方法当然是测试,看实现相同功能的SQL语句哪个执行时间最少,但是数据库中如果数据量很少,是比较不出来的,这时可以用查看执行计划,即:把实现相同功能的多条SQL语句考到查询分析器,按CTRL+L看查所利用的索引,表扫描次数(这两个对性能影响最大),总体上看询成本百分比即可。

  简单的存储过程可以用向导自动生成:在企业管理器工具栏点击运行向导图标,点击”数据库”、”创建存储过程向导”。复杂存储过程的调试:在查询分析器左边的对象浏览器(没有?按F8)选择要调试的存储过程,点右键,点调试,输入参数执行,出现一个浮动工具条,上面有单步执行,断点设置等。

转载于:https://www.cnblogs.com/ymyglhb/archive/2009/05/14/1456927.html

SQLServer安全及性能优化 修补漏洞 安装程序补丁修补漏洞 随时关注微软官方网站补丁升级 关闭不必要的端口 关闭联必要的服务 数据库引擎 SQL Server Analysis Services SQL Server Reporting Services SQL Server Integration Services SQL Server 代理 SQL Full-text Filter Daemon launcher SQL Server Browser 同时开启所有服务系统性能会变得很差,根据需要手动启动或者禁用某个服务 DTC: Distributed Transaction Coordinator(分布式事务处理协调器),用于协调多个数据库、消息队列、文件系统等等资源管理器的事务,由于内部开发中并不使用这个功能,远程数据库服务器上也并不经常使用,因此建议关闭这个服务 禁用不使用的协议 Shared Memory 默认为已启用状态,这个协议只能用于本地连接,不能用于远程连接,一般用于其它协议出问题的时候管理作诊断使用 TCP/IP 禁用不需要使用的协议,减少网络攻击对象 减少监听的网卡和IP地址 改变监听端口号 安全地设置账户 Windows身份验证[微软推荐的方式] 优势: 1.访问SqlServer时速度更快,不用输入用户名和密码 2.可以利用Windows系统的自身工具和安全策略管理账户 3.安全确认和口令加密、审核、口令失效、最小口令长度和账号锁定 SqlServer身份验证 1.将sa账户名更改为其它账户名比如nocial,防止黑客利用sa进行攻击 2.删除不使用的账户 3.对已有账户设置安全密码[强制密码规则] 4.限制登录->远程登录、匿名登录 5.限制用户角色和权限,一般将权限设置到最低。设置角色的时候不要为public角色授予任何权限,并且从sysadmin这个角色中删除windows的administrators组,提高系统安全性。 删除不必要的数据库对象 删除危险的存储过程 xp_cmdshell:执行操作系统命令,这是一个系统后门[可以移动文件位置、创建用户、提升用户权限],建议不需要则删除掉。 ole自动化存储过程 任务管理存储过程 强化文件和目录安全 数据库最终以文件的形式存储在文件系统中 使用NTFS设置权限 限制共享【不能设置为完全控制】 及时审核日志 sqlserver的审核机制可以帮助跟踪并且阻止系统中没有授权的用户他的行为。比如没有授权的用户登录系统会阻止这次登录,并且把这次操作给记录下来。审核机制既能跟踪失败记录也能跟踪成功记录。所有的数据库平台均在不同程度上提供了审查功能。 跟踪用户行为 保护数据库 数据库性能优化 数据库性能优化主要有两个方面:减少查询比较次数、减少资源的征用。 使用工具Sql Server Profiler优化数据库性能,减少资源的征用 SqlServer Profiler的功能 Sql Server Profiler的用法  定义跟踪  登录连接、失败和断开  Select、Insert、Update和Delete语句  SQL批处理的开始或结束  写入到Sql server错误日志的错误  安全权限检查  Profiler执行的事件 让Profiler监视我们感兴趣的事件,可以监视的事件太多,监视太多会大大降低性能和增大表数据,只监视与数据库性能密切相关的哪些事件。常见的感兴趣的事件:  执行查询的性能  单个用户或应用程序的活动  逻辑磁盘的读写  语句级别上的CPU占用  Standart模板的事件类 优化数据库性能可以从五个层次来进行:  优先级一:减少数据的访问【减少磁盘访问】  优先级二:返回更少数据【减少网络传输或磁盘访问】  优先级三:减少交互次数【减少网络传输或磁盘访问】  优先级四:减少开销【减少CPU及内存开销】  优先级五:利用更多资源【增加资源】 技术上从四个方面来解决性能优化问题 1、调整数据库结构设计 2、调整应用程序结构设计 3、调整数据库SQL语句 4、调整服务器内存分配 如果不熟悉sqlserver可以使用数据库引擎优化顾问来对数据库提出优化建议,然后通过系统管理的修改达到目的。 数据库引擎优化顾问  数据库引擎优化顾问介绍  分析一个或多个数据库的工作负荷和物理实现,工作负荷可以是优化的sql语句或者sqlserver profiler的跟踪文件和数据表。我们可以在运行引擎优化顾问前运用sqlserver profiler记录一些事件,然后将跟踪结果存储为文件或者数据表,然后把这些提供给数据库引擎优化顾问,让它去分析。  提出合理的物理设计结构,物理设计结构包括数据库中的索引、索引视图、非聚集索引、聚集索引视图等等。对工作负荷进行分析后,数据库优化顾问会建议添加删除修改数据库的物理设计结构。推荐一组合理的物理结构以降低工作负荷的开销。从而提高数据库性能 数据库性能优化的常见问题 如何发现问题,如何分析导致性能降低的原因仍然是数据库管理员要掌握的知识。 事务占用资源的时间过长,造成阻塞 许多用户同时访问数据库的时候会产生大量事务,许多用户同时竞争一个资源导致占用资源的时间过长,造成阻塞。从而降低了数据库执行效率。产生这样的现象的原因如下: 1、多表连接查询,查询期间占用多个表 2、事务需要占用太多资源,容易出现多个事务占用对方资源的状况。从而导致死锁 解决之道: 1、避免多表连接查询,联合过多的表会在查询中占用过多的资源。很容易因为别的事务占用资源而相互等待。 2、使用统一的SQL语句规范,特别是访问表的顺序要保持一致,这样可以避免互相占用资源而导致的死锁。 不合理的数据文件设置,影响事务处理的性能 当事务处理产生大量数据的时候,数据文件的大小如果设置不合理将导致数据文件的不断扩展,这也会影响到事务处理的性能,进而影响到整个数据库性能。 1、频繁操作数据库,导致日志文件增长的过快,因为日志文件记录数据库的原始操作。所以它的增长速度比数据文件要快得多。当日志文件的增长大小设置不合理的时候会导致频繁地扩展文件。从而影响性能 2、查询操作比较频繁,系统数据Tempdb的大小设置不合理。 查询操作比较频繁的时候系统数据Tempdb增长得会比较快,因为查询所产生的临时数据都存放在这个数据库上。如果Tempdb过小当查询数据量较大的时候Tempdb会自动扩展,如果遇到频繁的查询会导致Tempdb不断扩展,从而影响系统性能。这种情况我尽可能地使查询的返回结果比较小 3、大量插入数据,导致数据文件增长过快。不要设置数据文件的自动收缩,它会在忙碌的系统上导致不必要的性能开销。所以如果没有特别需要不要设置数据库的自动收缩。最好采用手动收缩。 磁盘数据组织不合理,导致磁盘的访问次数过多 数据库的磁盘访问都是按照页来访问数据的,无论访问的数据再少都是以页为单位读取,1页为8K。所以如果将经常访问的数据放在一起,数据库读取尽量少的页面就能够完成读取操作。这样效率自然就提高了。也减少了磁盘头的来回移动。否则会多次读取硬盘页面导致访问的效率降低。 对于表A和表B、表C、表D,如果经常查询表A和表B中的数据,那么可以将他们放在同一个文件组M中;如果经常访问表C和表D中的数据可以将他们放在同一个文件组N中。这样读取效率就比较高,因为一次读取就可能包含了两个表中的数据,因此提高了查询效率。要解决“磁盘数据组织不合理,导致磁盘的访问次数过多”这个问题,我们可以将经常读写的数据放置在不同的磁盘上,也就是将经常在一起被多表连接查询的表放在同一个文件组上。这里强调:这里反复提到的“不同的磁盘”指的的是不同的磁盘,而不是同一个硬盘的不同分区。 批量导入数据的时候,要进行特殊设置 当用户需要大批量导入数据的时候会突然增加很多日志记录,并且如果数据表上有索引,数据表每增加一条记录就会在索引上增加一条数据从而降低插入的性能。解决方案: 1、大批量导入数据的时候设置数据库的恢复模式为“大容量日志恢复模式” 2、导入前禁用索引,导入完毕后重建索引。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值