转到准备好的语句与直接查询

Question

普遍的共识似乎是直接查询语句不允许参数，而准备好的语句允许。

但是在 Go 的 database/sql 包中，你可以使用 ODBC 参数并将参数发送到诸如 db.QueryRow() 和 db.Query() 之类的东西。所以看起来它们在功能上是等效的。

话虽如此，那么首先创建一个语句，然后执行它有什么意义呢？假设语句首先针对数据库进行编译——这会不会增加负载并因此降低性能，因为您要添加额外的行程？并且由于您可以从 Query/QueryRow 获取参数，这不会使语句成为一件坏事吗？

Answer 1

理论上，当数据库服务器收到一条简单的 SQL 语句（或批处理）时，它必须对其进行编译：将其解析为某种内部形式，然后准备所谓的“查询计划”——操作序列（例如索引或表）扫描、比较等）以执行实际请求。做这一切显然会消耗大量的服务器资源。如此多的 DBMS 开始支持“准备好的语句”：服务器只执行一次解析/规划步骤，并将“句柄”交给您随后多次“调用”的结果，只需提供不同的参数。现在让我们进入一个更复杂的领域。首先要注意的是，当内存和处理能力变得更便宜时，运行在商品到高端服务器上的 DBMS 能够在处理查询时花费更多资源，因此其中一些缓存用户查询。也就是说，当您执行简单查询（SQL 语句或批处理）时，服务器会执行所有通常的解析/查询计划，但随后会保存结果，如果稍后遇到相同的查询，则会跳过处理部分并仅执行对数据的操作。第二件要注意的事情是，虽然编程语言/库倾向于为程序员提供访问数据库引擎的某个通用接口（ODBCC是一个例子，database/sqlforGo是另一个例子，还有无数其他的例子）、有线协议或其他的手段实际访问的服务器可能会大大不同。例如，一个数据库服务器可能支持在其有线协议中与查询一起传递参数，而另一个可能不支持，因此访问层必须将您的参数转换为转义的 SQL 文字并将它们嵌入到查询中，然后将其发送到服务器.您应该从所有这些中获得主要思想：数据库引擎是不同的，如果您计划通过程序对其施加密集负载，则必须了解您的来龙去脉。知道您的 DMBS 的有线协议可以做什么，不能做什么，知道您的 DBMS 是否能够快速建立连接等等等等。查找有关您的特定 DBMS 性能优化的文档。有关不同 DBMS 的一些讨论，另请参阅this和this。