А ты тупенький наивно думаешь что все вот так все бросили и на постгре кинулись пересаживаться на тебя насмотревшись?
Видишь ли. Есть такое понятие — психология называется.
И когда трольченышь заходит и начинает хамить, нормальная реакция нормального человека — ну его нахер этот постгре, а то подумают что я такой же говнюк.
PS
Ничего против разработчиков постгре не имею. Свою работу они делают очень хорошо. Но вот комьюнити у них… Пусть ему спасибо скажут за то, что они сливали, сливают и будут сливать MySQL.
Нужно просто понимать как работают подзапросы в MySQL.
Проблема в том, что оптимизатор в очень многих случаях считает " c.id IN " неконстантным значением и выполняет подзапрос не один, а столько раз, сколько посчитает нужным. Причем эксплайн напишет — все замечательно, индексы правильные и все тип-топ. Вот только не видно сколько раз будет выполнен подзапрос.
На тестах, когда данных немного и нет реальных нагрузок — это незаметно, но на продакшнах проблемы могут повылазить и не по детски.
В общем случае лучше уходить к джойну. Хотя он тот еще не сахар.
В идеале лучшим вариантом мог бы быть подзапрос гарантированно выполняющийся один раз и отдающий набор констант в IN (бла, бла, бла).
Заворачиваю в ХП.
Выполняю подзапрос, его результат через GROUP_CONCAT в переменную, что-то типа
SELECT GROUP_CONCAT(fld) FROM table INTO myvar;
Собираю строку запроса
@query = CONCAT('SELECT fld1 FROM table1 WHERE fld2 IN (', myvar, ')';
Препарирую @query и выполняю его.
В IN константа, и оптимизатор не дуркует.
Грабли там только одни, счас не помню, но по моему при NULL или пустой строке в конкатенируемом поле, результат GROUP_CONCAT может выглядеть типа ",,,77,2". Ну и соответственно ошибка при выполнении.
Посмотрите посещемость хабра за последние полгода на какой-нибудь алексе.
Если учесть, что большинство из людей, имеющих нормальную квалификацию и желание писать, уже давно на хабре, понятно что это за вновь поступивший контингент в подавляющем большинстве. Попса.
Оно в принципе и ничего бы, но эта свора отбивает желание у нормальных людей писать нормальные статьи. Раньше практически каждый день хотя бы одна сильная статья, но была. Сейчас в неделю две-три…
Для проекта это возможно и к лучшему (посещаемость, монетизация и т.п.), для желающих читать серьезные статьи — жопа.
И никаких других.
А если экономика в полной, а российская в особо глубокой, жопе и надолго, то говорить о бла-бла-бля продвижениях «всемь» не приходится.
Если кто попробует возразить насчет экономики — начинайте возражать с ответа на вопрос:
«Вы каждый день кушаете? И на что?»
А про кризису конец — выше на росстат уже послали.
Видишь ли. Есть такое понятие — психология называется.
И когда трольченышь заходит и начинает хамить, нормальная реакция нормального человека — ну его нахер этот постгре, а то подумают что я такой же говнюк.
PS
Ничего против разработчиков постгре не имею. Свою работу они делают очень хорошо. Но вот комьюнити у них… Пусть ему спасибо скажут за то, что они сливали, сливают и будут сливать MySQL.
Нужно просто понимать как работают подзапросы в MySQL.
Проблема в том, что оптимизатор в очень многих случаях считает " c.id IN " неконстантным значением и выполняет подзапрос не один, а столько раз, сколько посчитает нужным. Причем эксплайн напишет — все замечательно, индексы правильные и все тип-топ. Вот только не видно сколько раз будет выполнен подзапрос.
На тестах, когда данных немного и нет реальных нагрузок — это незаметно, но на продакшнах проблемы могут повылазить и не по детски.
В общем случае лучше уходить к джойну. Хотя он тот еще не сахар.
В идеале лучшим вариантом мог бы быть подзапрос гарантированно выполняющийся один раз и отдающий набор констант в IN (бла, бла, бла).
Ну а дальше все просто. Я это для себя так решил
sql.ru/forum/actualthread.aspx?tid=650047&hl=%ec%e5%f1%fc%e5
Заворачиваю в ХП.
Выполняю подзапрос, его результат через GROUP_CONCAT в переменную, что-то типа
SELECT GROUP_CONCAT(fld) FROM table INTO myvar;
Собираю строку запроса
@query = CONCAT('SELECT fld1 FROM table1 WHERE fld2 IN (', myvar, ')';
Препарирую @query и выполняю его.
В IN константа, и оптимизатор не дуркует.
Грабли там только одни, счас не помню, но по моему при NULL или пустой строке в конкатенируемом поле, результат GROUP_CONCAT может выглядеть типа ",,,77,2". Ну и соответственно ошибка при выполнении.
Погуглите про подзапросы в MySQL.
Потом на реальных данных верещать начинают, почему у меня запрос 5 мин. выполняется?!!!
Он же такой быстрый был. И эксплайн такой красивый :-(
Про коммент ниже. С константами там действительно все Ок.
Без такого шоу тупых да еще и бесплатного скучно будет.
:-)
До них еще никто в России не смог водку раком поставить.
А они смогли!!!
Силища :-)
Спалили контору.
dev.mysql.com/doc/refman/5.1/en/ansi-diff-comments.html
В этом engine уже реализованы гуглопатчи и еще куча фич рихтующих движок. Приблизительно на одном уровне с перконой по характеристикам.
Если учесть, что большинство из людей, имеющих нормальную квалификацию и желание писать, уже давно на хабре, понятно что это за вновь поступивший контингент в подавляющем большинстве. Попса.
Оно в принципе и ничего бы, но эта свора отбивает желание у нормальных людей писать нормальные статьи. Раньше практически каждый день хотя бы одна сильная статья, но была. Сейчас в неделю две-три…
Для проекта это возможно и к лучшему (посещаемость, монетизация и т.п.), для желающих читать серьезные статьи — жопа.
Тот кто контролирует новости управляет…
Не мое.
Давно зомбоящик не смотрели?
Сет Годин. Доверительный маркетинг.
Как выше писал никакой маркетинг и хреновое комьюнити.
Потому что люди обман не прощают.
И какой бы хороший продукт не был сделан — он никогда не станет первым.
Утверждение что их нет было некомпетентным или осознанным?
:-)
MySQL follows the SQL:2003 syntax for stored routines, which is also used by IBM's DB2.
«как исполнить ХП с про»
Лечил костылем.
отдавал строку параметром, в процедуре парсил, и через препаре выполнял. Так как надо было всего раза три — проблем никаких.
Вот только вопрос — они есть?
Вы что думете из постгре в пых вы по другому тянуть будете?
Вместо SELECT бла-бла-бла отправляете CALL и так же как из селекта забираете результат.
В чем проблемы.