普遍的共识似乎是直接查询语句不允许使用参数，而准备好的语句则允许。
但是在 Go 的 database/sql 包中，您可以使用 ODBC 参数并将参数发送到诸如 db.QueryRow() 和 db.Query() 之类的东西。所以看起来它们在功能上是等效的。
话虽如此，那么首先创建一个语句，然后执行它有什么意义呢？假设语句首先针对数据库进行编译——这不会增加负载并因此降低性能，因为您要添加额外的行程吗？既然您可以从 Query/QueryRow 中获取参数，那岂不是让语句成为一件坏事吗？
问问题
1536 次
2 回答
4
请记住，该database/sql软件包旨在涵盖所有理论上可能的 SQL 数据库系统的功能，而不会妨碍特定平台。
SQL驱动程序实例在运行时通过sql.Register. 这些驱动程序不一定基于 ODBC，它可能是其他东西。
有些 SQL 数据库支持转义查询参数，有些不支持——有些支持“编译”准备好的语句，有些则不支持。
通过使其成为一个两步过程，驱动程序可以决定在何处以及如何转义查询参数以及如何将它们插入到查询中。
您可以使用 ODBC 参数并将参数发送到诸如 db.QueryRow() 和 db.Query() 之类的东西
于 2013-11-11T07:51:32.160 回答
2
理论上，当数据库服务器接收到一个简单的 SQL 语句（或批处理）时，它必须对其进行编译：将其解析为某种内部形式，然后准备所谓的“查询计划”——操作序列（如索引或表）扫描、比较等）以执行实际请求。做这一切显然会耗费一定的服务器资源。如此多的 DBMS 开始支持“准备好的语句”：服务器只执行一次解析/规划步骤，然后将“句柄”交给您随后多次“调用”的结果，只提供不同的参数。
现在让我们进入一个更复杂的领域。
首先要注意的是，当内存和处理能力变得更便宜时，在商品到高端服务器上运行的 DBMS 能够在处理查询时花费更多资源，因此其中一些缓存用户查询。也就是说，当您执行简单查询（SQL 语句或批处理）时，服务器会执行所有常见的解析/查询计划，但随后会保存结果，如果稍后遇到相同的查询，它会跳过处理部分并执行对数据的操作。
第二点要注意的是，虽然编程语言/库倾向于为程序员提供访问数据库引擎的某个通用C接口（ODBC是一个例子，database/sqlforGo是另一个例子，还有无数其他的），但有线协议或其他实际访问服务器的方式可能大不相同。例如，一台数据库服务器可能支持在其有线协议中与查询一起传递参数，而另一台可能不支持，因此访问层必须将您的参数转换为转义的 SQL 文字并将它们嵌入到查询中，然后将其发送到服务器.
您应该从中获得的主要思想是：数据库引擎是不同的，如果您计划通过程序对其施加大量负载，则必须了解自己的来龙去脉。了解您的 DMBS 的有线协议可以做什么和不能做什么，知道您的 DBMS 是否快速建立连接等等等等。查找有关特定 DBMS 性能优化的文档。
于 2013-11-11T13:03:29.897 回答