Вы собираетесь делать 3 типа тюнинга, 1 реактивный и 2 проактивный.
реагирующий
Неожиданно, некоторые запросы начинают вызывать у вас проблемы. Это может быть связано с ошибкой или функциональностью приложения, ростом таблицы, превышающей ожидания, всплеском трафика или оптимизмом запроса. Это может быть случай типа «посреди ночи», или это может быть в ответ на медлительность системы некритического характера. В любом случае, определяющим признаком реактивной настройки является то, что у вас уже есть проблема . Излишне говорить, что вы хотите делать как можно меньше этого. Что приводит нас к ...
Проактивная
Тип 1: текущее обслуживание
По какому-то графику, каждые несколько месяцев или недель, в зависимости от того, как часто меняется ваша схема и как быстро растут ваши данные, вы должны просматривать выходные данные инструментов анализа производительности вашей базы данных (например, отчеты AWR для администраторов баз данных Oracle). Вы ищите зарождающиеся проблемы, то есть те вещи, которые на пути к требовательной настройке, а также низко висящие фрукты, предметы, которые вряд ли вызовут проблемы в ближайшее время, но могут быть улучшены без особых усилий в надежде предотвратить проблемы будущего. Сколько времени вы должны потратить на это, будет зависеть от того, сколько времени у вас есть, и на что еще вы могли бы тратить его, но оптимальное количество никогда не бывает равным нулю. Тем не менее, вы можете легко уменьшить сумму, которую вам нужно потратить, выполнив больше ...
Тип 2: Правильный дизайн
Предостережение Кнута против «преждевременной оптимизации» широко известно и должным образом уважается. Но правильное определение «преждевременного» должно быть использовано. Некоторые разработчики приложений, когда им разрешено писать свои собственные запросы, имеют тенденцию принимать самый первый запрос, на который они натолкнулись, который является логически правильным, и не обращают внимания на производительность, настоящее или будущее. Или же они могут проверить набор данных разработки, который просто не является репрезентативным для производственной среды (совет: не делайте этого! Разработчики всегда должны иметь доступ к реалистичным данным для тестирования). Дело в том, что правильное время для настройки запроса - это когда он впервые развертывается, а не когда он отображается в списке неэффективного SQL, и определенно не тогда, когда он вызывает критическую проблему.
Так что же можно квалифицировать как преждевременную оптимизацию на землях DBA? Наверху моего списка будет жертва нормализации без явной необходимости. Конечно, вы можете сохранить сумму в родительской строке, а не вычислять ее во время выполнения из дочерних строк, но вам действительно нужно? Если вы Twitter или Amazon, стратегическая де-нормализация и предварительный расчет могут стать вашими лучшими друзьями. Если вы разрабатываете небольшую учетную базу данных для 5 пользователей, надлежащая структура для обеспечения целостности данных должна быть главным приоритетом. Другие преждевременные оптимизации также являются вопросом приоритетов. Не тратьте часы на настройку запроса, который выполняется один раз в день и занимает 10 секунд, даже если вы думаете, что можете сократить его до 0,1 секунды. Может быть, у вас есть отчет, который работает в течение 6 часов в день, но изучите планирование как пакетное задание, прежде чем тратить время на его настройку. Не вкладывайте средства в отдельный реплицируемый экземпляр отчетности в режиме реального времени, если ваша производственная нагрузка никогда не превышает 10% (при условии, что вы можете управлять безопасностью).
Проводя тестирование на основе реалистичных данных, опираясь на обоснованные предположения о росте и моделях трафика (плюс допуски на пики), и применяя свои знания о причудах оптимизатора вашей платформы, вы можете развертывать запросы, оптимально выполняющие (близкие к) не только сейчас, но и в будущем. и при неидеальных условиях. Когда вы применяете надлежащие методы, производительность запросов можно точно прогнозировать и оптимизировать (в том смысле, что каждый компонент работает настолько быстро, насколько это необходимо).
(И пока вы на это, изучите статистику! )