使用 Execute 避免来自 SP 的 MySQL 多结果
我有一个类似的 SP
BEGIN
DECLARE ...
CREATE TEMPORARY TABLE tmptbl_found (...);
PREPARE find FROM
" INSERT INTO tmptbl_found
(SELECT userid FROM
(
SELECT userid FROM Soul
WHERE
.?.?.
ORDER BY
.?.?.
) AS left_tbl
LEFT JOIN
Contact
ON userid = Contact.userid
WHERE Contact.userid IS NULL LIMIT ?)
";
DECLARE iter CURSOR FOR SELECT userid, ... FROM Soul ...;
...
l:LOOP
FETCH iter INTO u_id, ...;
...
EXECUTE find USING ...,. . .,u_id,...;
...
END LOOP;
...
END//
,它给出了多种结果。除此之外,这很不方便,如果我得到所有这些多重结果(我真的根本不需要),对于 Soul 中数十万条记录中的每一条大约有 5 个(限制参数),我担心它会占用所有结果我的记忆(一切都是徒劳的)。 另外,我注意到,如果我确实从空字符串中准备,它仍然有多个结果...... 至少如何在执行语句中摆脱它们? 我想要一个方法来避免 SP 的任何输出,对于任何可能的语句 (我还有很多“更新...”和“选择...到”里面,如果它们可以产生多个)。 Tnx 寻求任何帮助...
i have an SP like
BEGIN
DECLARE ...
CREATE TEMPORARY TABLE tmptbl_found (...);
PREPARE find FROM
"
INSERT INTO tmptbl_found
(SELECT userid FROM
(
SELECT userid FROM Soul
WHERE
.?.?.
ORDER BY
.?.?.
) AS left_tbl
LEFT JOIN
Contact
ON userid = Contact.userid
WHERE Contact.userid IS NULL LIMIT ?)
";
DECLARE iter CURSOR FOR SELECT userid, ... FROM Soul ...;
...
l:LOOP
FETCH iter INTO u_id, ...;
...
EXECUTE find USING ...,. . .,u_id,...;
...
END LOOP;
...
END//
and it gives multi-results. Besides it's inconvenient, if i get all this multi-results (which i really don't need at all), about 5 (limit's param) for each of the hundreds of thousands of records in Soul, i'm afraid it will take all my memory (and all in vain).
Also, i noticed, if i do prepare from an empty string, it still has multi-results...
At least how to get rid of them in the execute statement?
And i would like to have a recipe to avoid ANY output from SP, for any possible statement
(i also have a lot of "update ..."s and "select ... into "s inside, if they can produce multi's).
Tnx for any help...
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
出色地。我只想说,事实证明确实没有问题。我没有仔细调查,但看起来服务器实际上并没有尝试执行语句(“call Proc();”)来查看是否有任何结果返回 - 它只是查看代码并假设将会有多个结果集,需要连接能够处理它们。但在我当时使用的 PhpMyAdmin 中,情况并非如此。然而,从 MySQL 命令行客户端发出相同的命令就成功了 - 没有抱怨给定的连接上下文,也没有多重,因为它们不必在那里 - 这只是 MySQL 的估计。我不必从错误中得出结论,像这样的 SP 肯定会在 MySQL 中返回 multis,刷新所有中间获取的数据,我需要以某种方式抑制这些数据。
可能不是我想象的那样,但问题现在已经解决了。
Well. I'll just say that it has come out that there wasn't really a problem. I didn't investigate hard, but it looks like the server didn't actually try to execute the statement ("call Proc();") to see whether there will be any results to return - it just looked at the code and assumed that there will be multiple result sets, requiring connection to be capable of handling them. But in PhpMyAdmin, which i was using at the time, it wasn't. However, issuing the same command from the MySQL command line client did the trick - no complaining about the given connection context, and no multis, too, because they don't have to be there - it's just a MySQL's estimation. I didn't have to conclude from the error, that the SP like this one will certainly return multis in MySQL, flushing all the intermediately fetched data, which i will need to suppress somehow.
It may be not so as i supposed, but the problem is gone now.