|
Задавайте вопросы, мы ответим
Вы не зашли.
В принципе я накидал вот такую ХП.
Отредактированно NT Man (26.02.2011 13:04:20)
Неактивен
Честно говоря, не понял, какой смысл во всей этой конструкции — процедура не
делает ничего в принципе: делает плохой SELECT во внутреннюю переменную
и тут же ее забывает. Я бы сказал, что идеальной оптимизацией является удаление
такой процедуры 
А вообще, конечно, да — делайте временную табличку со списком id и объеди-
няйте запрос с ней. Передавать TEXT в процедуру — еще более громоздко и не-
уклюже.
Неактивен
paulus, это же всего лишь пример демонстрирующий передачу списка неких id-шников в ХП, после комментария локальный код, много кода не имеющего отношения к теме.
Задачи то такие часто встречаются, банально грид с чекбоксами, и надо по кнопочке массово сделать бизнес логику, например, перевести документы в следующую по бизнес процессу стадию.
Если делать через временную таблицу, то какой тип движка хранения данных для неё выбрать? Для всей базы используется XtraDB, а тут вот думается MEMORY наверно будет лучше? Или для CREATE TEMPORARY TABLE это не имеет значения? Насколько вообще операция создания и уничтожения таблицы затратна?
Есть еще 3 вариант, отказаться от передачи списка параметров, курсора и просто дергать ХП для каждой записи из сервера приложений.
Что будет быстрее?
Отредактированно NT Man (26.02.2011 16:27:25)
Неактивен
Они будут MEMORY по умолчанию — они же хранятся в памяти Операция
создания объекта в памяти — не очень затратная (объект же в памяти). Я
думаю, что вполне сравнима с созданием TEXT для передачи в изначальном
варианте
Дергать процедуру на каждую строку — не известно, насколько тяжело. Если
в комментариях выполнение вычислений идет половину дня, то не принципи-
ально, будете ли Вы дергать процедуру на каждую строку или один раз на все.
В другом предельном случае — так, как написано в первом сообщении (ниче-
го не делать) — overhead от запуска процедуры очень большой — создание
временных параметров (помимо анализа запроса), выделение стека и т.п.
Я бы всё-таки использовал временную табличку.
Неактивен
С временной табличкой засада. DROP TABLE и TRUNCATE TABLE неявно делают COMMIT и переводят MySQL а AUTO COMMIT режим, что есть очень не хорошо. Как от этого побочного эффекта избавиться пока даже не представляю.
Пока сделал так:
Отредактированно NT Man (27.02.2011 14:38:11)
Неактивен
А в чем проблема? Создавайте таблицу перед тем, как начать транзакцию?
Неактивен
paulus написал:
А в чем проблема? Создавайте таблицу перед тем, как начать транзакцию?
Ну это уже архитектурная проблема. Стартом, коммитом и откатом транзакций занимается ядро, а не локальный код. Конечно в локальном коде можно самому стартовать транзакции, но если у нас произойдет ошибка, то не откатиться, то, что делал другой локальный код до того момента когда мы здесь перестартовали транзакцию. Отсюда всякие непонятности и глюки. И это не решит проблему с тем, что в памяти останется висеть временная табличка.
[ядро]START TRANSACTION[/ядро]
[локально вызванная процедура 1]Что-то правит в базе[/локально вызванная процедура 1]
[локально вызванная процедура 2]
правильно по идее
DROP IF EXISTS TABLE ... ; CREATE TEMPORARY TABLE ...
Что-то правит в базе
DROP TABLE ...
[/локально вызванная процедура 2]
[ядро]нет ошибок, COMMIT, в противном случае ROLLBACK[/ядро]
Неактивен
Насколько я вижу, это проблема архитектуры Вашего приложения (наличие ядра,
например, которое нельзя менять). Да, разные окружения накладывают свои огра-
ничения. Это стандартная проблема — если Вы не управляете всем, всё Вы сделать
не можете.
Но это я отвлекся. На самом деле, всё куда проще: я Вам поверил, что CREATE
TEMPORARY TABLE работает как DDL и завершает транзакцию, а это не так
Т.е. можно безопасно создать временную таблицу тогда, когда она нужна, и не
переживать по поводу наличия ядер и транзакций (проверил на 5.1.53).
Неактивен
Блина, перечитал весь тред, это я невнимательный 
Вы написали, что DROP TABLE бьет транзакции. Да, бьет. А вот
DROP TEMPORARY TABLE, которому тут самое место, не бьет.
Неактивен
paulus, вот теперь красота. Спасибо!
Неактивен
