多个查询VS存储过程

Question

我有一个应用程序,每小时大约20000个数据操作数据操作有30个参数(对于所有10个查询).有些是文本,有些是数字.一些文本参数长达10000个字符.

每个数据操作都遵循以下内容:

• 单个DATA-OPERATION,在数据库中插入/更新多个表(大约10个).
• 对于每个数据操作,我采取一个连接,
• 然后我在DATA-OPERATION中为每个查询使用new prepared-statement.
• 每次执行查询时都会关闭Prepared语句.
• 连接将重用于所有10个预准备语句.
• DATA-OPERATION完成后,连接关闭.

现在执行此数据操作,

• 10个查询,10个准备语句(创建,执行,关闭),1个n/w调用.
• 1个连接(打开,关闭).

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

在SP的情况下,DATA-OPERATION将具有:

• 1个连接,1个可调用语句,1个/ w命中.

我建议这样,但我被告知

• 这可能比SQL查询更耗时.
• 它会给DB服务器带来额外的负担.

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

基准测试是一种选择.将不得不搜索任何有助于此的工具.任何人都可以建议已经有这种问题的基准.

Answer 1

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

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

1. 将每个操作执行的 10 条语句合并到 1 次调用中的过程
2. 可以使用 a 迭代参数表CURSOR以输入过程 1 的过程

你的流程是

1. 用参数填充一个表，这些参数将由过程 2 输入到过程 1 中
2. 执行程序2

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

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