Послесловие

В заключении хотелось бы повторить те приёмы, которые мы рассмотрели. К сожалению остались ещё неосвещённые моменты. Я буду рада узнать чтобы ещё хотелось осветить. Я жду ваших замечаний по адресу sveta_точка_smirnova_гав_oracle_точка_com или sveta_гав_js-client_точка_com

Список приёмов.

Приём №1: используйте оператор вывода для вывода запроса в том виде, в котором его получает СУБД.

Приём №2: используйте general query log, если вам нужно определить какой именно запрос вызывает неправильное поведение вашего приложения.

Приём №3: после того как вы выявили запрос, вызывающий проблемы, запустите его в командной строке и проанализируйте полученный результат.

Приём №4: пробуйте изменить SQL таким образом, чтобы результат был правильным. Пользуйтесь поисковыми системами для нахождения workaround.

Приём №5: используйте EXPLAIN EXTENDED для того, чтобы понять каким образом оптимизируется (а значит и выполняется) SQL запрос.

Приём №6: преобразуйте DML запросы в соответствующий SELECT чтобы выяснить какие строки будут изменены.

Приём №7: проверяйте ваш сценарий шаг за шагом в обратном порядке пока не найдёте проблемный запрос.

Приём №8: всегда проверяйте результат запроса! Используйте инструменты вашего коннектора или вывод интерактивного клиента.

Приём №9: настройте ваше приложение таким образом, что оно будет записывать логи запросов самостоятельно.

Приём №10: используйте MySQL Proxy или любой другой прокси.

Приём №11: используйте SHOW PROCESSLIST чтобы посмотреть список одновременно выполняемых запросов.

Приём №12: используйте таблицу INFORMATION_SCHEMA.PROCESSLIST если вам нужен отсортированный по какому-либо параметру список одновременных запросов.

Приём №13: используйте SHOW ENGINE INNODB STATUS чтобы получить информацию о транзакциях.

Приём №14: используйте general query log если в выводе SHOW ENGINE INNODB STATUS только часть информации о проблемной транзакции.

Приём №15: проверяйте значение max_allowed_packet и размер передаваемых данных если сервер выдаёт ошибку для синтаксически правильного запроса.

Приём №16: проверяйте значение wait_timeout и других timeout-ов, если вы встречаете ошибку "MySQL server has gone away"

Приём №17: проверяйте значение connect_timeout в случае ошибки «Lost connection to MySQL server at 'reading authorization packet'»

Приём №18: всегда используйте error log

Приём №19: используйте general query log если error log не содержит информации о причинах крушения сервера.

Приём №20: всегда проверяйте достаточно ли у вас RAM для выделенных буферов.

Приём №21: устанавливайте значение max_connections таким какое вы сможете обслужить.

Приём №22: используйте средства мониторинга вашей операционной системой чтобы установить что потребляет избыточное количество ресурсов, которое приводит к крушению MySQL сервера.

Приём №23: Используйте опцию log_warnings=2 чтобы отследить имеются ли у вас отклонённые соединения.

Приём №24: проверяйте запросы на сервере, запущенном с опцией –no-defaults и сравнивайте результат.

Приём №25: если творится что-то непонятное, первым делом проверьте записи в error log.

Приём №26: насторйте InnoDB Monitor чтобы иметь в error log информацию о всех транзакциях с применением InnoDB таблиц.

Приём №27: используйте slow query log чтобы выявить медленные запросы.

Приём №28: используйте MySQL Sandbox, чтобы быстро и удобно оттестировать ваше приложение на нескольких версиях MySQL.

Приём №29: используйте часть данных при работе с запросами, которые возвращают неверные результаты на больших объёмах.