有针对性地优化一些特定的资源消耗严重的应用当出现性能问题时，首先应该做什么？这个问题问过很多同事，有人说根据经验，优化有问题的SQL。我们通常说的，要合理使用索引，尽量不要使用前面带*的Like语句，不要在比较运算符前面进行计算。或者使用函数等，这些路径都可以，但经验有时并不一定能解决问题。当出现问题时，首先要做的是确定问题是什么。只有正确发现问题，才能有针对性地解决问题。下面简单介绍一下我们一般从哪些角度入手判断问题。1、首先从业务角度了解场所的功能，了解用户的真实意图，用户真正关心的是什么，想要什么数据，是否有灵活简洁的方法满足用户的要求。而不是使用复杂的sql查询。其实有时候灵活修改也可以达到目的，只是使用的SQL语句已经大大简化了。这是解决性能问题的优先事项。2、在优化一个固定的sql时，一定要注意与查询相关的数据量和数据的大小。有时用户在进行查询时，如果查询条件处理不当，返回的记录集过大，对用户是不利的。其实意义不大。关键是这样势必会导致更多的磁盘IO，性能问题在所难免。除非用户真的需要那么多数据，但事实证明大部分都不需要，所以重点是如何限制返回记录集的大小或者查询中使用的临时中间数据集的大小。只有这样，你的优化才能达到效果，才能发挥作用。下面简单介绍几种常用的检查问题SQL的方法。当然还有一些技巧，比如：使用setstatisticsioon查看实际的磁盘IO信息，物理读，逻辑读等信息。这是一份简单有效的参考资料。在笔者以往的经验中，也是主要的参考资料。.在查询分析器中贴出问题sql，使用setstatisticsiotoon，或者在空白处右击，选择，选择勾选SetStatisticsio。运行查询，除了得到结果集，还可以得到本次查询相关的IO信息，如下图所示：我们一般关注的是逻辑读次数。当多张表联合查询时，这里会显示每张表的IO信息。当某个表的逻辑读数非常多时，就需要重点关注和分析这张表。是不是查询涉及到这个表的记录太多，Index是不是没有用好？是否可以？添加其他过滤条件以减少相关记录集等。下面简单说明一下：输出项的名称含义Table表。扫描计数执行的索引或表扫描的次数。逻辑读取数从数据高速缓存中读取的页数。physicalreads从磁盘读取的页数。预读读取放入高速缓存以供查询的页数。loblogicalreads从数据缓存中读取的text、ntext、image或大值类型（varchar(max)、nvarchar(max)、varbinary(max)）页数。lobphysicalreads从磁盘读取的text、ntext、image或大值类型页数。lobread-aheadreads为查询缓存的text、ntext、image或大值类型页面的数量。这里先介绍磁盘IO相关信息，另外一个参考数据是使用setstatisticstimeonreference来显示分析、编译和执行语句所需的毫秒数。具体使用方法与setstatisticsioon基本相同，只是显示本次查询使用的分析、编译、执行的时间信息。如果你聪明，你一定一眼就明白了。我不会在这里重复它们。setstatisticsprofileon是指显示当前语句执行的配置文件信息，执行步骤等信息，使用方法同上。查询执行后，除了显示执行的结果集外，还会以记录树的形式显示SQL语句执行相关的配置信息，对应执行计划中的每一步，如索引某步使用的type，Evaluaterowcount，IO信息，时序信息等，这些信息可以作为参考，判断SQL语句的问题出在哪里。参考当前语句的估计执行计划或实际执行计划，分析SQLServer查询优化器在执行当前语句时选择的数据检索方式。实际执行计划显示的是本次执行所使用的执行计划。图片应该从右到左，从下到上看。如果是多表连接查询，这里也会显示多个执行步骤。可以查看每个步骤相关的操作信息，比如IO开销，CPU开销等，预估行数，是否使用Index，使用何种Index。如果线路过多，则需要注意。使用的Indexl类型也是需要注意的信息之一。这里简单介绍一下执行计划中的一些概念：Tooltip项解释PhysicalOperation使用的物理操作符，例如HashJoin或NestedLoops。以红色显示的物理运算符表示查询优化器已发出警告，例如缺少列统计信息或缺少连接谓词。这会导致查询优化器选择一个效率低于预期的查询计划。有关列统计信息的更多信息，请参阅使用统计信息提高查询性能。当图形执行计划建议创建统计信息、更新统计信息或创建索引时，使用SQLServerManagementStudio对象资源管理器中的快捷菜单立即创建或更新缺失的列统计信息和索引。有关详细信息，请参阅索引操作方法主题。逻辑运算符与物理运算符相匹配的逻辑运算符，例如InnerJoin运算符。逻辑运算符列在物理运算符之后，并且都位于工具提示的顶部。估计行大小运算符生成的行的估计大小（以字节为单位）。估计I/O成本用于执行操作的所有I/O活动的估计成本。该值应尽可能低。EstimatedCPUCost用于执行操作的所有CPU活动的估计成本。EstimatedOperatorCost用于执行此操作的查询优化器的成本。此操作的成本在括号中显示为查询总成本的百分比。该值应尽可能低，因为查询引擎会选择最有效的操作来执行查询或执行语句。EstimatedSubtreeCost查询优化器在同一子树中执行此操作和此操作之前的所有操作的总成本。估计行数运算符生成的行数。结合上面介绍的几种参考信息方法，大致可以判断出问题sql的问题所在，然后对症下药，剩下的就是针对性的修改了。这只是一个介绍。如果你聪明，你一定会想办法解决的。原文链接：http://www.cnblogs.com/JerryTian/archive/2012/07/03/2574068.html【编者推荐】提高MySQL数据库查询效率的技巧（三）如何获取记录行号在MySQLQueryResultSetExample中讲解如何配置MySQL数据库主从复制
