单独为占位符绑定使用预准备语句是不是有点过分了？

Question

A知道很多人使用预准备语句，仅用于占位符绑定。也就是说，它们不打算使用不同的值多次发出相同的语句。他们只是觉得以这种方式使用PS更安全。

我对MySQL的PS的理解是，SQL是作为单次传输发送的，然后再发送一个或多个传输值。因此，使用PS进行单个查询的效率低于使用普通查询的效率，后者是在单个传输中完成的。

PS提供的安全优势是否超过了效率方面的损失？我不这么认为，因为我认为在将值添加到SQL之前，正确转义值并不难。

你的想法是什么？

Answer 1

准备好的语句被编译并存储在DBMS上。这些语句可以被缓存和重用。

想象一下多次点击同一页会有什么好处。

此外，一些数据库引擎(例如Oracle)可能会施加硬语句限制，并相信我(我从经验中知道)，您不会想要耗尽这一点的。

Answer 2

Do the security benefits PS offer out weigh the loss in efficiency?

我想是的，他们可能是这样做的。然而，即使使用预准备语句确实非常低效，收集一些数据来证明这种低效加起来会对您的操作造成某种显著的障碍，这不是很谨慎吗？如果效率较低，但您的web服务器仍然可以很好地处理它，这有什么关系吗？你必须先量化差异，然后才能说出它有多重要。

实际上，您正在权衡安全性与效率的模糊概念。这可能是错误的做法。

编辑：回复第一条评论：

当然，争论也可以反过来，您可以争辩说，如果有的话，应该对预准备语句比查询构建安全多少进行某种评估。但是，与您对脚本效率的担忧相比，这不太适合量化。

我建议，每个人在这方面的目标都是达成一种解决方案，他们可以合理地自信地保护自己免受攻击；当然，如果您认真地使用预准备语句，或者在需要的时候认真地避开查询变量，那么您就已经做到了。IMO，你真正应该考虑的是:我避免SQL漏洞的方法有多系统化？它为错误的发生提供了多大的空间，为你在创建有问题的代码时未能发现提供了多少空间？

如果每次执行数据库查询时，您都必须认真地记住要使用的每个变量并对其进行转义，这将导致冗长的代码，并且很可能会忽略某个变量。从本质上讲，剪切和粘合绳子也有些凌乱。如果您有某种程度的抽象，需要您标识每个查询变量及其类型，并且如果您不这样做就会导致查询失败，那么无论这是不是由使用预准备语句引起的，那么您已经在以更系统的方式进行操作，这有助于您避免在其他地方忽略您的谨慎保护的疏忽。

Answer 3

我认为这不应该是效率的问题。我怀疑您是否会衡量有意义的差异，特别是与数据库调用的网络延迟和其他代码引入的低效相比时。

仅仅是防范SQL注入的好处本身就值得付出准入的代价。

我认为这是Donald Knuth警告要注意的微优化的一个例子。

但不要投机，也不要依赖你在这里得到的观点。做一名科学家，获取一些数据。如果数据支持你的情况，那么一定要去做。