如何提高SQL Server数据库的性能 该从哪里入手呢?笔者认为 该遵循从外到内的顺序 来改善数据库的运行性能 如下图
第一层 网络环境
到企业碰到数据库反映速度比较慢时 首先想到的是是否是网络环境所造成的 而不是一开始就想着如何去提高数据库的性能 这是很多数据库管理员的一个误区 因为当网络环境比较恶劣时 你就算再怎么去改善数据库性能 也是枉然
如以前有个客户 向笔者反映数据库响应时间比较长 让笔者给他们一个提高数据库性能的解决方案 那时 笔者感到很奇怪 因为据笔者所知 这家客户数据库的记录量并不是很大 而且 他们配置的数据库服务器硬件很不错 笔者为此还特意跑到他们企业去查看问题的原因 一看原来是网络环境所造成的 这家企业的客户机有 多台 而且都是利用集线器进行连接 这就导致企业内部网络广播泛滥 网络拥塞 而且由于没有部署企业级的杀毒软件 网络内部客户机存在病毒 掠夺了一定的带宽 不仅数据库系统响应速度比较慢 而且其他应用软件 如邮箱系统 速度也不理想
在这种情况下 即使再花十倍 百倍力气去提升SQL Server数据库的性能 也是竹篮子打水一场空 因为现在数据册竖库服务器的性能瓶颈根本不在于数据库本身 而在于企业的网络环境 若网络环境没有得到有效改善 则SQL Server数据库性能是提高不上去的
为此 笔者建议这家企业 想跟他们的网络管理员谈谈 看看如何改善企业的网络环境 减少广播包和网络冲突;并且有效清除局域网内的病毒 木马等等 三个月后 我再去回访这家客户的时候 他们反映数据库性能有了很大的提高 而且其他应用软件 性能也有所改善
所以 当企业遇到数据库性能突然降低的时候 第一个反应就是查看网络环境 看看其实否有恶化 只有如此 才可以少走冤枉路
第二层 服务器配置
这里指的服务器配置 主要是讲数据库服务器的硬件配置以及周边配套 虽然说 提高数据库的硬件配置 需要企业付出一定的代价 但是 这往往是一个比较简便的方法 比起优化SQL语句来说 其要简单的多
如企业可以通过增加硬盘的数量来改善数据库的性能 在实际工作中 硬盘输入输出瓶颈经常被数据库管理员所忽视 其实 到并发访问比较多的时候 硬盘输入输出往往是数据库性能的一个主要瓶颈之一 此时 若数据库管理员可以增加几个硬盘 通过磁盘阵列来分散磁盘的压力 无疑是提高数据库性能的一个捷径
如增加服务器的内存或者CPU 当数据库管理员发现数据库性能的不理想是由内存或者CPU所造成的 此时 任何的改善数据库服务器本身的措施都将一物用处 所以 有些数据库管理专家 把改善服务器配置当作败姿乱数据库性能调整的一个先决条件
如解决部署在同一个数据库服务器上的资源争用问题 虽然我们多次强调 要为数据库专门部署一个服务器 但是 不少企业为了降低信息化的成本 往往把数据库服务器跟应用服务器放在同一个服务器中 这就会导致不同服务器之间的资源争用问题 如把文件服务器跟数据服务器部署在同一个服务器中 当对文件服务器进行备份时 数据库性能就会有明显的下降 所以 在数据库性能发现周期性的变化时 就要考虑是否因为服务器上不同应用对资源的争夺所造成的
故 笔者建察档议 改善数据库性能时第二个需要考虑的层面 就是要看看能否通过改善服务器的配置来实现
第三层 数据库服务器
当通过改善网络环境或者提高服务器配置 都无法达到改善数据库性能的目的时 接下去就需要考察数据库服务器本身了 首先 就需要考虑数据库服务器的配置
一方面 要考虑数据库服务器的连接模式 SQL Server数据库提供了很多的数据库模式 不同的数据库连接模式对应不同的应用 若数据库管理员能够熟悉企业自身的应用 并且选择合适的连接模式 这往往能够达到改善数据库性能的目的
其次 合理配置数据库服务器的相关作业 如出于安全的需要 数据库管理员往往需要对数据库进行备份 那么 备份的作业放在什么时候合适呢?当然 放在夜晚 夜深人静的时候 对数据库进行备份最好 另外 对于大型数据库 每天都进行完全备份将会是一件相当累人的事情 虽然累得不是我们 可是数据库服务器也会吃不消 差异备份跟完全备份结合将是改善数据库性能的一个不错的策略
第四层 数据库对象
若以上三个层面后 数据库性能还不能够得到大幅度改善的话 则就需要考虑是否能够调整数据库对象来完成我们的目的 虽然调整数据库对象往往可以提到不错的效果 但是 往往会对数据库产生比较大的影响 所以 笔者一般不建议用户一开始就通过调整数据库对象来达到改善数据库性能的目的
数据库对象有表 视图 索引 关键字等等 我们也可以通过对这些对象进行调整以实现改善数据库性能的目标
如在视图设计时 尽量把其显示的内容缩小 宁可多增加视图 如出货明细表 销售人员可能希望看到产品编号 产品中英文描述 产品名字 出货日期 客户编号 客户名字等等 但是 对于财务来说 可能就不需要这么全的信息 他们只需要产品编号 客户编号 出货日期等等少量的信息即可 所以 能可浪费一点代码的空间 设计两张视图 对应不同部门的需求 如此 财务部门在查询数据时 不会为不必要的数据浪费宝贵的资源
如可以通过合理设置索引来提高数据库的性能 索引对于提高数据的查询效率 有着非常好的效果 对一些需要重复查询的数据 或者数据修改不怎么多的表设置索引 无疑是一个不错的选择
另外 要慎用存储过程 虽然说存储过程可以帮助大家实现很多需求 但是 在万不得已的情况下 不要使用存储过程 而利用前台的应用程序来实现需求 这主要是因为在通常情况下 前台应用程序的执行效率往往比后台数据库存储过程要高的多
第五层 SQL 语句
若以上各个层面你都努力过 但是还不满足由此带来的效果的话 则还有最后一招 通过对SQL语句进行优化 也可以达到改善数据库性能的目的
虽然说SQL Server服务器自身就带有一个SQL语句优化器 他会对用户的SQL语句进行调整 优化 以达到一个比较好的执行效果 但是 据笔者的了解 这个最多只能够优化一些粗略的层面 或者说 %的优化仍然需要数据库管理员的配合 要数据库管理员跟SQL优化器进行配合 才能够起到非常明显的作用
不过 SQL语句的调整对于普通数据库管理员来说 可能有一定的难度 除非受过专业的训练 一般很难对SQL语句进行优化 还好笔者受过这方面的专业训练 对这方面有比较深的认识 如在SQL语句中避免使用直接量 任何一个包含有直接量的SQL语句都不太可能被再次使用 我们数据库管理员要学会利用主机变量来代替直接量 不然 这些不可再用的查询语句将使得程序缓存被不可再用的SQL语句填满 这都是平时工作中的一些小习惯
lishixin/Article/program/SQLServer/201311/22452
⑵ 如何提高sql语句的执行效率
1、使用ordered提示
Oracle必须花费大量的时间来剖析多表的合并，用以确定表合并的最佳顺序。SQL表达式涉及七个乃至更多的表合并，那么有时就会需要超过30分钟的时间来剖析，Ordered这个提示(hint)和其他的提示一起使用能够产生合适的合并顺序。
2、使用ordered_predicates
ordered_predicates提示在查询的WHERE子句里指定的，并被用来指定布尔判断(Booleanpredicate)被评估的顺序。在没有ordered_predicates的情况下，Oracle会使用下面这些步骤来评估SQL判断的顺序：子查询的评估先于外层WHERE子句里的Boolean条件。
所有没有内置函数或者子查询的布尔条件都按照其在WHERE子句里相反的顺序进行评估，即最后一条判断最先被评估。每个判断都带有内置函数的布尔判断都依据其预计的评估值按递增排列。
3、限制表格合并评估的数量
提高SQL剖析性能的最后一种方法是强制取代Oracle的一个参数，这个参数控制着在评估一个查询的时候，基于消耗的优化器所评估的可能合并数量。
(2)sql怎么提高提点扩展阅读：
1、表设计的优化，数据行的长度不要超过8020字节，如果超过这个长度的话在物理页中这条数据会占用两行从而造成存储碎片，降低查询效率。
2、语句的查询优化，保证在实现功能的基础上，尽量减少对数据库的访问次数；
3、建立高效的索引创建索引一般有以下两个目的：维护被索引列的唯一性和提供快速访问表中数据的策略。
大型数据库有两种索引即簇索引和非簇索引，一个没有簇索引的表是按堆结构存储数据，所有的数据均添加在表的尾部，而建立了簇索引的表，其数据在物理上会按照簇索引键的顺序存储。个表只允许有一个簇索引。
4、强制查询转换，有时候oracle 的优化器未必能走正确的查询路线，这个时候就需要添加一些hint 之类的来规定他的执行路线。当然了，这个未必是最好的处理方案。因为虽然现在走这个路线是对的，以为因为数据的变化到这这个HINT 变得不可取。
⑶ 如何提高sql数据库的查询速度
一、程序中：
1、保证在实现功能的基础上，尽量减少对数据库的访问次数。
2、通过搜索参数，尽量减少对表的访问行数,最小化结果集，从而减轻网络负担，能够分开的操作尽量分袭蔽开处理，提高每次的响应速度。
3、在数据窗口使用SQL时，尽量把使用的索引放在选择的首列，算法的结构尽量简单。
二、避免使用不兼容的数据类型。
例如“float”、“int”、“char”等，都属于不兼容。 数据类型的不兼容可能使优化器无法执行一些本来可以进行的优化操型态作。
三、尽量避免在Where子句中对字段进行函数或表达式卜禅源操作，这将导致引擎放弃使用索引而进行全表扫描。
四、尽量使用数字型字段。
一部分开发人员和数据库管理人员喜欢把包含数值信息的字段设计为字符型，这会降低查询和连接的性能，并会增加存储开销。