设计高效SQL: 一种视觉的方法

行; 这听起来很直观，但最有效的方法是什么？你可能有如下选择：行，其中有50行你必须剔除行，其中有450行你必须剔除行中剔除50行听起来比从500行中剔除450行更高效，但是请记住：聚簇，或者说，数据的物理组织或分布，是关系重大的。页（译者注：“页”可理解为ORACLE的“块”）的数据，每页包含10行，你要的50行在其中的5页上；而另一个索引找出了5页，每页包含100行。访问10个页并剔除50行，或者访问5个页剔除450行，哪个方法好？访问更少数据页的方法可能更好。中的查询：所示的图像。一般要两三次尝试才能画出一幅清晰、整洁的图像，这不足为奇，特别是当你对别人的SQL进行反向工程的时候。我的第一幅草图总是会把所有的表挤在画面的一角。

行）还是行数稍微增加（选项4），诸如此类。但是，如果你把这些选项当作灵活而不是死板的教条，并且总是提前思考几个步骤，即使你错了也差不远。中所示的草图。

图2: 表被访问的顺序一旦我们决定这是查询的正确路径，我们就可以着手实施，可能是简单方便的重新排列一下表在查询中的顺序并且加上“强制顺序”的提示。(译者注：相当于ORACLE中的ORDERED提示，这仅仅在发现优化器生成的计划不够理想时使用)另一方面，如果这个查询至关重要，而且我们早在系统设计阶段就得以介入，那么我们可能需要考虑一下架构上的特点。选择索引我们可能会在customers表上建一个聚簇索引，但如果它是一个简单的堆表带一个非聚簇的主键索引(id)，我们可以考虑把地点(location)列加入到索引中，所以我们不必再访问表来检查地点。这种安排，即一个小小的主键索引带附加列，比起在表的id列上建一个聚簇索引会给我们带来更多的缓存上的好处。(译者注：聚簇索引(clustered index)是SQL SERVER和SYBASE的概念，相当于ORACLE中的索引组织表(index organized table)和索引聚簇表(index clustered table), 带附加列(included column)的主键在oracle中不支持，ORACLE中必须另外建立一个 (id,location) 上的索引)或者，如果我们在orders表的(id_customer, date_placed)上建立一个索引，我们可以考虑从customers表开始我们的查询，因为这个新索引使得我们能够利用customers表中选择出来的客户非常精确地访问orders表：虽然这个索引可能比较大，对于这个查询而言几乎没有缓存上的好处。因此也许(date_placed, id_customer)会更好。理所当然的，这又把我们带回了聚簇这个话题。在orders表上有两个候选的聚簇索引：下单日期(date_placed)和客户id(id_customer)。如果要用的话，哪一个好？或者（悄悄说）我们应该只是建一个简单的堆表？当然，这个基础设计问题应该在系统设计阶段就很明确地提出来，并且取决于我们期望按照什么来访问表：根据客户，根据日期，或者两者的组合(如本例所示)。既然数据是按照日期顺序产生的，它自己很自然地就按日期来聚簇，哪怕我们只是用了一个简单的堆表，所以按下单日期(date_placed)的聚簇索引不会带来明显的好处。另一方面，假如我们在客户id建立一个聚簇索引，数据插入将会变得昂贵得多，并且，除非我们经常查询一个客户的完整历史，当我们运行基于单个客户的查询的时候，一个(id_customer, date_placed)上的非聚簇索引已经能给我们足够好的性能。最后要说的是，在一个生产系统上修改索引肯定会有风险，为了解决SQL的性能问题，我们希望通过对代码的处理，对统计信息的调整，或者使用提示来强制更优的执行计划。画图使得你更好地看清楚和理解可供选择的手段，也使得你在作一些困难决定时更加心里有底。结论为了写出高效的查询，你必须知道你需要获取多少数据，数据又在哪里。你还必须知道你有哪些手段可以获取这些数据，为了访问你不需要的数据必须浪费多少代价，这样你才能决定访问表的顺序。对于复杂的查询，最好的办法是从画图开始，包括所有相关的表，画出表间的连接，指出相关的数据量，描述出能让你从一张表到达另一张表的所有索引。这样的一张图会使你更易于理解你的查询所有可能的访问路径的效率。