SQL-запросы - как медленно, слишком медленно?

Question

Есть ли у вас формальные или неформальные стандарты для разумно достижимой скорости запросов SQL? Как вы применяете их? Предположим, что рабочая база данных OLTP при полной реалистичной производственной нагрузке составляет пару десятков запросов в секунду, правильно оборудована и настроена.

Личный пример в иллюстративных целях (не рекомендация, сильно зависит от многих факторов, некоторые вне вашего контроля):

Expectation:

Каждая транзакционная единица (один оператор, несколько операторов SQL от начала до конца границ транзакции или одна хранимая процедура, в зависимости от того, какая из них больше) должна выполняться в среднем за 1 секунду или менее, без аномальных выбросов.

Разрешение:

Более медленные запросы должны быть оптимизированы до стандарта. Медленные запросы для отчетов и другого анализа перемещаются в куб OLAP (в лучшем случае) или в статическую базу данных моментальных снимков.

(Очевидно, что некоторые запросы выполнения (вставка / обновление / удаление) не могут быть перемещены, поэтому их необходимо оптимизировать, но, насколько я понимаю, это достижимо.)

Answer 1

Учитывая, что вы не можете ожидать детерминированной производительности в системе, которая может (по крайней мере, теоретически) подвергаться скачкам переходной нагрузки, вы хотите, чтобы ваш SLA производительности был вероятностным. Примером этого может быть:

95% транзакций для завершения в течение 2 секунд.
95% поисковых запросов (более подходящих для экрана поиска) должны быть выполнены в течение 10 секунд.
95% оперативных отчетов должны быть заполнены в течение 10 секунд.

Транзакционные и поисковые запросы не могут быть перемещены из транзакционной системы, поэтому единственные действия, которые вы можете предпринять, это настройка базы данных или приложения или покупка более быстрого оборудования.

Для оперативных отчетов вы должны быть безжалостны в отношении того, что квалифицируется как операционный отчет. Только отчеты о том, что абсолютно должен иметь доступ к актуальным данным, должны запускаться из действующей системы. Отчеты, которые выполняют много операций ввода-вывода, очень антисоциальны в производственной системе, а нормализованные схемы, как правило, неэффективны для создания отчетов. Переместите все отчеты, которые не требуют данных в режиме реального времени, в хранилище данных или в другое отдельное средство отчетности.

Answer 2

O из N - это хорошо, и все, что хуже, например, N ^ 2, будет в конечном итоге слишком медленным.

Answer 3

Я обычно придерживаюсь правила одной секунды при написании / рефакторинге хранимых процедур, хотя на моем рабочем месте нет конкретных правил по этому поводу. Это просто мой здравый смысл. Опыт подсказывает мне, что если для выполнения процедуры, которая не выполняет больших операций массовой вставки, требуется до десяти секунд или более, в коде обычно возникают серьезные проблемы, которые можно легко исправить.

Наиболее распространенная проблема, с которой я сталкиваюсь в SP: низкая производительность - неправильное использование индексов, что приводит к затратным операциям поиска индекса.