除非您遵循本文介绍的这些技术，否则很容易编写降低查询速度或锁定数据库的数据库代码。

因为数据库领域还比较不成熟，每个平台上的SQL开发人员都在一次又一次的纠结于犯同样的错误。

当然，数据库厂商也在取得一些进展，继续在尽力处理重大问题。

无论是SQL开发人员在SQL Server、Oracle、DB2、Sybase、MySQL还是任何其他关系数据库平台上编写代码，并发性、资源管理、空间管理、运行速度等问题仍然困扰着他们。

一方面，没有灵丹妙药；对于几乎所有的更佳实践，我至少可以举出一个例外。

通常开发人员会找到自己喜欢的方法，却懒得去研究其他方法。这可能是缺乏教育的表现，也可能是开发者在做错事的时候没有意识到。也许对于一组本地测试数据，查询运行得很顺利，但是如果将其更改为生产级系统，性能就不令人满意了。

我不指望SQL开发人员是管理员，但他们在编写代码时必须考虑生产环境。如果他们在开发前期不这样做，数据库管理员会让他们后期返工，用户会吃亏。

我们说调优数据库既是一门艺术，也是一门科学，这是有道理的，因为很少有完全适用的硬性规则。你在一个系统上解决的问题在另一个系统上不是问题，反之亦然。

谈到调优查询，没有正确答案，但这并不意味着我们应该放弃。你可以遵循以下17个原则，期望得到好的结果。

不要用更新替换案例

这个问题比较常见，但是很难发现。许多开发人员经常忽略这个问题，因为使用UPDATE似乎是合乎逻辑的。

以这个场景为例：你在一个临时表中插入数据，如果存在另一个值，你需要它来显示某个值。

也许您从客户表中提取记录，并希望将订单金额超过10万美元的客户标记为“”。

因此，您可以将数据插入表中，运行UPDATE语句，并将客户链接列设置为订单金额超过100，000美元的任何客户的“”。

问题是UPDATE语句被记录，这意味着每次写入表时，都会写入两次。

解决方案：在SQL查询中使用内联CASE语句，验证每行的订单金额条件，并在写入表中之前设置“Preferred”标记，处理性能大大提高。

不要盲目重用代码

这个问题也很常见。我们可以很容易地复制别人写的代码，因为你知道它可以得到所需的数据。

问题是它经常会得到太多你不需要的数据，开发者也很少精简，所以最后会有很多数据。

这通常表现为WHERE子句中的额外连接或额外条件。如果您根据您的确切需求简化重用代码，您可以大大提高性能。

如果需要几列，请选择几列

这个问题和第二个问题类似，但是是专栏独有的。用SELECT*编写所有的查询代码很容易，而不是一列一列地列出。

问题是它提取了太多你不需要的数据。这个错误我见过无数次。开发人员对一个有120列和数百万行的表执行SELECT*查询，但最终只使用了三列或五列。

因此，您处理的数据比实际需要的多得多，查询返回结果是一个奇迹。你不仅处理了太多不必要的数据，还拿走了其他进程的资源。

不要查询两次(双底)

这是我见过很多人犯的另一个错误：写存储过程，从一个有上亿行的表中提取数据。

开发商希望提取居住在加州、年收入超过4万美元的客户的信息。于是，他询问住在加州的客户，并将询问结果放在一个临时表格中。

然后，查询年收入超过4万美元的客户，并将这些结果放在另一个临时表中。最后，他连接两个表以获得最终结果。

开什么玩笑？这应该通过一个查询来完成。相反，您需要查询一个过大的表两次。别傻了：试着只查询大表一次，你会发现存储过程执行得快多了。

一个稍微不同的场景是，当某个过程的几个步骤需要大表的一个子集时，每次都会导致对大表的查询。

为了避免这个问题，只需查询这个子集，将其持久存储在其他地方，然后将以下步骤指向这个较小的数据集。

知道何时使用临时表

解决这个问题有点麻烦，但是效果显著。在许多情况下可以使用临时表，例如防止大型表被查询两次。也可以使用临时表，这大大降低了连接大型表所需的处理能力。

如果你要把一个表连接到一个大表，而这个大表有条件，就设置这个大表