Что я должен учитывать при разработке и оптимизации хранимой процедуры, которая будет работать на больших серверах баз данных?

Question

На работе кто-то сказал

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

Я смущен этим утверждением в нескольких отношениях:

1. Означает ли "большой сервер базы данных" большой объем данных и, если да, то как это влияет на структуру хранимой процедуры?

2. Является ли дизайн и оптимизация хранимой процедуры таким же, как дизайн и оптимизация обычного SQL?

3. Является ли "дизайн и оптимизация" излишним? Другими словами, если вы спроектируете хранимую процедуру хорошо, не будет ли она автоматически оптимизирована для производительности?

Answer 1

1. Как правило, да. Когда вы работаете с базами данных, если вы работаете с большими объемами данных, вещи, которые будут быстрыми для небольших наборов данных, могут быть довольно медленными для больших.

2. Нет, потому что хранимая процедура - это обычный язык программирования, который включает в себя SQL.

3. Не обязательно. У вас может быть два отдельных проекта, один из которых прост в написании кода, прост в обслуживании и т. Д., Но он также медленный для больших объемов данных. А другой, возможно, имеет менее чистый, менее простой дизайн, но добавляет сложности ради производительности.

Answer 2

1. Большие серверы БД обычно отличаются от маленьких по нескольким причинам: больше данных, больше ЦП, больше ОЗУ, а также большие и более быстрые диски или сеть SAN. В этой среде некоторые запросы выполняются не так, как на маленьких машинах. Например, сложные объединения с большими таблицами могут выполняться там достаточно быстро и слишком медленно на меньшей машине. Существуют также подходы кеширования и управления памятью, которые имеют смысл на больших машинах, но не такие полезные на небольших.

2. Не совсем. Например, когда вы работаете с хранимой процедурой, вы также принимаете во внимание границы пакетов и возможные множественные результирующие наборы. У SP также могут быть проблемы с безопасностью, которых нет в динамическом SQL или параметризованных запросах.

3. Нет. Дизайн означает создание чего-то, что работает правильно и отвечает бизнес-требованиям. Оптимизация относится к скорости или масштабируемости или к обоим. SP может быть медленным, но все равно делать то, что должен. Обычная лучшая практика (хотя я не всегда согласен с ней) - сначала заставить ее работать правильно, а затем оптимизировать, если это окажется необходимым.