Форум MySQL

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

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

Вы имеете в виду длинный запрос на пересечение больших таблиц?

Я его переделывл пару раз, но сейчас пересекаю 3 таблицы: points, results, pointsdata

Смысл в том, чтобы выбрать лучшие точки из таблицы points, по оценкам этих точек results (связаны ключом), группирую по точкам и через HAVING отсекаю явно лишнее, потом остальное сортирую и сокращаю уже через LIMIT, затем пишу оставшееся в таблицу, к которой идут уже существенно более частые обращения.

Потом пришлось ещё добавить связь с pointsdata, чтобы исключить возникающую несмотря на все мои усилия несогласованность таблиц, когда точка есть, а её координаты неизвестны, но содержимое pointsdata никак в этом запросе не используется, только наличие точки в индексе.

Вот и весь запрос (INSERT ... SELECT) примерно 50 строк

Вообще-то я ещё планирую поработать над этим запросом.
В частности, мне надо выбирать только те точки в таблице results для которых стоит флаг success, если есть хотя бы один results c иным флагом, то эту точку надо как можно раньше из обработки отбросить, я пока не придумал как.

Лучшее, что приходит в голову - это делать GROUP_CONCAT по полю флага и потом анализировать строковыми функциями на этапе HAVING

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

>PS Не факт, конечно, что дело именно в этом, но попробовать стоит.
Кажется, я нашёл, почему MySQL падал.
У меня время от времени запрос на пересечение больших таблиц с группировкой посылался, примерно раз в 20 минут, а выполнялся он около 5-10 минут.

Но иногда, не успев закончить с одним запросом MySQL получал аналогичный, вытесняя из оперативной памяти на диск система начинала тормозить, и подходило время обрабатывать 3-й запрос. В результате объём памяти задействованный MySQL уходил за разумные пределы.

Пока я отрегулировал время между запросами, - и падения прекратились.
Но это не совсем удовлетворительное решение так как загрузка компьютера может сильно различаться и даже простые запросы могут исполняться долго, поэтому ориентироваться просто на время - ненадёжно.

Как-то бы сделать, чтобы MySQL сам отслеживал эту проблему и отклонял запрос...

>Ставьте третий сервис-пак, на втором сервис-паке нельзя сейчас сидеть

Данная версия MySQL была создана ранее 3-го пака, поэтому как-то не верится, что 3-й пак её излечит.

Кстати, падение MySQL выглядит слкдующим образом:
База просто перестаёт отвечать на запросы, но таблицы после перезагрузки системы целы.

Ставьте третий сервис-пак, на втором сервис-паке нельзя сейчас сидеть в том числе и потому, что очень сильно изменился состав Windows API (много новых удобных функций, которые сами в руки просятся). Вы таких сбоев в других программах будете получать все больше и больше.

PS Не факт, конечно, что дело именно в этом, но попробовать стоит.

В логах в основном вот такие сообщения:

InnoDB: Could not create a Windows event semaphore; Windows error 1816 InnoDB: Could not create a Windows event semaphore; Windows error 1816

версия 5.0.51а-community

Операционная система WINDOWS XP SP2

Увеличив размер пула, я существенно снизил время ожидания клиентов, но когда объём базы доходит до 400М, время ожидания снова становится значительным. К сожалению, самые сложные запросы с группировками идут именно к самым большим таблицам. Это не изменить.

Все запросы можно ускорить, если прилагать усилия, настраивать СУБД, формировать структуру данных, заточенную под скорость, вводить ключи. Когда клиенты чего-то ждут - это нормально только лишь в начале работы сервиса, затем нужно добиваться того, чтобы ожидания не было.

Вообще, то что база данных падает - это странно. Если не сложно сообщите версию сервера и операционную систему. Логи нам тут не сильно помогут, там скорее всего ничего ценного не будет, однако в стоит посмотреть в каталоге данных файл с расширением .err - возможно там есть что-то интересное (это лог ошибок).

>У вас просто маленькая нагрузка на MySQL - не обращайте внимание, если пользуетесь в домашних условиях, вам просто не разогнать MySQL полностью, так как она спроектирована для обслуживания большого количества клиентов.

На что не обращить внимания? На то что она падает 2-3 раза в день?
Насчёт малой нагрузки - спорно.
Клиентов мало, но таблицы большие и запросы сложные.
В частности, мне пришлось увеличивать long_quiry до 30 секунд, чтобы работало.

Примерно половину времени клиенты ждут обработки их запросов базой.
Это ещё можно стерпеть, но вот выяснить чего она падает часто - было бы важно.

Я просто привожу вам возможные причины, котрые так или иначе бросаются в глаза.
А вообще, понятия не имею куда дальше копать.

Я бы посмотрел журнал, но как это сделать?

У вас просто маленькая нагрузка на MySQL - не обращайте внимание, если пользуетесь в домашних условиях, вам просто не разогнать MySQL полностью, так как она спроектирована для обслуживания большого количества клиентов.