sql语句的sql服务器优化

1，SQL Server 2005的性能工具包括SQL Server分析器和数据库引擎优化顾问，优秀的东方，必须熟练使用。

2。在查询SQL语句时打开显示估计的执行计划，并分析每一步的情况

3，基本方法，当CPU占用率很高时，打开SQL Server分析器运行，将运行的数据存储到文件中，然后打开数据库引擎优化顾问调用该文件进行分析，并通过SQL Server提供索引优化建议，采用索引索引优化部分。

4，但上述做法往往不会超出你的需要。在最近的优化过程中，CPU占用率很高，但它不能提高我所需要的优化建议，特别是一些语句存储在多个表的过程中，此时需要使用中间的方法来定位CPU的高语句。

5，或运行SQLServer探查器，将运行结果保存到一个新的库表（一个名字系统将由您自己构建），让它运行一段时间，然后就可以使用它了。
选择前100的测试，以期文本数据是无效的
这可以选择一个运行时间长的语句，可以用CPU替换，然后读取以选择CPU占用很长时间并读取太多数据的语句。
在找到问题的陈述之后，可以详细分析它，一些语句清楚地看到执行计划中的问题。
是否有任何指标或指标建设不合理，将有表扫描或指数扫描。如果您看到扫描，您将意味着全部或全部索引扫描，这是很多次的必然结果，我们希望看到的是查找或键查找。

6、如何查看SQL语句的执行计划是很特别的，初学者会过于注重显示里面的开销比例，而实际上这有时误导。在实际的优化过程中，我发现一个索引扫描执行成本仅为25%，而另一个关键的搜索成本是50%，而关键的部分不是在所有搜索优化。寻求谓词ID = xxx基于主键查找。仔细分析后，可以看出，后者的CPU开销是0.00015，和我/ O成本0.0013.in前，CPU开销1.4xxxx，和我/ O开销远远大于后者。因此，优化的重点应放在前。

7，如何优化一个单一的部分，一个复杂的SQL语句，SQL Server将巧妙地重构语句后面的位置，试图匹配索引。选择优化步骤，选择它旁边的属性并选择谓词，并复制这些部分。这部分是分解的WHERE语句。然后，在查询接口中，从刚刚复制谓词的表中选择*，这是需要优化的部分。现在我们已经进入了这个阶段，大多数人应该能够手动设置索引，因为这里的语句比以前简单得多了。（在我的项目中，原始SELECT语句的一部分有10个条件组合，涉及6个字段。4部分的4部分涉及到3个方面，新指标建立后，CPU的占用率立即降低，与新建立的索引相关的字段是更新的一部分，并非总是如此。频繁的读写操作不会影响更新的效率。

8，以上是优化的想法。最后，提出了系统设计中需要注意的一些优化过程或需要注意的问题。
一、尽量避免使用SELECT * FROM XXX，ABC是xxx'type模糊查询，因为在它前面的是无法使用索引，将不可避免地导致全量扫描操作。在像查找应该寻找替代的方法或使用条件语句减少到最低限度的行数。
B，尽量避免随机记录的操作选择上n×XXX，XXXX为NEWID（）大表数据。NEWID（）操作将读取的全量数据再整理一遍，也占用了大量的CPU和读取操作成为可能。考虑使用rand（）函数，而我还在学习中，对整个表的操作，如身份> =（选择最大值（ID）从表）* rand（）。然而，有必要考虑本地数据的随机记录。
C、在SQL Server Profiler纪录，会发现审计注销占用大量如CPU的读写操作。有些信息被称为SQL语句连接期间由链接产生的总数量，没有太多的担心，这似乎是真实的，很多审计注销的CPU和IO消耗基本上与先前优化语句相同。所以在第五点，我提到的SQL语句是隐藏的文本数据不为空的条件。
D，两个不同的域或语句导致全表扫描。例如，m = 1，n = 1.if索引的建立是m和n，这也将导致扫描，和解决方案是指数m和n分别测试12万个数据表，索引的建立误差，IO开销为10.xxx高，在指标的建立，都变成了0.003，对比度是非常巨大的。虽然插入操作的性能问题引起的，大多数的瓶颈是在选择阅读操作毕竟。
E（索引），查找和索引扫描的索引（索引扫描），我们需要的是前者，后者的原因通常是多余的一个字段索引查找，例如A和B指数在两个领域，只要我们找到了，它将导致索引扫描。建议索引是建立一个单独的一个形成一个索引查找。
对于小表，不推荐索引，尤其是数百个数据，只有一千个成千上万的数据级别被索引。

数据库优化是一门很深的学问，在设计数据库时要注意，特别是最后提到的A、B两点，尽量避免在前期设计中。