使用 Execute 避免来自 SP 的 MySQL 多结果

发布于 2024-09-05 13:10:06 字数 934 浏览 10 评论 0原文

我有一个类似的 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 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

淡笑忘祈一世凡恋 2024-09-12 13:10:06

出色地。我只想说,事实证明确实没有问题。我没有仔细调查,但看起来服务器实际上并没有尝试执行语句(“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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文