提高SQL查询性能的7个法宝

数据库，简而言之可视为电子化的文件柜——存储电子文件的处所，用户可以对文件中的数据进行新增、截取、更新、删除等操作。所谓“数据库”是以一定方式储存在一起、能与多个用户共享、具有尽可能小的冗余度、与应用程序彼此独立的数据集合。

每个数据库平台上的SQL开发人员都是在困难中求得生存，我们总是一次又一次犯同样的错误，这是因为数据库领域还相对不成熟，是的，每个数据库厂商都在做着各种不同的努力，但作为开发人员仍然要克服各种问题，无论是在SQL Server，Oracle，DB2，Sybase，MySQL数据库，还是其它关系数据库平台上编写SQL代码，并发性、资源管理、空间管理和SQL运行速度总是困扰着开发人员。
 

遗憾的是，其中部分问题的解决没有灵丹妙药，也几乎没有最佳实践。通常，开发人员有自己喜欢的SQL书写习惯，一般不愿意去研究其它可行方案，当然这可能是因为缺少培训的原因。我见得最多的就是在测试环境中SQL查询运行良好，但尚未在生产系统上进行试运行，就草草收场了，至于后来发现有问题，再被动式修改，因此最终用户就痛苦了。
 

我不期望开发人员成为DBA，但我们编写代码时必须考虑生产时的问题，如果不在开发初期这么做，DBA发现后只能迫使我们返工。
 

我们通常说数据库调试是一门技术，更是一门艺术，这是因为很少有现成的规则可以适应一切问题的解决，你在一个系统上解决的问题在另一个系统上可能就不是问题了，反之亦然。涉及到查询调整时，没有一个答案是完全正确的，但这并不意味着你应该放弃。
 

适当遵循一些原则可以让工作变得更加轻松，本文就列举7个可以灵活运用的原则，它们可以帮助你提高SQL查询速度，当然这些技巧你可以咨询DBA获得更多的信息。
 

1、用case代替update

要更新一条记录，我们立即会想到update，这个问题非常常见，许多开发人员经常忽视这个原则，因为使用update看起来非常自然，非常合乎逻辑。
 

假设你从Customer表中提取记录，你想将超过10万美元的订单标记为“Preferred”，因此你会想到使用一条update语句将CustomerRank列更新为“Preferred”，问题是update语句是有日志的，这就意味着每条记录它会写两次，解决这个问题的办法就是在SQL查询中内嵌case语句，在向表写入“Preferred”标志前，它会用订单金额条件对每一行进行检查，满足条件的才会更新，性能的提升是惊人的。
 

2、不要盲目地重用代码

这个问题也非常常见，在工作中直接用别人写好的代码是一件痛快的事情，你知道这些代码可以查询出你需要的数据，但问题是往往有些数据不是你需要的，但我们常常不愿意做一下修改，因此返回的数据集往往是一个超集，很可能多用一个外连接或是一个where子句就可以解决问题，因此在复用代码时最好检查一下，如有必要略做适应性修改。
 

3、只提取你需要的列

这个问题和2有点类似，但这次是指定具体的列。也许我们在使用select * 时感觉很畅快，多省事呀!如果要将每个列名都写出来，太麻烦了，这是很多人的想法，但这种想法是错误的，因为这样做会取出多余的数据列，我无数次看到犯这种错误的代码，曾经有一位开发人员对一张有120列，上百万行数据的表使用select * 查询，但他只会用到其中的三五列，这是对资源的极大浪费，我们建议拒绝书写select * ，你要什么就查询什么，多余的返回结果对你没用，虽然不影响你要实现的功能，但对数据库性能却有极大的影响。
 

4、尽可能只查询一次大表

这也是我看到很多人犯的错误，例如，某存储过程从一张上百万条记录的大表中取数据，开发人员想提取居住在加利福利亚且收入高于4万美元的客户信息，因此它先将居住在加利福利亚的客户取出放在一张临时表中，然后再查询收入高于4万美元的客户，将查询结果放入另一张临时表中，最后，他连接这两张临时表查询出最终的结果。
 

可能有人认为我是在开玩笑吧?但事实是确实有人这么做，这应该在一个查询中就能完成，却查询了两次大表。
 

有种稍微不同的情况是，当一个过程中的多个步骤需要大表的子集时，每一步可能都必须查询一次大表。避免多次查询的办法是持久化第一次查询的子集，然后将后面的步骤指向该持久化子集。

全新的路由器不仅让你更稳定快速地连接无线网络，更可以让家中的智能设备连接在一起。