加速SQL查询效率的7大秘诀

任何平台的SQL开发者都有自身的困惑，似乎他们一直纠缠在DO WHILE循环里，这个循环让他们不断地重复同样的错误。这是因为数据库的发展依然不够成熟。当然，供应商们也在不断进步，但是他们还是需要处理更严重的问题。并发性，资源管理，空间管理和速度依然制约着SQL开发者对开发平台的选择。

部分问题是因为没有诀窍可以实现解决这些问题，也没有任何实践表明已经解决了这些问题。但是，至少我可以告诉你这里有一个例外。通常，开发者会找到自己喜欢的方法，尽管这些方法无法实现性能架构和并发性，但是开发者也不会再自找麻烦地去寻找别的方式了。或许这是缺少教育的后果，或许是因为开发者太接近这些进程了，所以就没办法认清他们产生的错误。可能在本地测试系统上这些查询代码可以运行良好，但是在运行系统上就会产生极大的错误。

我并不期望SQL开发者能成为管理员，但是在写代码的时候，他们必须重视生产问题。如果在开发初期他们就不做这些工作，那么，DBAs将强制他们回过头来考虑这个问题，以此同时，使户也会受到影响。

我们之所以说调整数据库是一件艺术性和科学性结合的事情，是因为在应用上来看有很多必须遵守的规则。你在一个系统里解决的问题，在另一个系统里依然会出现，反之亦然。在调整数据库方面没有万能的答案，但是你依然不能放弃。

下面我将总结出在SQL编程中容易被忽略的一些注意要点，哪些是可以做的，哪些是不可以做的。这些要点将帮你更加深入地理解DBAs，也可以增强你从面向生产的角度思考进程。

1.不要用UPDATE代替CASE

尽管这个问题经常被忽略，但是却是一个很普遍的问题。很多开发者都会忽略这个问题，因为使用UPDATE看起来是一个具有逻辑性的自然流。

在这种情况下，例如：你插入一个临时表格，在存在另一个值的时候，让它显示某个值。你要从客户表中按顺序列出超过10万美金的人，以便把他们设置为“首选”。这时，你就要把数据插入表格中，运行UPDATEA命令来设置CustomerRank列，来顺序定义那些超过10万美金的人。问题是，UPDATE命令已经被记录了，这就意味着针对每一个表写入你都要进行两次操作。当然，针对这个过程可以使用SQL查询语言本身的CASE语句。它将测试每一行是否符合总体条件，并在写入表格前，给它一个“首选”的标签。这种性能的提高是惊人的。

2.不要盲目使用代码

这个也是很普遍的。这很容易复制别人的代码，因为你知道它这段代码可以查询到你需要的资料。问题是，很多时候复制别人的代码会让你得到很多你不需要的额外资料。但是很少有开发者有功夫去挑选这些数据。所以他们也只是通过这些代码得到了需要数据的父集。这样的代码通常是以外部链接的方式或者是在WHERE语句中出现。所以说如果你有针对性地修改代码，SQL的性能就会得到大大的提升。

3.只查询对你游泳的列

这个问题和第二个问题类似，但是，是针对列来讲的。用SELECT * 查询，而不是分别对每列查询在代码实现方面也简单地多。但是这时，问题再一次出现，你再次得到了比你需要的数据多得多的数据。我已经无数次地看到这种现象发生了。开发者用SELECT * 语句查询一个120列、几百万行的表以后最后只得到了3到5行的有用数据。在这一点上，你不是仅仅查询了比你所需要的数据多的数据，你还从别的进程中抢夺了资源，降低了整体速度。

4.不要做两次查询

还有一个常见的现象是：写一个从拥有无数行的表里取数据的存储进程。开发者需要查询到符合这样以下条件的用户：住在加利福尼亚州，收入超过$40,000。这时，他把住在加利福尼亚州的客户查出来放到一张零时表中，然后把收入在$40，000以上的客户查出来放到另一张零时表中。最后，他合并这两个表得到最终的查询结果。然后，通过更小的数据集，来加强后续步骤。

你在开玩笑吧？这个查询应该是一个单一的查询，可是，你却对一个如此大型的表进行了两次查询。不要再做这样的傻事了：对大型表格说，尽可能地只进行一次查询。这时，你会发现你的程序执行起来效率更高了。

稍微不同的地方是，当我们需要通过几个步骤查询一个大型表的子集时，它将导致对大型表的多次查询。一定要通过查询子集避免这种事情的发生。

未经允许不得转载：DOIT » 加速SQL查询效率的7大秘诀