为什么要避免在存储过程中使用Dynamic SQL？

我听说有人说您不想使用动态SQL。您能举一个具体的例子还是真实的例子？我个人在数据库中编写了几次代码。我认为可以，因为它具有灵活性。我的猜测是关于SQL注入或性能的。还要别的吗？

如果必须的话，使用动态SQL没错。实际上，在某些情况下，这是您唯一的选择。最好不要使用它，因为如果没有对输入进行清理，它会导致SQL注入，是的，是的，在经常调用的模块中使用动态SQL可能会损害其性能。

我不认为有一个具体的例子，但是我会这样说：首先使用常规查询和语句后，尝试实现自己的目的-只有在用尽所有其他途径后，才可以动态地做到这一点。只需记住，执行动态SQL字符串是在与调用它的模块不同的用户会话中完成的-因此，您可能会遇到不需要的权限问题。

如果您担心性能；测试一下。如果您担心安全性；验证您的输入。没有对与错-只有您根据当时可用的信息和工具做出最佳判断。

动态SQL是一种工具。作为一种工具，它具有一些应用程序-例如，对于管理工作，这是一种祝福。

在应用程序使用的SP上效果不佳，尤其是在您不管理所生成代码的参数化的情况下（最新版本的SQL Server减少了问题，但仍然有效）。

我不会在此处详细介绍，因此我将推荐一篇有关动态SQL问题的出色文章：MVP Erland Sommarskog 撰写的有关动态SQL 的诅咒和祝福。

就像大多数dbms功能一样，如果在正确的情况下使用它，则效果很好，而在错误的情况下，它的效果不佳。

优点：有些事情没有它就无法完成。通常，我只发现这是为了管理工作，而不是应用程序代码。某些系统命令不允许将参数用作输入。因此，例如，如果我需要在每个数据库上通过一个存储库对某些数据库运行某些实例，并且该命令不接受参数，那么我通常通过动态SQL解决此问题。然而，这在Sybase ASE中比MSSQL更重要。

缺点：因为我想我们都已经知道了，所以我不会做太多介绍，但是如果使用不正确，SQL注入可能会存在一些风险。对我来说，更大的问题是查询将被视为是唯一的临时查询，而不是已编译查询计划的一部分。对于偶尔运行的东西，没什么大不了的。对于每分钟执行数百次并且将具有很多唯一sql的事物，它将生成许多新的，可能不必要的查询计划，从而耗尽整个周期，并缩短计划缓存的有效时间。

不要使用动态SQL。

由于缺乏有关如何在存储过程中使用可选参数的知识，因此有99％的时间使用Dynamic SQL ，其余1％的时间用于为客户不了解的报表创建高度复杂的查询甚至。动态SQL的诅咒和祝福没有显示使用它的好主意的示例，而只是表明它有问题，因为它增加了调试，维护和维护的复杂性，更不用说SQL的安全风险了。注入，性能不佳不是因为缓存，而是因为它带来的不良做法，例如使用临时表和游标，这当然是懒惰和幼稚的程序员会滥用的。这样的查询就没有灵活性，SQL是一种声明性语言，应该这样处理。

懒惰是万恶之源。

矛盾的是，这个答案将排在最被低估的答案中。