SQL-запросы - насколько медленно - слишком медленно?
Есть ли у вас какие-либо формальные или неформальные стандарты разумно достижимой скорости SQL-запросов? Как вы их обеспечиваете? Предположим, что производственная база данных OLTP при полной реалистичной производственной нагрузке в пару десятков запросов в секунду, должным образом оборудована и настроена.
Личный пример в иллюстративных целях (не рекомендация, сильно зависит от многих факторов, некоторые из которых не зависят от вас):
Ожидание:
Каждая транзакционная единица (один оператор, несколько операторов SQL от начала до конца границы транзакции или одна хранимая процедура, в зависимости от того, что больше) должна выполняться в среднем за 1 секунду или меньше, без аномальных выбросов.
Разрешение:
Более медленные запросы должны быть оптимизированы по стандарту. Медленные запросы отчетов и другого анализа перемещаются в куб OLAP (в лучшем случае) или в базу данных статических моментальных снимков.
(Очевидно, что некоторые исполнительные запросы (Insert / Update / Delete) не могут быть перемещены, поэтому должны быть оптимизированы, но пока, по моему опыту, это было достижимо.)
Ответы 3
Учитывая, что вы не можете ожидать детерминированной производительности от системы, которая может (по крайней мере теоретически) подвергаться кратковременным скачкам нагрузки, вы хотите, чтобы ваше соглашение об уровне обслуживания производительности было вероятностным. Примером этого может быть:
95% транзакций завершаются в течение 2 секунд. 95% поисковых запросов (более подходящих для экрана поиска) выполняются в течение 10 секунд. 95% операционных отчетов заполняются в течение 10 секунд.
Транзакционные и поисковые запросы нельзя перенести из транзакционной системы, поэтому единственные действия, которые вы можете предпринять, - это настройка базы данных или приложения или покупка более быстрого оборудования.
Что касается оперативных отчетов, вы должны безжалостно относиться к тому, что считается операционным отчетом. Только отчеты о том, что абсолютно должен иметь доступ к актуальным данным, должны запускаться из действующей системы. Отчеты, в которых выполняется много операций ввода-вывода, очень антиобщественны в производственной системе, а нормализованные схемы, как правило, довольно неэффективны для отчетности. Переместите любые отчеты, для которых не требуются данные в реальном времени, в хранилище данных или другое отдельное средство отчетности.
Я обычно придерживаюсь правила одной секунды при написании / рефакторинге хранимых процедур, хотя на моем рабочем месте нет никаких конкретных правил по этому поводу. Это просто мой здравый смысл. Опыт подсказывает мне, что если выполнение процедуры занимает до десяти секунд или более, не выполняя больших объемных вставок, обычно в коде возникают серьезные проблемы, которые можно легко исправить.
Наиболее распространенная проблема, с которой я сталкиваюсь в SP: s с низкой производительностью, - это неправильное использование индексов, вызывающее дорогостоящие операции поиска по индексу.
O из N - это хорошо, а что-то хуже, например N ^ 2, в конечном итоге будет слишком медленным.