多查询 VS 存储过程

Question

我有一个应用程序 每小时进行大约 20000 次数据操作 DATA-OPERATION 总共有 30 个参数（对于所有 10 个查询）。有些是文本，有些是数字。一些文本参数长达 10000 个字符。

每个数据操作都执行以下操作：

• 单个数据操作，在数据库中插入/更新多个表（大约 10 个）。
• 对于每一个数据操作，我都会使用一个连接，
• 然后我为 DATA-OPERATION 中的每个查询使用新的prepared-statement。
• 每次执行查询时，Prepared-statement 都会关闭。
• 为所有 10 个准备好的语句重复使用连接。
• 数据操作完成后连接关闭。

现在执行这个数据操作，

• 10 个查询，10 个准备好的语句（创建、执行、关闭），1 个 n/w 调用。
• 1 个连接（打开、关闭）。

我个人认为，如果我从以上 10 个查询中创建一个存储过程，那将是更好的选择。

如果是 SP，DATA-OPERATION 将有：

• 1 个连接，1 个可调用语句，1 个 n/w 命中。

我建议过这个，但有人告诉我

• 这可能比 SQL 查询更耗时。
• 它会给数据库服务器增加额外的负载。

我仍然认为SP是更好的选择。请让我知道您的意见。

基准测试是一种选择。将不得不搜索任何可以帮助解决此问题的工具。 任何人也可以为此类问题建议已经可用的基准。

Answer 1

任何建议都部分取决于执行查询的脚本所在的位置。如果执行查询的脚本与 MySQL 实例在同一台服务器上，那么您不会看到太大的差异，但与 1 个存储过程相比，执行 200k 查询仍然会有一点开销。

无论哪种方式，我的建议都是将其作为存储过程。您可能需要几个程序。

1. 结合您每次操作执行的 10 条语句的过程 1 次通话
2. 可以使用CURSOR 对参数表进行迭代以输入过程 1 的过程

你的过程是

1. 使用将由过程 2 输入过程 1 的参数填充表
2. 执行程序 2

这将产生性能优势，因为无需连接到 MySQL 服务器 20000*10 次。虽然每个请求的开销可能很小，但毫秒加起来。即使每个请求节省了 0.1 毫秒，也仍然节省了 20 秒。

另一种选择可能是修改您的请求以一次执行所有 20k 数据操作（如果可行），方法是调整您的 10 个查询以从上述数据库表中提取数据。所有这一切的关键是在单个批量插入中加载参数，然后在一个过程中使用 MySQL 服务器上的语句来处理它们，而无需进一步的往返。