sql性能优化
SQL Server数据库性能调整与优化
摘要:数据库技术是计算机系统的核心技术，数据库的稳定性与否直接影响计算机的运行效果，SQL SERVER数据库具有广泛的应用平台，作为高度可优化的软件产品———SQL SERVER数据库，其性能的调整与优化对提高计算机运行效果具有重要的现实意义。
关键词:数据库性能调整与优化SQL SERVER数据库作为计算机系统的核心，基于SQL SERVER数据库性性能的调整与优化主要目的就是通过将网络流通、磁盘I/O和CPU时间减到最低，减少每个查询时间，以此提高数据库服务的吞吐量。
SQL SERVER 数据库性能调整与优化是提高计算机系统稳定性的重要技术支撑。
1SQL SERVER数据库的特点①具有高性能设计和先进的管理系统。
高性能设计就是说其可以利用windows NT为计算机提供优越的服务，并且通过先进的管理系统实现计算机功能的全面，比如可以为计算机使用者提供支持本地以及远程的管理与配置，同时也具有图形化管理功能。
②具有强大的处理功能和兼容性。
SQL SERVER数据库性具有事务处理功能，它可以根据具体的计算机系统要求正确的保持数据的完整，实现相关数据的安全，同时SQL SERVER数据库性可以兼容不同的计算机系统，能够根据不同的计算机系统为使用者提供一个稳定的数据库平台。
2SQL SERVER数据库性能调整与优化的方法无论什么原因导致计算机数据管理系统出现问题都会影响数据库的运行效率，因此要想提高SQL Server数据库性能发挥最大效率，应该不断调整与优化SQL Server数据库系统，实现SQL Server数据库系统各个功能的最大发挥。
2.1SQL SERVER数据库设计优化要想提高SQL SERVER数据库性能的稳定性，就必须首先提高数据库的设计，保证数据库设计方案的性能做大优化。
2.1.1数据库的事务设计。
数据库事务系统是由不同的SQL语句模块所构成的，事务处理是由计算机系统的应用程序实现的，因此事务处理的起止点也应该由应用系统完成，基于此程序，数据库事务设计，要遵循运行效率的最大化原则，要保证数据库短事务，实现事务中的SQL语句能够科学的占有与释放系统资源，避免在系统运行中占用过多的资源而导致系统运行速度的下降。
MySql（十）：MySQL性能调优——MySQLServer性能优化
MySql（⼗）：MySQL性能调优——MySQLServer性能优化本章主要通过针对MySQL Server（ mysqld）相关实现机制的分析，得到⼀些相应的优化建议。
主要涉及MySQL的安装以及相关参数设置的优化，但不包括mysqld之外的⽐如存储引擎相关的参数优化，存储引擎的相关参数设置建议将主要在下⼀章“ 常⽤存储引擎的优化” 中进⾏说明。
⼀、MySQL安装和优化1.选择合适的发⾏版本a.⼆进制发⾏版（包括RPM 等包装好的特定⼆进制版本）由于MySQL 开源的特性，不仅仅MySQL AB 提供了多个平台上⾯的多种⼆进制发⾏版本可以供⼤家选择，还有不少第三⽅公司（或者个⼈）也给我们提供了不少选择。
使⽤MySQL AB 提供的⼆进制发⾏版本我们可以得到哪些好处？a) 通过⾮常简单的安装⽅式快速完成MySQL 的部署；b) 安装版本是经过⽐较完善的功能和性能测试的编译版本；c) 所使⽤的编译参数更具通⽤性的，且⽐较稳定；d) 如果购买了MySQL 的服务，将能最⼤程度的得到MySQL 的技术⽀持；b.第三⽅提供的MySQL 发⾏版本⼤多是在MySQL AB 官⽅提供的源代码⽅⾯做了或多或少的针对性改动，然后再编译⽽成。
这些改动有些是在某些功能上⾯的改进，也有些是在某写操作的性能⽅⾯的改进。
还有些由各OS ⼚商所提供的发⾏版本，则可能是在有些代码⽅⾯针对⾃⼰的OS 做了⼀些相应的底层调⽤的调整，以使MySQL 与⾃⼰的OS 能够更完美的结合。
当然，也有⼀些第三⽅发⾏版本并没有动过MySQL ⼀⾏代码，仅仅只是在编译参数⽅⾯做了⼀些相关的调整，⽽让MySQL 在某些特定场景下表现更优秀。
这样⼀说，听起来好像第三⽅发⾏的MySQL ⼆进制版本要⽐MySQL AB 官⽅提供的⼆进制发⾏版有更⼤的吸引⼒，那么我们是否就应该选⽤第三⽅提供的⼆进制发⾏版呢？需要进⼀步分析⼀下第三⽅发⾏版本可能存在哪些问题?⾸先，由于第三⽅发⾏版本对MySQL 所做的改动，很多都是为了应对发⾏者⾃⼰所处的特定场景⽽做出来的。
基于SQL的数据库性能优化分析
基于 Ｓ Ｑ Ｌ的数据库性能优化分析
张 云 帆
（ 中 国石 油 辽 河 油 田公 司 信 息 管 理 部 ， 辽 宁 盘锦 １ ２ ４ ０ １ ０ ）
［ 摘 要］ 数 据 库性 能调 整 与 优 化 ， 对 于提 高数 据 库 的稳 定性 、 可 靠性 ， 保 障 业务 高效 运 行有 着重 要 意 义 。 本 文从 数 据 库 性 能
和风 险上 代 价 很 高 ， 而 对 数据 库 系 统 性 能 的 提 升 收 效 有 限 ： 另 一 方面． 应 用 程 序 对数 据 库 的操 作 ． 最终体现在 Ｓ Ｑ Ｌ语 句 对 数 据 库
的操 作 ． 因此 Ｓ Ｑ Ｌ语 句 的执 行 效 率 决 定 了数 据 库 的性 能 。由此 可 １ ． ２ ． １ 使用 Ｄ Ｅ Ｃ Ｏ Ｄ Ｅ 函数 来 减 少处 理 时 间 见． 应 用程 序 的优 化 应 着 重 于 Ｓ Ｑ Ｌ语 句 的优 化 在 数据 库 应 用 系 使用 Ｄ Ｅ Ｃ Ｏ Ｄ Ｅ 函数 可 以 避 免 重 复 扫描 相 同 记录 或 重 复 连 接 统中． 相 同 功 能 的程 序 可 以采 用 不 同 的 Ｓ Ｑ Ｌ语 句 编 写 实 现 ． 而 不 相 同 的表 ， 例如： 同的 Ｓ Ｑ Ｌ语 句 存 在 着 性 能 及 效 率 上 的差 异 ．这 种 差 异 在 大 型 数 Ｓ Ｅ Ｌ Ｅ ＣＴ Ｃ ＯＵＮＴ（ ） ， Ｓ ＵＭ（ Ｓ ＡＬ）Ｆ ＲＯＭ ＥＭＰ 据 库 环境 中表 现 得 尤 为 明显 。因 此 。 通过优化调整 Ｓ Ｑ Ｌ语 句 ， 从 Ｗ ＨＥＲＥ ＤＥ Ｉ ｒ ＿ Ｎ０ ＝０ ２ ０ ０ ＡＮＤ ＥＮ ＡＭＥ ＵＫＥ ‘ Ｓ Ｍｒ ｒ Ｈ％ ’ ； 而 显 著 改 善整 个 系统 的性 能 。 对 提 高 数 据 库 内存 区 的命 中 率 、 减 Ｓ Ｅ Ｌ Ｅ ＣＴ Ｃ ０ＵＮ Ｔ（ ） ． Ｓ ＵＭ（ Ｓ ＡＬ）Ｆ ＲＯＭ ＥＭＰ
优化SQL对ORACLE数据库性能的提高
3科技资讯科技资讯S I N &T NOLOGY I NFO RM TI ON 2008NO .28SC I EN CE &TECH NO LOG Y I N FOR M A TI O N 信息技术大多数情况下,系统运行缓慢不是由于所有部件都饱和引起的,而是由于系统中的某个部分限制了整体的性能,这部分称为瓶颈。
通常影响ORA CL E 数据库性能指标的三个瓶颈主要是:CP U 、内存、I /O 。
数据库性能的优化主要是or a c l e 数据库参数的调整、磁盘I /O 调整、应用程序S QL语句分析及设计、网络性能调整等。
本文主要通过优化S QL 语句来提高ORACL E 数据库的性能。
1SQ L 语句处理流程如图1所示。
1.1打开游标从上图可以看出处理S QL 语句的第一步就是要打开一个游标,事实上,一个完整的S QL 处理过程就是一个游标的生命周期。
1.2共享SQLOr a cl e 内存中有一个区叫SHA R ED _PO OL ,这个区的主要作用就是将S Q L 语句存放在这个区内,当客户发出一个新的S QL 语句,数据库引擎首先会到这个区查找是否有相同的S QL ,如果有,则避免了解析、分析索引、制定执行计划等一系列的动作。
如果没有则需要进行ha r d pa r s e 。
1.3绑定变量如果在S QL 中指定了绑定变量,需要在这个阶段给S QL 附上绑定变量的值。
1.4并行处理如果S Q L 需要进行并行处理,在这一阶段需要把整个S Q L 分割成多个并行的部分。
1.5执行查询Or a c l e 按照执行计划指定的方式执行SQL,执行UPDATE 和DE LE TE 语句时,必须将行锁定,以免其他用户修改。
Or a cl e 先从数据库缓冲区中寻找是否存在所要的数据块,如果存在,就直接读或修改,否则从物理文件中读到数据库缓冲区中。
1.6返回结果对S EL ECT 语句需要返回结果的语句,首先看是否需要排序,需要,则排序后返回给用户,然后根据内存的大小不同,可以一次取出一行数据,也可以一次取一组数据。
Oracle SQL性能优化
Ｓ Ｌ语 法 的性 能 至关 重要 。 Ｑ １ 选 择最 有 效率 的 表名 顺序 （ 只在 基 于规 则 的优 化 器 中有 效 ） Ｏ Ａ Ｌ 的解 析 器 按 照 从 右 到左 的顺 序 处 理 Ｆ Ｏ 子 句 中 的表 Ｒ ＣＥ Ｒ Ｍ 名 ，Ｆ Ｏ 子 句 中写 在最 后 的 表 （ 础 表 ｄｉｉｇｔ ｌ）将 被 最先 处 Ｒ Ｍ 基 ｒ ｎ ａ ｅ ｖ ｂ
所 引用 的 表 。 ２ ＷＨ Ｒ Ｅ Ｅ子句 中的连 接顺 序 Ｏ Ａ Ｌ Ｒ Ｃ Ｅ采 用 自下 而 上 的顺 序 解 析 ＷＨ Ｒ Ｅ Ｅ子 句 ，根 据 这个 原 理 ，表 之 间 的 连 接 必 须 写在 其 他 ＷＨ Ｒ 条 件 之前 ，那些 可 以 过 滤 ＥＥ 掉 最大 数 量记 录 的 条件 必须 写 在 ＷＨ Ｒ Ｅ Ｅ子句 的末 尾 。 ３Ｓ Ｉ Ｃ Ｅ Ｊ Ｔ子 句 中避 免使 用 ’ Ｅ ： ０ Ｃ正 在解 析 的过 程 中 ，会 将 ’依 次 转 换 成 所 有 的列 名 ， ＲＡ Ｉ 这 个工 作 是通 过 查 询数 据 字典完 成 的 。这 意 味着 将 耗费 更 多 的时 间
理 ，在 Ｆ Ｏ 子 句 中包 含 多 个 表 的情 况 下 ，你 必 须 选 择记 录 条数 最 ＲＭ 少 的表 作 为基 础 表 。 如 果有 ３个 以上 的表 连 接 查 询 ，那就 需 要 选 择 交 叉 表 （ｎｅｓｃｉ ａ ｌ） 作 为 基础 表 ，交 叉 表 是 指 那 个 被 其 他 表 ｉｔ ｅ ｔ ｎ ｔ ｅ ｒ ｏ ｂ
维普资讯
Ｏａｌ Ｓ Ｌ性能优化 ｒｃ Ｑ ｅ
陈 运庆 （ 中国石 油哈 尔滨石化 分 公 司信 息 中心 ， 黑龙 江 哈 尔滨 １ ｏ ｏ ） ５ ｏ ｏ
摘 要 ：提 出 几种优 化 Ｏ Ａ Ｌ Ｑ Ｒ Ｃ Ｅ Ｓ Ｌ语 句 的优化 方法 ， 来提 高 ｏ ｃ ｒｌ ａ ｅ数据 库 的 查询 速 度 。
Informix SQL性能跟踪优化
复杂 ， 数据量也飞快增长 。然而 ， 与之对应的应用 系 统吞吐量却很难提 高， 甚至逐步下 降。在实 际应用 系统 中， 经常会 出现系统 资源 的负载不 高 ，Ｐ 、 ＣＵ 内 存等使用率很低 ， 不到 ５ ％。 同时查看 ｉ ｏ ｉ ０ ｎ ｒ ｘ的 ｆｍ 检查 点 （ ｈ ｃ ｐ ｉｔ 的时 间也很 短 ， Ｃ ｅｋ ｏｎ） 一般 在 １ ｓ ～２ 之 内， 最大不超过 ５。而前台业务操作 却速度慢 ， ｓ 响
冲区 ， 锁和用户的情况 ， 见表 １ 。
表 １ 如 ： ｎ ｔｔ—ｕ ｍｏｅ ￥ｏ ｓａ Ｉ ｒ
这里 着 重 关 注 ｎｅｄ ｒａｓ和 ｎ ｆｅ 列 。这 两 列 表 ｗ ｔｓ ｉ
行分析。在实际 中， 由于同一个数据库 ｓ ｖ 上可 ｅｅ ｒｒ
能有很多的线程 ， 可以利用 Ｓ Ｅ Ｌ Ｈ Ｌ 对命令的输 出进 行简化。对 ｎｅｄ 值对进行排序 ， ｒａｓ 直接找到 Ｉ Ｏ最高 的线程。
２ ９ ｂ ｓ ２ ７ ７ ０ ７ ｏｃ ｐｇ ９ ３ ６ ４ ｂｓ １７４０ ５ ｃ ｐ ８７ ３ ３ ３ ３ ｅ ｐ ８４ ９ １ ８ ３ ２ ｂ ｓ ４ ９ ６ ２ ３ １
３ ２ ｃ ｐ ８４ ７ ５ ２ ７ ２ ｂ ｓ ４ ０ ７７ ５ ９
利用 ｏｓ ｔ—Ｕ命令输 出 的 ｓ ｓ （ ｎｔ ａ ｅ ｉ 会话标 识 ｓｄ 号） 。取道线程的 ｉ 号 ， 列 ｄ 然后可以利用 ｏｓ ｔ—ｇ ｎｔ ａ
示线 程 已执 行 的读 调 用 数 （ ｒ ｄ ） 写 调 用 数 ｎ ａｓ 和 ｅ （ ｗｉｓ 。如果 ｎｅｄ 值较大 ， 初步怀疑可能存 ｎ ｒｅ） ｔ ｒ ｓ ａ 就
在顺序扫描。然后需要进一步对这个数据库线程进
第 ｌ 期 ２
SQL数据库系统语句优化问题研究
SQL数据库系统语句优化问题研究[摘要]sql语句的优化是将性能低下的sql语句转换成目的相同的性能优异的sql语句。
人工智能自动sql优化就是使用人工智能技术，自动对sql语句进行重写，从而找到性能最好的等效sql语句。
[关键词]人工智能自动优化 sql语句优化中图分类号：tp311.138 文献标识码：a 文章编号：1009-914x （2013）10-0042-011、一个数据库系统的生命周期可以分成设计、开发和成品三个阶段。
在设计阶段进行数据库性能优化的成本最低，收益最大。
在成品阶段进行数据库性能优化的成本最高，收益最小。
数据库的优化通常可以通过对网络、硬件、操作系统、数据库参数和应用程序的优化来进行。
最常见的优化手段就是对硬件的升级。
根据统计，对网络、硬件、操作系统、数据库参数进行优化所获得的性能提升，全部加起来只占数据库系统性能提升的40%左右，其余的60%系统性能提升来自对应用程序的优化。
许多优化专家认为，对应用程序的优化可以得到80%的系统性能的提升。
应用程序的优化通常可分为两个方面：源代码和sql语句。
由于涉及到对程序逻辑的改变，源代码的优化在时间成本和风险上代价很高，而对数据库系统性能的提升收效有限。
1.1 为什么要优化sql语句优化sql语句的传统方法是通过手工重写来对sql语句进行优化。
dba或资深程序员通过对sql语句执行计划的分析，依靠经验，尝试重写sql语句，然后对结果和性能进行比较，以试图找到性能较佳的sql语句。
这种传统上的作法无法找出sql语句的所有可能写法，且依赖于人的经验，非常耗费时间。
1.2 sql优化技术的发展历程第一代sql优化工具是执行计划分析工具。
这类工具针对输入的sql语句，从数据库提取执行计划，并解释执行计划中关键字的含义。
第二代sql优化工具只能提供增加索引的建议，它通过对输入的sql语句的执行计划的分析，来产生是否要增加索引的建议。
第三代sql优化工具不仅分析输入sql语句的执行计划，还对输入的sql语句本身进行语法分析，经过分析产生写法上的改进建议。
浅谈Oracle数据库SQL性能优化
浅谈Oracle数据库SQL性能优化摘要：随着计算机信息网络技术的不断发展，数据库系统取得很大突破。
面临网络化时代的进步，人们对网络信息的需求的也变得逐渐走向多元化。
网络信息数据库存取技术逐渐被广泛运用，数据库系统规模也越来越大。
目前Oracle 就是被广泛应用的一种数据库，其信息存储量能满足人们日益增长的需求，但为了能够保证其能够流畅稳定安全地运行，应当对其进行一定的优化措施。
关键词：Oracle数据库；SQL优化随着数据库技术功能逐步增加，应用范围逐渐扩展，效果也是日渐明显。
随着网络信息吞吐量的逐步增加，数据库系统在对数据进行处理时算法变得十分繁琐。
数据库系统如果长时间的超负荷工作就会变得反应迟钝影响效率，甚至可能导致死锁。
由于天天都将会有大量的SQL语句访问Oracl数据库系统，系统需要很多时间来处理这些访问，而SQL语句直接影响到Oracl数据库系统性能，所以运用对SQL语句优化的方法来提升ORACLE数据库的性能显得十分必要。
1、对SQL进行优化的必要性数据库系统作为数据管理的主要组成部分主要作用是存储供相关人员查阅大量信息，实现网络资源共享。
查询操作在数据库系统的各种操作中居于首位，直接关系到数据库系统的运行状态。
假如数据查询操作量过大，会给系统带来很大的负担，系统反应速度变慢，严重者可能就会引起系统瘫痪。
因此，为了保证数据库系统的高效正常运行，必须对SQL语句进行优化[1]。
图1.1SQL语句优化2、SQL优化的目标往往由于SQL的结构设计的问题，很可能使得正常运行的一个数据库系统出现性能问题。
所以必须对SQL语句进行必要的调整，达到有效提升数据库系统性能的目的。
对SQL结构的优化本质就是简化繁琐的数据结构，常规方法一般就是对SQL语法进行一些调整，基本方法是把程序中繁琐的SQL语句结构简化，保持服务器的搜索数据能力处于最佳运行状态，有效降低程序中表扫描的时间，促使所以功能得以充分发挥，尽量使服务器的处理器时间和输入输出时间保持平衡。
大数据量数据库设计与优化方案（SQL优化）
⼤数据量数据库设计与优化⽅案（SQL优化）⼀、数据库结构的设计如果不能设计⼀个合理的数据库模型，不仅会增加客户端和服务器段程序的编程和维护的难度，⽽且将会影响系统实际运⾏的性能。
所以，在⼀个系统开始实施之前，完备的数据库模型的设计是必须的。
在⼀个系统分析、设计阶段，因为数据量较⼩，负荷较低。
我们往往只注意到功能的实现，⽽很难注意到性能的薄弱之处，等到系统投⼊实际运⾏⼀段时间后，才发现系统的性能在降低，这时再来考虑提⾼系统性能则要花费更多的⼈⼒物⼒，⽽整个系统也不可避免的形成了⼀个打补丁⼯程。
所以在考虑整个系统的流程的时候，我们必须要考虑，在⾼并发⼤数据量的访问情况下，我们的系统会不会出现极端的情况。
（例：对外统计系统在7⽉16⽇出现的数据异常的情况，并发⼤数据量的的访问造成，数据库的响应时间不能跟上数据刷新的速度造成。
具体情况是：在⽇期临界时（00：00：00），判断数据库中是否有当前⽇期的记录，没有则插⼊⼀条当前⽇期的记录。
在低并发访问的情况下，不会发⽣问题，但是当⽇期临界时的访问量相当⼤的时候，在做这⼀判断的时候，会出现多次条件成⽴，则数据库⾥会被插⼊多条当前⽇期的记录，从⽽造成数据错误），数据库的模型确定下来之后，我们有必要做⼀个系统内数据流向图，分析可能出现的瓶颈。
为了保证数据库的⼀致性和完整性，在逻辑设计的时候往往会设计过多的表间关联，尽可能的降低数据的冗余。
（例:⽤户表的地区，我们可以把地区另外存放到⼀个地区表中）如果数据冗余低，数据的完整性容易得到保证，提⾼了数据吞吐速度，保证了数据的完整性，清楚地表达数据元素之间的关系。
⽽对于多表之间的关联查询（尤其是⼤数据表）时，其性能将会降低，同时也提⾼了客户端程序的编程难度，因此，物理设计需折衷考虑，根据业务规则，确定对关联表的数据量⼤⼩、数据项的访问频度，对此类数据表频繁的关联查询应适当提⾼数据冗余设计但增加了表间连接查询的操作，也使得程序的变得复杂，为了提⾼系统的响应时间，合理的数据冗余也是必要的。
mssql占用cpu高的sql方法
一、介绍mssql占用CPU高的问题在使用Microsoft SQL Server（mssql）时，有时会遇到CPU占用率较高的情况。
这种情况会给数据库系统的性能和稳定性带来不利影响，需要及时解决。
本文将介绍mssql占用CPU高的情况，并提出相应的解决方法。
二、分析mssql占用CPU高的可能原因1. 查询语句性能不佳：一些复杂的查询语句可能会导致mssql的CPU 占用率飙升。
涉及多个表的join操作或者涉及大量数据的排序和聚合操作等都可能引起CPU占用率升高。
2. 索引缺失或失效：当数据库中的索引缺失或者失效时，查询语句的执行效率会大幅下降，从而导致CPU占用率飙升。
3. 数据库参数设置不当：一些mssql的参数设置不当可能会导致CPU 占用率升高，过高的并行度设置、过低的内存分配等。
4. 锁争夺：当多个查询语句同时对数据库中的数据进行修改操作时，可能会导致锁争夺，从而引起CPU占用率升高。
5. 其他因素：除了上述原因外，硬件故障、磁盘IO负载过高等因素也可能导致mssql的CPU占用率升高。
三、解决mssql占用CPU高的方法1. 优化查询语句：通过使用合适的索引、合理的查询语句等手段来优化查询性能，从而降低CPU占用率。
可以使用SQL Server Profiler 等工具对查询语句的执行计划进行分析，找出性能瓶颈所在。
2. 优化索引：对数据库中的索引进行优化，包括创建合适的索引、删除不必要的索引等，从而提高查询效率，降低CPU占用率。
3. 调整数据库参数：合理调整数据库的参数设置，包括并行度设置、内存分配等，以适应当前的数据库负载情况，从而降低CPU占用率。
4. 锁优化：通过优化事务隔离级别、减少锁的持有时间等手段来降低锁争夺情况，从而降低CPU占用率。
5. 硬件升级：如果硬件故障或者性能较差，可以考虑进行硬件升级，以提高服务器的整体性能，从而降低CPU占用率。
6. 监控和分析：定期对mssql的CPU占用率进行监控和分析，找出性能瓶颈所在，及时采取相应的优化措施。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
sql性能优化 数据库性能优化涉及到很多方面，在数据库开发时可以通过一些基本的优化技巧提高数据库的性能： 1．原则上为创建的每个表都建立一个主键,主键唯一标识某一行记录，用于强制表的实体完整性。SQL Server 2005 Database Engine 将通过为主键列创建唯一索引来强制数据的唯一性。查询中使用主键时，此索引还可用来对数据进行快速访问。（注意：如果你建立了主键，默认情况下它就是聚集索引）
2．为每一个外键列建立一个索引，如果确认它是唯一的，就建立唯一索引。当在查询中组合相关表中的数据时，经常在联接条件中使用外键列，索引使 SQL Server 2005 数据库引擎 可以在外键表中快速查找相关数据。
3．暂时不要为其他列建立索引 4．当在TSQL中引用对象时，建议使用对象的架构名称限定。（使用dbo.sysdatabases代替sysdatabases）未指定架构可 能会导致混淆和意义不明确，还有一个重要原因，当很多连接同时运行同一个存储过程时，如果未指定架构名称，这些连接可能会因为要获取编译锁 （compile lock）而互相阻塞。
5．使用SET NOCOUNT ON在每个存储过程的开头SET NOCOUNT OFF在结尾。当 SET NOCOUNT 为 ON 时，将不给客户端 发送存储过程中的每个语句的 DONE_IN_PROC 信息。当使用 Microsoft SQL Server 提供的实用工具执行查询时，在 Transact-SQL 语句（如 SELECT、INSERT、UPDATE 和 DELETE）结束时将不会在查询结果中显示"n rows affected"。如果存储过程中包含的一些语句并不返回许多实际的数据，则该设置由于大量减少了网络流量，因此可显著提高性能。
补充： 1.当 SET NOCOUNT 为 ON 时，也更新 @@ROWCOUNT 函数。 2. @@ROWCOUNT是返回受上一语句影响的行数，包括找到记录的数目、删除的行数、更新的记录数等，不要认为是返回查找的记录数目，而且@@ROWCOUNT要紧跟需要判断语句，否则@@ROWCOUNT将返回0。 3. 使用错误处理程序，用来检查 @@ERROR 系统函数的 T-SQL 语句 (IF) 实际上在进程中清除了 @@ERROR 值，无法再捕获除零之外的任何值,必须使用 SET 或 SELECT 立即捕获错误代码。 6．慎用锁，可以使用NOLOCK提示，它与READUNCOMMITTED是等价的。更简单的做法是在存储过程的开头SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED，结尾READ COMMITTED。 7．查询仅仅返回需要的行和列 8．在适当的时候使用事务，尽量将事务放在一个存储过程中。 9．尽量少的使用临时表，因为大量使用临时表可能使tempdb成为瓶颈。可以使用表表达式，包括派生表、CTE、视图和内联表值UDF。
补充：CTE是SQL Server 2005的一项强大而灵活的功能。它使得SQL Server的可读性更强，更易于管理，降低了查询的复杂程度。执行递归查询是CTE最重要也是最强大的功能。
10．避免使用NOT IN，可以用LEFT OUTER JOIN代替它 11．如果需要使用动态SQL，sp_executesql更具优势，因为它提供了输入输出接口，并且更有可能重用执行计划，因为你可以更容易的生成被重复调用的查询字符串。注意有一点声明的参数类型尽量和查询关键字字段类型一致，否则可能导致低的查询效率。
12．当修改你的代码时，比较前后代码执行的性能，如果发现在CPU、IO上有大的增长，需要检查代码的修改
13．尽量减少和服务器的交互，可以通过一次返回多结果集来解决。 14．一般情况下不需要使用INDEX和JOIN提示，因为优化器会选择最优的执行计划。如果统计信息没有更新会影响查询计划的选择。
15．在本地测试时，可以看一看语句在CPU，IO或执行时间上是否异常。通常利用命令：set statistics io on, set statistics time on , set showplan on 等。
16．如果用到其他库的Table或View，可以在当前库中建立View来实现跨库操作，最好不要直接使用 “databse.shema.table_name”，因为sp_depends（显示有关数据库对象依赖关系的信息）不能显示出该SP所使用的跨库 table或view，不方便校验。
1. --执行下面的存储过程显示数据库中依赖于表的数据库对象 2. EXEC sp_depends@objname=N'user';
17．尽量避免大事务操作，慎用holdlock子句，提高系统并发能力。 1. --会话 2. begin tran 3. --holdlock人为加共享锁 4. SELECT*from UserWITH(HOLDLOCK)whereUserID=1 5. waitfor delay'00:00:10' 6. commit tran 7. --会话 8. SELECT*from UserWITH(HOLDLOCK)whereUserID=1 9. update Usersetuserpw=222222whereUserID=1 10. --若同时执行上述两个语句，则第二个会话中的select查询可以执行 11. --而update必须等待第一个会话中的共享锁结束后才能执行，即要等待10秒
18．尽量避免反复访问同一张或几张表，尤其是数据量较大的表，可以考虑先根据条件提取数据到临时表中，然后再做连接。
19．尽量避免使用游标，游标的效率较差，因为游标基本上是强制优化器执行固定的计划，并且逐行操作产生大量的开销；如果使用了游标，就要尽量避免在游标循环中再进行表连接的操作。
20．不要在where子句中进行函数、算术运算或其他表达式运算，否则系统将可能无法正确使用索引。 1. --为了测试新建一个索引 2. dbcc dropc**buffers 3. CREATE NONCLUSTEREDINDEX[IX_User_AddDate]ON[User]([AddDate]ASC) 4. set statisticsioon 5. SELECT*from UserwhereDateDiff(d,useradddate,GETDATE())=1 6. set statisticsiooff 7. --(0行受影响) 8. --表'User'。扫描计数1，逻辑读取91216次，物理读取1次，预读91284次，lob逻辑读取0次，lob物理读取0次，lob预读0次。 9. set statisticsioon 10. SELECT*from Userwith(index=IX_User_AddDate)whereDateDiff(d,adddate,GETDATE())=1 11. set statisticsiooff 12. --(0行受影响) 13. --表'Worktable'。扫描计数0，逻辑读取0次，物理读取0次，预读0次，lob逻辑读取0次，lob物理读取0次，lob预读0次。 14. --表'User'。扫描计数5，逻辑读取3278次，物理读取0次，预读2750次，lob逻辑读取0次，lob物理读取0次，lob预读0次。 15. set statisticsioon 16. SELECT*from Userwhereadddate>=convert(varchar(10),GETDATE()-1,120) 17. set statisticsiooff 18. --(0行受影响) 19. --表'Worktable'。扫描计数0，逻辑读取0次，物理读取0次，预读0次，lob逻辑读取0次，lob物理读取0次，lob预读0次。 20. --表'User'。扫描计数1，逻辑读取3次，物理读取1次，预读0次，lob逻辑读取0次，lob物理读取0次，lob预读0次。
21． 尽量使用exists代替select count(*)来判断是否存在记录 优化器优化exists谓词时优化器支持短路（short-circuiting）功能。只要找到一行，不需要再扫描其他行就可以确定该表是否包含行了。 count函数只有在统计表中所有行数时使用， count(1)、count(?)、count(*)哪个效率高的问题，经过测试堆、利用聚集索引、非聚集索引三种情况下这三个的执行效率基本上一样，生成的查询计划是相同的。
22．注意insert、update操作的数据量，防止与其他应用冲突。如果数据量超过一定的数据页面，系统将会进行锁升级，页级锁会升级成表级锁。
23．关于涉及tempdb的使用方面 临时表和表变量被物理的保存在tempdb中，除此之外，SQL Server还为很多隐式操作在tempdb中存储数据。包括：作为查询执行计划的一部分的脱机数据，排序，以及维护行版本（2005）。所以tempdb可能会成为瓶颈。 1. 尽量少的使用distinct、order by、group by、having、join，因为这些语句会加重tempdb的负担。 2. 避免频繁创建和删除临时表，减少系统表资源的消耗。 3. 在新建临时表时，如果一次性插入数据量很大，那么可以使用select into代替create table，避免log，提高速度；如果数据量不大，为了缓和系统表的资源，建议先create table，然后insert。 4. 如果临时表的数据量较大，需要建立索引，那么应该将创建临时表和建立索引的过程放在单独一个子存储过程中，这样才能保证系统能够很好的使用到该临时表的索引。 5. 如果使用到了临时表，在存储过程的最后务必将所有的临时表显式删除，先truncate table，然后drop table，这样可以避免系统表的较长时间锁定。