Razbezhkin 30 авг 2007 в 05:57

Производительность хранимых процедур MS SQL Server 2000/2005

3 мин

6.1K

IT-компании

Комментарии 14

pietrovich 30 авг 2007 в 06:08

может 2005 SQL а не 2003 ?

Razbezhkin 30 авг 2007 в 06:55

да, 2005

pietrovich 30 авг 2007 в 06:59

так может стоит отредактировать название? ;)
а в остальном спасибо, никогда не замечал раньше, но на уровне подсознания чувствовал что не все так гладко со сторедами. есть над чем подумать :)

Razbezhkin 30 авг 2007 в 07:23

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

olegi 30 авг 2007 в 07:58

1. "При запуске ранимой " — опечатка

2. вопрос: насколько шаг 7 медленнее шага 8?

Razbezhkin 31 авг 2007 в 06:53

Смотрите. допустим, таблица содержит 1000000 строк, при этом в одну страницу попадает 100 строк, тогда table scan прочитает 10000 страниц. А при использовании bookmark lookup количество логических чтений составит 100000, т.к. каждая операция bookmark lookup читает за одну операцию 1 страницу данных, а число операций будет равно числу строк.

разумеется есть еще и кэширование, благодаря чему разнится в производительности будет не так заметна на глаз, но при оптимизации запросов показатель кэширования имее не очен большой вес, в основном учитываются именнно логические чтения (сколько бы страниц читалось при отсутствии кэша)

norguhtar 30 авг 2007 в 08:05

эээ, а модификаторов у создаваемой процедуры нет? в PostgreSQL есть возмоность указать насколько динамичны используемые данные.

Wellick 30 авг 2007 в 17:08

А на что это влияет в PosgreSQL?

norguhtar 31 авг 2007 в 02:57

На то как кешируются результаты и планы у хранимых процедур.

Razbezhkin 31 авг 2007 в 06:54

Модификаторов нет. в следующей статье описан способ борьбы с этой ситуацией: http://razbezhkin.habrahabr.ru/blog/2430…

norguhtar 31 авг 2007 в 07:00

эээ... а прямее способа точно нету?

Razbezhkin 31 авг 2007 в 08:24

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

Wellick 30 авг 2007 в 17:07

Спасибо за статью. Еще бы график какой-нибудь в конце =)
И всё-таки, основная причина использования хранимок, по моему опыту, не повышение производительности, а создание дополнительного слоя абстракции над таблицами базы данных.

Razbezhkin 31 авг 2007 в 06:49

Microsoft "говорит" что и для оптимизации производительности в своих официальных курсах.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий