Warning: Cannot use a scalar value as an array in /home/admin/public_html/forum/include/fm.class.php on line 757

Warning: Invalid argument supplied for foreach() in /home/admin/public_html/forum/include/fm.class.php on line 770
Форумы портала PHP.SU :: Версия для печати :: Проверка запроса перед его выполнением
Форумы портала PHP.SU » PHP » SQL и Архитектура БД » Проверка запроса перед его выполнением

Страниц (1): [1]
 

1. Silver Soft - 05 Декабря, 2013 - 07:24:14 - перейти к сообщению
Доброго времени суток!

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

Заранее благодарен!
2. DeepVarvar - 05 Декабря, 2013 - 08:42:24 - перейти к сообщению
Чтобы узнать таймаут, нужно запрос хотябы раз выполнить. Но некоторые, даже долгие запросы, при повторном вызове могут оказаться в кеше и таймаут будет уже не тот, что был получен в первый раз.

Бредовая идея.
3. AmsTaFF - 05 Декабря, 2013 - 08:52:28 - перейти к сообщению
можно попробовать запрос EXPLAIN, поищите его в доках или в гугле.
+ может быть надо подобавлять индексы, внешние ключи, конфиги сервера чтобы оптимизировать работу, да и ещё оптимизировать сам запрос большой
+ можно попробовать сделать дамп БД, сделать там какую-нибудь копию на отдельном сервере и там запустить сложный запрос (это жесть конечно)
+ насчет того, чтобы снимал сам - вроде там есть настройка в конфиге БД
4. Silver Soft - 05 Декабря, 2013 - 10:16:15 - перейти к сообщению
AmsTaFF пишет:
может быть надо подобавлять индексы, внешние ключи, конфиги сервера чтобы оптимизировать работу, да и ещё оптимизировать сам запрос большой
AmsTaFF пишет:
насчет того, чтобы снимал сам - вроде там есть настройка в конфиге БД

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

я тоже думаю, пока в эту сторону)

а так явно, что что-то с настройками, так как он любой запрос с вложенным запросом заворачивает и отправляется висеть до перезагрузки))
5. DeepVarvar - 05 Декабря, 2013 - 10:52:56 - перейти к сообщению
Silver Soft пишет:
любой запрос с вложенным запросом заворачивает и отправляется висеть до перезагрузки
Да ты шо? А нука:
CODE (SQL):
скопировать код в буфер обмена
  1. SELECT (1) t1, ((SELECT (100) zz) / 2) t2

(Добавление)
AmsTaFF пишет:
попробовать запрос EXPLAIN
И смысл? Это не решит вопрос с кешем. Время выполнения всегда будет разным.
AmsTaFF пишет:
это жесть конечно
Конечно это жесть - Вы там походу даже не слышали про master и slave.
Silver Soft пишет:
я тоже думаю, пока в эту сторону
Не думайте в ту сторону. Это темная сторона.
6. AmsTaFF - 05 Декабря, 2013 - 11:30:17 - перейти к сообщению
DeepVarvar пишет:
AmsTaFF пишет:
попробовать запрос EXPLAIN
И смысл? Это не решит вопрос с кешем. Время выполнения всегда будет разным.

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

DeepVarvar пишет:
AmsTaFF пишет:
это жесть конечно
Конечно это жесть - Вы там походу даже не слышали про master и slave.

Не считаю целесообразным делать master-slave ради одного аналитического запроса.
7. Silver Soft - 06 Декабря, 2013 - 06:23:51 - перейти к сообщению
AmsTaFF пишет:
автор хотел предугадать как будет выполняться запрос

не то чтобы предугадать, я представляю какие данные должны вернутся, но это высоконагруженный сайт, на котором куча посетителей и крайне не желательно, чтобы сайт был недоступен даже 5 минут....
после каждого зависания у главного редактора случается предынфарктное состояние с воплями "Тревога! Мы деньги теряем" )) я обещал подумать, как сделать так, чтобы сервер не падал каждый раз, когда нужно собрать какую нибудь информацию)
8. DeepVarvar - 06 Декабря, 2013 - 06:41:59 - перейти к сообщению
AmsTaFF пишет:
Не считаю целесообразным делать master-slave ради одного аналитического запроса.
Но:
Silver Soft пишет:
это высоконагруженный сайт
Таки целесообразно. Кроме того надо бы ввести транзакции на InnoDB если это сейчас не так. Т.к. MyISAM при изменениях блокирует таблицу полностью и остальные вынуждены ждать, когда InnoDB в этом плане лучше - он блокирует только нужную часть таблицы + поддерживает транзакции, на случапй когда изменения затрагивают несколько таблиц.
9. Silver Soft - 06 Декабря, 2013 - 06:46:56 - перейти к сообщению
DeepVarvar пишет:
Кроме того надо бы ввести транзакции на InnoDB если это сейчас не так

Блин! Посмотрел сейчас и ужаснулся... все таблицы до единой MyISAM... на это нужно было в первую очередь проверить... может после этого и не будет падать сервер при каждом шорохе...
DeepVarvar, спасибо, что подсказал)
10. DeepVarvar - 06 Декабря, 2013 - 06:59:59 - перейти к сообщению
Простой переезд на InnoDB не особо поможет - следить за транзакциями надо с клиента, т.е. из скриптов. А это уже чревато переделом кода.
(Добавление)
Кроме того InnoDB не поддерживает FULLTEXT INDEX и если поиск работает именно на фуллтексте, то нужно будет изголяться.
11. Silver Soft - 06 Декабря, 2013 - 07:04:38 - перейти к сообщению
ну как бы клиент то особо не ощущает сбоев в работе сайта, пока не наступит отчетный период и не нашим продвиженсам не захочется разнообразной статистики...
так то во всех скриптах дальше INNER JOIN ничего нет) у клиента ничего не тормозит, да и жалоб пока не поступало)
помнится как-то работал с проектом где база была PostrgeSQL, так там тоже были сложные аналитические запросы, которые могли запускать сами пользователи и ничего... БД ни разу не зависла)
12. DeepVarvar - 06 Декабря, 2013 - 07:08:37 - перейти к сообщению
Ну, там не тормозило и не глючило, а тут глючит..
Раз на раз не приходится.
В любом случае вопрос нужно изучать глубже, искать узкое место и устранять проблему.
13. Мелкий - 06 Декабря, 2013 - 09:29:38 - перейти к сообщению
DeepVarvar пишет:
Кроме того InnoDB не поддерживает FULLTEXT INDEX и если поиск работает именно на фуллтексте, то нужно будет изголяться.

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

Silver Soft пишет:
крайне не желательно, чтобы сайт был недоступен даже 5 минут....

Silver Soft пишет:
я не админ, а админ рогами упирается и ничего делать не хочеть - типа и так работает)

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

Silver Soft пишет:
помнится как-то работал с проектом где база была PostrgeSQL, так там тоже были сложные аналитические запросы, которые могли запускать сами пользователи и ничего... БД ни разу не зависла)

Магия DBA...

 

Powered by ExBB FM 1.0 RC1