Partitioned Views

14.09.2008, 15:56. **Показов** 1533. **Ответов** 9

Студворк — интернет-сервис помощи студентам

Подскажите,

сложилась такая ситуация: решил сделать Partitioned View. Была у меня таблица, около 3,5 млн. записей. Разбил я ее на 12 таблиц по 12-ти месяцам, т.е., в колонке date каждой из таблиц стоит constraint check (month(<DATE_COLUMN>) = 3, или 4, или др. месяц). Таблицы объединил во view при помощи UNION ALL, получив аналог исходной таблицы.

Ожидаю, что выборка из view типа select * from <view> where month(<col>) = 3 будет значительно быстрее, чем select * from <table> where month(<col>) = 3. На деле получается наоборот (включаю SET STATISTICS TIME). Хотя времени CPU на выборку из VIEW затрачивается немного меньше, чем в случае с таблицей. Но всё равно, общее время выполнения запроса больше в случае с view. Кэширование не при чём - выполнял запросы в разных вариантах, сначала таблица, потом view, наоборот, ставил разные месяцы во view и таблице, и т.д..
Выходит, SQL SERVER не понял, что это Partitioned View? В чём может быть дело?

@Alex Lee · 14.09.2008, 16:55

А что в экзекьюшн плане ?

14.09.2008, 17:08

Слушай, lex, какой же я болван - как же я сразу туда не посмотрел. Смогу посмотреть лишь вечером, тогда сразу отвечу!

@Glory · 14.09.2008, 17:18

http://www.osp.ru/win2000/sql/2000/04/404.htm

@Alex Lee · 14.09.2008, 17:31

2 Delta

Почитай ссылку Glory. Glory плохого не посоветует

14.09.2008, 17:54

lex,

Glory действительно посоветовал то, что надо. Glory, спасибо! Если будут вопросы, я обязательно напишу. Внимательно изучу скрипт вечером, но на первый взгляд это то, что надо.

Тебе lex то же спасибо за внимание.

Сколько мне еще предстоит научиться, диву даешься. Иногда таким пнём себя чувствуешь... А я ещё гордился, что я MCP...

@Glory · 15.09.2008, 12:28

На всякий случай раскажу еще о некоторых особенностях partitioned view-ов

1. При использовании в запросе в качестве фильтра переменной сервер будет использовать в плане выполнения ВСЕ таблицы view-а. Т.е. при
declare @mymonth char(2)
set @mymonth = '03'
... WHERE mymonth = @mymonth
будут сканироваться все таблицы. Выигрыш правда будет за счет того, что т.к. фактически условию фильтра будут удовлетворять только записи одной таблицы, то 'результатом' view-а будут только эти записи.

2. После добавления записей в какую-либо таблицу view-а эта таблица начинает использоваться в запросах ко view-у. Но опять же т.к. там нет записей, удовлетворяющих фильтру, то на конечное число записей view-а это не влияет, но время выполнения конечно не уменьшает
'Лечится' это путем пересоздания CHECK constraint-а с обязательным указанием опции WITH CHECK

15.09.2008, 12:43

Glory, бери меня на работу

.
Рядом с тобой может и сам чему научусь.

Теперь к постингу: showplan_text показал, что в случае с неpartitioned view осуществляется table scan всех таблиц с условием where. Если view partitioned, то сканируются то же все таблицы, но к каждой применяется фильтр, как ты и написал в 1. Непонятно, в чем же выйгрыш? Все равно производится table scan всех таблиц.

Не совсем понял пункт 2. твоего постинга. Какую проблему ты описал?

@Glory · 15.09.2008, 13:34

1. Выигрыш будет на мультипроцессорной машине за счет параллельной обработки. Если конечно оптимизатор выберет такой план выполнения.
На данный момент можно обойти использование переменных только через динамический запрос.

2. При bulk insert-ах (через команду BULK INSERT или DTS) сервер может не проверять constraint-ы для добавляемых данных. В этом случае где-то в системе сохраняется информация об этом и оптимизатор выбирает сканирование не одной таблицы, а нескольких (для которых происходило добавление данных и нет 'уверенности', что реальные данные соответсвуют constraint-ам). Исправляется это удалением и добавлением заново CHECK constraint-а.

16.09.2008, 13:53

Мужики, получилось!

Я честно такого результата не ожидал.

Конечно, я создал самые комфортные условия для Part. View. Т.е., воткнул в таблицу (примерно 3,7 млн. записей) столбец identity, а потом разбил её на 12 таблиц, примерно 300 тыс. записей в каждой, на каждой check constraint (column between 1 and 300000), (column between 300001 and 600000) и т.д.. Затем убедился в showplan_text, что используется Part. View. Сервер у меня полностью разгружен, т.е., дома комп с установленным на нём SQL Server 2000, на нём я готовлюсь к 70-229.

Затем включаю STATISTICS TIME. Результат превзошёл все ожидания: даже при втором и третьем запуске запроса на выборку (когда таблица уже в buffer cash) выборка из таблицы раза в 3 (а то и больше) медленне, чем из View. А когда таблица запускалась в первый раз, так разница в выполнении была 26-ти или 36-кратная!

Ну, спасибо всем! СПАСИБО! Еще конечно буду обращаться. Вот уже пишу следующий постинг с вопросом по индексированному view.

Новые блоги и статьи Все статьи Все блоги /
SDL3 для Web (WebAssembly): Реализация движения на Box2D v3 - трение и коллизии с повёрнутыми стенами 8Observer8 20.02.2026 Содержание блога Box2D позволяет легко создать главного героя, который не проходит сквозь стены и перемещается с заданным трением о препятствия, которые можно располагать под углом, как верхнее. . .	Конвертировать закладки radiotray-ng в m3u-плейлист damix 19.02.2026 Это можно сделать скриптом для PowerShell. Использование . \СonvertRadiotrayToM3U. ps1 <path_to_bookmarks. json> Рядом с файлом bookmarks. json появится файл bookmarks. m3u с результатом. # Check if. . .	Семь CDC на одном интерфейсе: 5 U[S]ARTов, 1 CAN и 1 SSI Eddy_Em 18.02.2026 Постепенно допиливаю свою "многоинтерфейсную плату". Выглядит вот так: https:/ / www. cyberforum. ru/ blog_attachment. php?attachmentid=11617&stc=1&d=1771445347 Основана на STM32F303RBT6. На борту пять. . .	Камера Toupcam IUA500KMA Eddy_Em 12.02.2026 Т. к. у всяких "хикроботов" слишком уж мелкий пиксель, для подсмотра в ESPriF они вообще плохо годятся: уже 14 величину можно рассмотреть еле-еле лишь на экспозициях под 3 секунды (а то и больше),. . .
И ясному Солнцу zbw 12.02.2026 И ясному Солнцу, и светлой Луне. В мире покоя нет и люди не могут жить в тишине. А жить им немного лет.	«Знание-Сила» zbw 12.02.2026 «Знание-Сила» «Время-Деньги» «Деньги -Пуля»	SDL3 для Web (WebAssembly): Подключение Box2D v3, физика и отрисовка коллайдеров 8Observer8 12.02.2026 Содержание блога Box2D - это библиотека для 2D физики для анимаций и игр. С её помощью можно определять были ли коллизии между конкретными объектами и вызывать обработчики событий столкновения. . . .	SDL3 для Web (WebAssembly): Загрузка PNG с прозрачным фоном с помощью SDL_LoadPNG (без SDL3_image) 8Observer8 11.02.2026 Содержание блога Библиотека SDL3 содержит встроенные инструменты для базовой работы с изображениями - без использования библиотеки SDL3_image. Пошагово создадим проект для загрузки изображения. . .

Delta

	Partitioned Views 14.09.2008, 15:56. Показов 1533. Ответов 9 Метки нет (Все метки) Подскажите, сложилась такая ситуация: решил сделать Partitioned View. Была у меня таблица, около 3,5 млн. записей. Разбил я ее на 12 таблиц по 12-ти месяцам, т.е., в колонке date каждой из таблиц стоит constraint check (month(<DATE_COLUMN>) = 3, или 4, или др. месяц). Таблицы объединил во view при помощи UNION ALL, получив аналог исходной таблицы. Ожидаю, что выборка из view типа select * from <view> where month(<col>) = 3 будет значительно быстрее, чем select * from <table> where month(<col>) = 3. На деле получается наоборот (включаю SET STATISTICS TIME). Хотя времени CPU на выборку из VIEW затрачивается немного меньше, чем в случае с таблицей. Но всё равно, общее время выполнения запроса больше в случае с view. Кэширование не при чём - выполнял запросы в разных вариантах, сначала таблица, потом view, наоборот, ставил разные месяцы во view и таблице, и т.д.. Выходит, SQL SERVER не понял, что это Partitioned View? В чём может быть дело?

@Alex Lee 0 / 0 / 0 Регистрация: 24.03.2008 Сообщений: 90
	14.09.2008, 16:55
	А что в экзекьюшн плане ? 0

Delta
	14.09.2008, 17:08
	Слушай, lex, какой же я болван - как же я сразу туда не посмотрел. Смогу посмотреть лишь вечером, тогда сразу отвечу!

@Glory 5 / 5 / 0 Регистрация: 20.02.2008 Сообщений: 141
	14.09.2008, 17:18
	http://www.osp.ru/win2000/sql/2000/04/404.htm 0

@Alex Lee 0 / 0 / 0 Регистрация: 24.03.2008 Сообщений: 90
	14.09.2008, 17:31
	2 Delta Почитай ссылку Glory. Glory плохого не посоветует 0

Delta
	14.09.2008, 17:54
	lex, Glory действительно посоветовал то, что надо. Glory, спасибо! Если будут вопросы, я обязательно напишу. Внимательно изучу скрипт вечером, но на первый взгляд это то, что надо. Тебе lex то же спасибо за внимание. Сколько мне еще предстоит научиться, диву даешься. Иногда таким пнём себя чувствуешь... А я ещё гордился, что я MCP...

@Glory 5 / 5 / 0 Регистрация: 20.02.2008 Сообщений: 141
	15.09.2008, 12:28
	На всякий случай раскажу еще о некоторых особенностях partitioned view-ов 1. При использовании в запросе в качестве фильтра переменной сервер будет использовать в плане выполнения ВСЕ таблицы view-а. Т.е. при declare @mymonth char(2) set @mymonth = '03' ... WHERE mymonth = @mymonth будут сканироваться все таблицы. Выигрыш правда будет за счет того, что т.к. фактически условию фильтра будут удовлетворять только записи одной таблицы, то 'результатом' view-а будут только эти записи. 2. После добавления записей в какую-либо таблицу view-а эта таблица начинает использоваться в запросах ко view-у. Но опять же т.к. там нет записей, удовлетворяющих фильтру, то на конечное число записей view-а это не влияет, но время выполнения конечно не уменьшает 'Лечится' это путем пересоздания CHECK constraint-а с обязательным указанием опции WITH CHECK 0

Delta
	15.09.2008, 12:43
	Glory, бери меня на работу . Рядом с тобой может и сам чему научусь. Теперь к постингу: showplan_text показал, что в случае с неpartitioned view осуществляется table scan всех таблиц с условием where. Если view partitioned, то сканируются то же все таблицы, но к каждой применяется фильтр, как ты и написал в 1. Непонятно, в чем же выйгрыш? Все равно производится table scan всех таблиц. Не совсем понял пункт 2. твоего постинга. Какую проблему ты описал?

@Glory 5 / 5 / 0 Регистрация: 20.02.2008 Сообщений: 141
	15.09.2008, 13:34
	1. Выигрыш будет на мультипроцессорной машине за счет параллельной обработки. Если конечно оптимизатор выберет такой план выполнения. На данный момент можно обойти использование переменных только через динамический запрос. 2. При bulk insert-ах (через команду BULK INSERT или DTS) сервер может не проверять constraint-ы для добавляемых данных. В этом случае где-то в системе сохраняется информация об этом и оптимизатор выбирает сканирование не одной таблицы, а нескольких (для которых происходило добавление данных и нет 'уверенности', что реальные данные соответсвуют constraint-ам). Исправляется это удалением и добавлением заново CHECK constraint-а. 0

Delta
	16.09.2008, 13:53
	Мужики, получилось! Я честно такого результата не ожидал. Конечно, я создал самые комфортные условия для Part. View. Т.е., воткнул в таблицу (примерно 3,7 млн. записей) столбец identity, а потом разбил её на 12 таблиц, примерно 300 тыс. записей в каждой, на каждой check constraint (column between 1 and 300000), (column between 300001 and 600000) и т.д.. Затем убедился в showplan_text, что используется Part. View. Сервер у меня полностью разгружен, т.е., дома комп с установленным на нём SQL Server 2000, на нём я готовлюсь к 70-229. Затем включаю STATISTICS TIME. Результат превзошёл все ожидания: даже при втором и третьем запуске запроса на выборку (когда таблица уже в buffer cash) выборка из таблицы раза в 3 (а то и больше) медленне, чем из View. А когда таблица запускалась в первый раз, так разница в выполнении была 26-ти или 36-кратная! Ну, спасибо всем! СПАСИБО! Еще конечно буду обращаться. Вот уже пишу следующий постинг с вопросом по индексированному view.