Избегайте множественных результатов MySQL от SP с Execute

Question

У меня есть 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//

и это дает мульти-результаты. Кроме того, это неудобно, если я получу все эти мульти-результаты (которые мне вообще не нужны), около 5 (параметр limit) для каждой из сотен тысяч записей в Soul, я боюсь, что потребуется все моя память (и все напрасно). Кроме того, я заметил, что если я готовлюсь из пустой строки, она по-прежнему имеет несколько результатов... По крайней мере, как избавиться от них в операторе execute? И я хотел бы иметь рецепт, чтобы избежать ЛЮБОГО вывода из SP, для любого возможного утверждения (у меня также есть много "update ..." и "select ... into " внутри, если они могут производить multi), TNX за любую помощь...

Answer 1

Что ж. Я просто скажу, что выяснилось, что на самом деле проблемы не было. Я не провел тщательного расследования, но похоже, что сервер на самом деле не пытался выполнить оператор ("call Proc();"), чтобы увидеть, будут ли какие-либо результаты для возврата - он просто посмотрел на код и предположил, что будет несколько наборов результатов, требующих подключения, чтобы иметь возможность обрабатывать их. Но в PhpMyAdmin, который я использовал в то время, это было не так. Тем не менее, выполнив ту же команду из клиента командной строки MySQL, все получилось - не жаловаться на заданный контекст подключения и не использовать multis, потому что их там не должно быть - это просто оценка MySQL. Мне не пришлось делать вывод из ошибки, что такой SP, как этот, обязательно вернет multis в MySQL, сбрасывая все промежуточно извлекаемые данные, которые мне нужно будет как-то подавить.

Это может быть не так, как я предполагал, но проблема исчезла.