A知道很多使用预处理语句的人，仅用于占位符绑定。也就是说，他们不打算用不同的值多次发出相同的语句。他们只是觉得以这种方式使用PS更安全。
我对MySQL的PS的理解是，SQL是作为单个传输发送的，然后是一个或多个传输来发送值。因此，使用PS进行单个查询的效率低于使用普通查询的效率，这可以通过单次传输完成。
PS提供的安全优势是否会影响效率损失？我不这么认为，因为我认为在将值添加到SQL之前正确地转义值并不困难。
你有什么想法？
答案 0 :(得分：8)
编译预准备语句并将其存储在DBMS中。这些语句可以被缓存和重用。
想象一下多次点击同一页面时的好处。
此外，某些数据库引擎（例如Oracle）可能会施加严格的声明限制并信任我（我从经验中知道），您不想用尽它。
答案 1 :(得分：6)
Do the security benefits PS offer out weigh the loss in efficiency?
我认为是的，他们可能会这样做。即使使用准备好的陈述真的非常低效，但是，收集一些证明低效率会对您的运营造成某种显着障碍的数据是不是应该谨慎？如果它效率较低但你的网络服务器仍然可以处理它，它是否太重要了？你必须先说明差异是什么，然后才能说出它有多重要。
实际上，你正在权衡安全性，而不是对可能有效的东西这个相当模糊的想法。这可能是错误的做法。
修改：回复第一条评论：
当然，这个论点可以反过来说，你可以争辩说，某些评估应该是多少比查询构建更安全的预备语句，如果有的话。但这比量化脚本效率的问题更难以量化。
我建议每个人在这方面的目标是找到一个解决方案，他们可以合理地保护他们免受攻击;当然，如果您虔诚地使用预备语句，或者您在需要时认真地转义查询变量，那么您已经这样做了。 IMO应该考虑的是：系统是如何避免SQL攻击的？它为错误发生了多大的范围，因为在创建有问题的代码时未能发现错误？
如果每次进行数据库查询时，都必须认真记住查看将要使用的每个变量并为此目的转义它，这会导致冗长的代码，很可能会忽略某个变量或其他变量。切割和粘合弦本质上也有些不整齐。如果你有一定程度的抽象需要你识别每个查询变量及其类型，并且如果你不这样做会导致查询失败，那么无论是否通过使用预准备语句提示，你是已经以更系统的方式做事，这有助于你避免在其他地方绕过你的小心保护的疏忽。
答案 2 :(得分：1)
我认为这不应该是效率问题。我怀疑你是否会衡量一个有意义的差异，特别是与数据库调用的网络延迟和其余代码引入的低效率相比时。
单独防止SQL注入的好处值得单独承认。
我认为这是Donald Knuth警告的微观优化的一个例子。
但不要推测或依赖你在这里得到的意见。做一名科学家并获得一些数据。如果数据支持您的情况，请务必去寻找它。