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

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

1 голос
/ 12 июня 2010

У меня есть 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" внутри, если они могут создавать мульти). Tnx за любую помощь ...

1 Ответ

0 голосов
/ 28 ноября 2010

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

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

...