不适用于 sql 注入保护。我知道这种好处，但就编译部分和效率更高的部分而言，我找不到可以提高效率的方案。我希望在这里。含糊我知道，但除了这里我不知道在哪里问。谢谢。
问问题
87 次
2 回答
0
场景很简单：事务处理。
正如 Edokan 所说，准备语句消除了编译 SQL 和创建执行计划的开销。在更复杂的查询中，这种开销是最小的。但是，如果您每秒运行 100 或 1000 个事务，那么这种开销可能会影响数据库的有效使用。
当然，查询计划可能不是最好的，尤其是当基础表的统计信息发生变化时。准备时的特征用于确定最佳查询计划。这些可能会随着时间而改变，不同的查询计划可能会变得更好。对于更复杂的查询，这更是一个问题。由于这些通常需要更长的时间才能运行，因此编译开销不是问题。
于 2012-08-16T18:35:57.850 回答
0
可以很容易地列出准备好的语句的好处
- 你摆脱了编译开销
- 您无需准备执行计划
- 由于没有声明，而只有参数需要通过线路传输，因此您获得了带宽。
如果您有一个语句要在很长一段时间内工作数百万次，那么所有这些项目对于效率都很重要。如果它很容易开发（如存储过程），这是一个双赢的局面，但是......
我曾经不得不使用“C with Embedded SQL”开发一个直接连接到 AS/400 系统的代码，您在 C 代码中编写 sql，将其提供给预处理器以输出可编译代码和活页夹文件，然后提供活页夹文件到 as/400 系统准备语句。都是因为他们拒绝安装 ODBC 支持他们的服务器。
编写和测试该代码很痛苦。它工作得非常缓慢，改变任何东西肯定会破坏系统。编写这样的代码效率不高。
效率取决于变量，这些变量取决于您的观点。
在我的示例中，AS/400 人员很高兴，因为他们通过不安装一些cr.p软件来保持系统高效。客户很高兴，因为他们强迫开发人员使用低效的方法编写代码的方法足够有效，可以及时处理。这对网络管理员来说很有效，因为只有很少的数据通过网络传输（甚至没有元数据）。这对开发人员来说效率非常低，因为它既费时又容易出错。但是对于同一开发人员来说，在简历上获得“看起来不错”的东西也是有效的。
现在你可以看到了？
于 2012-08-16T14:52:42.177 回答