[ новости /+++ | форум | теги | ]

Каталог документации / Раздел "Базы данных, SQL" / Оглавление документа

Послесловие

В заключении хотелось бы повторить те приёмы, которые мы рассмотрели. К сожалению остались ещё неосвещённые моменты. Я буду рада узнать чтобы ещё хотелось осветить. Я жду ваших замечаний по адресу sveta_точка_smirnova_гав_sun_точка_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: используйте часть данных при работе с запросами, которые возвращают неверные результаты на больших объёмах.

Партнёры:

Хостинг: