它很容易地创建数据库代码减慢查询结果或捆绑不必要的数据库 - 除非你遵循这些提示
每个平台上的SQL开发人员都在挣扎，似乎陷入了DO WHILE循环，使他们一再重复同样的错误。这是因为数据库字段还相对不成熟。当然，供应商正在取得一些进展，但他们仍在努力解决更大的问题。并发性、资源管理、空间管理和速度仍然困扰着SQL开发人员，不管他们是在SQL Server、Oracle、DB2、Sybase、MySQL的，或任何其他关系平台。
问题的部分原因是，没有灵丹妙药，而对于几乎每一个最好的做法，我可以告诉你，至少有一个例外。通常情况下，开发者发现他或她自己喜欢的方式 - 尽管他们通常不包括性能或并发任何结构 - 并没有理会探索其他选项。也许这就是缺乏教育的症状，或开发商实在太靠近的过程时，他们正在做一些错误的认识。也许在查询运行以及在本地组测试数据，但在生产系统上悲惨的失败了。
(读肖恩·麦科恩的数据库地下博客。|保持最新在InfoWorld的数据管理issuws技术:数据管理时事通讯。|，并保持我们的软件发展趋势开发世界通讯。]
我并不期望SQL开发人员成为管理员，但是他们在编写代码时必须考虑生产问题。如果在最初的开发过程中没有这样做，dba就会让他们在以后再这样做——而在此期间，用户会受到伤害。
我们说调优数据库既是一门艺术也是一门科学，这是有原因的。这是因为几乎没有什么硬性规定能适用于所有行业。您在一个系统上解决的问题不是另一个系统上的问题，反之亦然。对于调优查询没有正确的答案，但这并不意味着您应该放弃。
有可以遵循的是应该产生在一个组合或另一个结果一些好的原则。我封装他们SQL该做什么和不该做什么，往往会被忽视或者是很难被发现的列表。这些技术应该给你一些更深入地了解您的数据库管理员的头脑，以及启动过程中的思维一家生产型的方式的能力。
1.不要使用UPDATE代替CASE的这个问题是很常见的，但它不是很难发现，很多开发者常常忽略它，因为使用UPDATE有似乎是合乎逻辑的自然流动。
就拿这种情况下，例如：你插入数据到一个临时表，需要它，如果另一个值存在，显示一定的价值。也许你从客户表中拉，你想用的人多被打成订单$ 100,000“首选”。因此，您将数据插入到表中并运行UPDATE语句来CustomerRank列设置为“首选”的人谁拥有的订单超过$ 100,000。问题是，UPDATE语句被记录，这意味着它必须为每一个写表写两次。解决这个问题的方法，当然，是在SQL查询本身使用内联CASE语句。之前它写入表此测试中的每一行的订单金额条件，并设置“首选”的标签。业绩增长可以是惊人的。
2.不要盲目地重用代码这个问题也很常见。复制别人的代码很容易，因为你知道这会提取你需要的数据。问题是，它常常会牵动你许多比您需要的数据更多，而开发人员很少费心去削减它，因此他们最终得到了一个巨大的超集数据。这通常以额外的外连接或WHERE子句中的额外条件的形式出现。如果按照自己的需要裁减重用的代码，可以获得巨大的性能收益。
3.是否只提取所需的列数这个问题与第2个问题类似，但它是特定于列的。使用SELECT *来编写所有查询，而不是单独列出列，这太容易了。问题是，它获取的数据比你需要的更多。这种错误我见过无数次了。开发人员对一个包含120列和数百万行的表执行SELECT *查询，但最终只使用其中的3到5个。此时，您处理的数据比您需要的要多得多，查询返回的数据简直是奇迹。您不仅要处理比需要更多的数据，而且还要从其他进程中获取资源。
4.不二次下面是另一个例子，我已经见过很多次了:编写一个存储过程从一个有数亿行的表中提取数据。开发商需要居住在加州、收入超过4万美元的客户。因此，他询问住在加州的客户，并将结果放入一个临时表中;然后，他查询收入超过4万美元的客户，并将这些结果放入另一个临时表中。最后，他将两个表连接起来得到最终产品。
你在跟我开玩笑吗？这应该在一个单一的查询进行;相反，你两面沾光一个超大型表。不要一个白痴：查询大表只有一次只要有可能 - 你会找到更好的你的程序有多少执行。
另一种稍有不同的情况是，一个进程中的几个步骤需要一个大表的子集，这导致每次都要查询这个大表。可以通过查询子集并将其持久化到其他地方，然后将后续步骤指向较小的数据集来避免这种情况。
5.知道什么时候使用临时表吗这个问题是一个有点难以得到一个句柄，但它可以产生可观的收益。您可以在许多情况下，如让你从两面沾光到大表使用临时表。您也可以使用它们来大幅降低加盟大表所需的处理能力。如果你必须加入一个表，一张大桌子，有一个条件上大表，你可以提高拉出数据，你从大表所需要的子集到一个临时表，而是与连接性能。这也是有帮助的（再次）如果你在程序几个查询有作出类似的连接到同一个表。
6.做好售前阶段的数据这是我最喜欢的话题之一，因为这是一个经常被忽视的老技巧。如果您有一个报告或一个过程(或者更好的是，一组这样的过程)将执行类似的对大型表的连接，那么通过提前连接这些表并将它们持久化到一个表中来预先准备数据可能会对您有好处。现在，报表可以针对这个预阶段表运行，从而避免大型联接。
您并不总是能够使用这种技术，但如果可以的话，您会发现它是节省服务器资源的极好方法。
请注意，许多开发商解决此获得通过集中查询自身并创建连接问题只能查看周围的加盟，使他们不必键入一次又一次的连接条件。但是，这种方法的问题是，查询仍然运行于每个需要它的报告。根据分期前的数据，运行加入只有一次（比方说，在报告前10分钟）和其他人避免了大的加盟。我不能告诉你我有多么爱这个技术;在大多数环境中，也有获得参加所有的时间流行表，因此没有理由为什么他们不能预先准备。
7.是否批量删除和更新这里还有一个简单的技术，该技术被忽视了很多。删除或更新大量从庞大的表中的数据可以是一个噩梦，如果你不这样做是正确的。问题是，这两个语句的运行作为一个单一的交易，如果你需要杀死他们或如果事情发生在这一系统，同时他们的工作，该系统具有回滚整个事务。这可能需要很长的时间。这些操作还可以阻止其他事务对它们的持续时间，基本上是瓶颈的系统。
解决方案是在较小的批次中进行删除或更新。这可以从两方面解决你的问题。首先，如果事务由于某种原因被终止，那么它只有少量的行需要回滚，因此数据库联机返回的速度要快得多。其次，当较小的批被提交到磁盘时，其他批可以潜入并执行一些工作，因此并发性得到了极大的增强。
按照这种思路，许多开发人员都认为这些删除和更新操作必须在同一天完成。但这并不总是正确的，尤其是在进行归档时。您可以将操作扩展到您需要的时间，而较小的批量有助于完成这一任务。如果你可以花更长的时间来做这些密集的手术，那就多花些时间，不要让你的系统崩溃。
享受快SQL在编写查询或过程以提高SQL性能时，请尽可能遵循这些应该做和不应该做的事情，但是请记住，要单独评估每种情况，看看哪种方法最有效——没有铁板钉钉的解决方案。您还会发现，许多这些技巧将提高并发性，并通常使事情运行得更顺利。请注意，虽然这些技巧的物理实现会随着供应商的不同而变化，但它们解决的概念和问题在每个SQL平台中都存在。
Jennifer McCown对本文有贡献。
本文， ”7个更快的SQL查询的性能提示”最初发表于InfoWorld.com。读肖恩·麦科恩的数据库地下博客及跟进最新的发展数据管理在InfoWorld.com上。
阅读更多关于数据管理的内容在InfoWorld的数据管理频道。
本文“更快的SQL查询的7个性能提示”最初由InfoWorld的 。