Проверка запроса перед его выполнением

Доброго времени суток!

Иногда приходится делать достаточно сложные sql-запросы на MySQL-сервер, которые могут повесить сервер. Sql-запросы часто имеют аналитическую функцию, то есть запустил раз там в месяц-два, чтобы узнать опредленные изменения.
Так вот вопрос: можно как-то проверить запрос перед его непосредственным выполнением на то что повесит ли он сервер или выполнится нормально?
Пока что, чтобы не весит сервер приходится в php писать множественные односложные запросы и потом уже смотреть - это муторно) может, как-то можно указать тайм-аут, чтобы сервер не мучился и если долго запрос выполняется, то просто его снимал с исполнения?

Заранее благодарен!

Чтобы узнать таймаут, нужно запрос хотябы раз выполнить. Но некоторые, даже долгие запросы, при повторном вызове могут оказаться в кеше и таймаут будет уже не тот, что был получен в первый раз.

Бредовая идея.

-----
Шта? Репозиторий?

можно попробовать запрос EXPLAIN, поищите его в доках или в гугле.
+ может быть надо подобавлять индексы, внешние ключи, конфиги сервера чтобы оптимизировать работу, да и ещё оптимизировать сам запрос большой
+ можно попробовать сделать дамп БД, сделать там какую-нибудь копию на отдельном сервере и там запустить сложный запрос (это жесть конечно)
+ насчет того, чтобы снимал сам - вроде там есть настройка в конфиге БД

-----
Делюсь своим опытом

я не админ, а админ рогами упирается и ничего делать не хочеть - типа и так работает)
я тоже думаю, пока в эту сторону)

а так явно, что что-то с настройками, так как он любой запрос с вложенным запросом заворачивает и отправляется висеть до перезагрузки))

Да ты шо? А нука:

-----
Шта? Репозиторий?

от Explain можно получить некоторые данные, на основе которых можно сделать предположение о запросе. Это к тому, что автор хотел предугадать как будет выполняться запрос. Это не решение, это лишь направление чтобы "подумать".


Не считаю целесообразным делать master-slave ради одного аналитического запроса.

-----
Делюсь своим опытом

не то чтобы предугадать, я представляю какие данные должны вернутся, но это высоконагруженный сайт, на котором куча посетителей и крайне не желательно, чтобы сайт был недоступен даже 5 минут....
после каждого зависания у главного редактора случается предынфарктное состояние с воплями "Тревога! Мы деньги теряем" )) я обещал подумать, как сделать так, чтобы сервер не падал каждый раз, когда нужно собрать какую нибудь информацию)

Но: Таки целесообразно. Кроме того надо бы ввести транзакции на InnoDB если это сейчас не так. Т.к. MyISAM при изменениях блокирует таблицу полностью и остальные вынуждены ждать, когда InnoDB в этом плане лучше - он блокирует только нужную часть таблицы + поддерживает транзакции, на случапй когда изменения затрагивают несколько таблиц.

-----
Шта? Репозиторий?

Блин! Посмотрел сейчас и ужаснулся... все таблицы до единой MyISAM... на это нужно было в первую очередь проверить... может после этого и не будет падать сервер при каждом шорохе...
DeepVarvar, спасибо, что подсказал)

Простой переезд на InnoDB не особо поможет - следить за транзакциями надо с клиента, т.е. из скриптов. А это уже чревато переделом кода.
(Добавление)
Кроме того InnoDB не поддерживает FULLTEXT INDEX и если поиск работает именно на фуллтексте, то нужно будет изголяться.

-----
Шта? Репозиторий?

ну как бы клиент то особо не ощущает сбоев в работе сайта, пока не наступит отчетный период и не нашим продвиженсам не захочется разнообразной статистики...
так то во всех скриптах дальше INNER JOIN ничего нет) у клиента ничего не тормозит, да и жалоб пока не поступало)
помнится как-то работал с проектом где база была PostrgeSQL, так там тоже были сложные аналитические запросы, которые могли запускать сами пользователи и ничего... БД ни разу не зависла)

Ну, там не тормозило и не глючило, а тут глючит..
Раз на раз не приходится.
В любом случае вопрос нужно изучать глубже, искать узкое место и устранять проблему.

-----
Шта? Репозиторий?

Или обновиться до MySQL 5.6, где innoDB уже умеет FullText



Выгоняйте админа к чертям.
С таким желаемым аптаймом реплика должна быть уже. Если мастер жив - запускать OLAP на слейве. Если мастер сдох - переключать слейв в мастер и отключать OLAP-задачи, мол, подождите, мы скоро восстановимся.


Магия DBA...

-----
PostgreSQL DBA