我的公司有一支才华横溢，精明的运营人员，他们非常努力。我想给他们一个SQL执行工具，以帮助他们避免在急忙时容易犯的常见的，易于检测的SQL错误。谁能建议这样的工具？详细信息如下。

运营团队的一部分职责是编写非常复杂的临时SQL查询。毫不奇怪，操作员有时会因为忙而在其所写的查询中犯错。

幸运的是，它们的查询都是不改变数据的SQL的SELECT，而且无论如何它们都在数据库的副本上运行。尽管如此，我们还是要防止它们运行的​​SQL中的错误。例如，有时错误会导致长时间运行的查询，从而减慢他们正在使用的重复系统的速度，并给其他人带来不便，直到我们找到罪魁祸首并杀死它。更糟糕的是，有时错误会导致表面上正确的答案，直到很久以后我们才意识到，随之而来的是尴尬。

我们的开发人员还会在编写的复杂代码中犯错误，但是他们拥有Eclipse和各种插件(例如FindBugs)，它们会在键入时捕获错误。我想给操作员理想的东西

SELECT U.NAME, C.NAME FROM USER U, COMPANY C WHERE U.NAME = 'ibell';

在执行之前，它会说"嘿，我们知道这是笛卡尔积吗？确定要这样做吗？"发现明显缺少联接条件并且类似的明显错误也可以，这不是很聪明。

看起来TOAD应该执行此操作，但是我似乎找不到任何有关此功能的信息。还有像TOAD这样的其他工具可以提供这种半智能错误纠正吗？

更新：我忘了提到我们正在使用MySQL。

解决方案

回答

我们可能会发现redgate的SQL提示很有用。我不确定我们使用的是哪种数据库引擎，因为它仅适用于MSSQL Server

回答

我不希望这样的事情存在。该工具必须首先实现数据库中SQL解析器实现的所有内容，然后必须进行数据模型分析以预测"不良"查询。

最好的选择是为文本编辑器编写一个插件，该插件对可疑模式进行一些基本检查，并与标准.sql模式不同地突出显示它们。但是，即使那样也将是相当困难的。

每当我输入不带where子句的update语句时，我都会对触发警报的工具感到满意。可能还施加了轻微的电击，因为通常在漫长的一天之后的早晨大约在凌晨1点，这样的错误才会发生。

回答

通过使用非常少量的伪数据来建立示例数据库来构建它非常容易，该伪数据库将首先接收查询。将会发生几件事：

• 我们可能会收到一个SQL语法错误，由于它是一个小型数据库，因此不会加载太多数据库。
• 我们可能会得到一个响应，该响应可以清楚地显示为包含一个或者多个表中的每一行，这可能不是他们想要的。
• 通过上述条件的事情可能还可以，因此我们可以在生产数据库的副本上运行它们。

假设架构变化不大并且不是特别怪异，那么编写以上内容可能是解决问题的最快方法。

回答

如果人员正在使用mysql(1)程序运行查询，则可以使用safe-updates选项(又名i-am-a-dummy)来满足需求。它的名字有点误导。它不仅可以在没有WHERE的情况下防止UPDATE和DELETE(我们不必担心)，而且还可以在SELECT语句中添加隐含的LIMIT 1000，并中止具有联接并且估计要考虑超过1,000,000个元组的SELECT，这很可取笛卡尔加入。

回答

..."编写非常复杂的临时SQL查询。...它们太忙了"

危险威尔·鲁滨逊！

自动化自动化。

理想情况下，不应将操作团队置于必须在高压力情况下即时写查询的位置，这是灾难的根源！对于他们来说，最好建立一个经过适当测试的预写脚本库，以确保a)满足要求b)提供审核线索c)可能具有撤消类型功能。

失败的话，给他们一个只具有SELECT权限的用户ID可能会有所帮助:-)

回答

我将从一些编码标准入手，例如在示例中永远不要使用联接类型，这通常会导致不好的结果(尤其是在SQL Server中，如果我们尝试以这种方式进行外部联接，则会得到不好的结果)。要求他们进行显式联接。

如果我们有复杂的关系，则可以考虑将它们放在视图中，然后从视图中编写临时查询。然后，至少他们永远不会犯错，导致联接错误。

回答

我们不能只限制查询可以运行的时间吗？我不确定MySQL，但是对于SQL Server，即使是默认查询分析器也可以限制查询超时之前要运行的时间。将它们与有限的权限结合在一起，这样它们就只能运行SELECT查询，并且我们应该会受到很大的介绍。