Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Оптимизация  [new]
igor2222
Member

Откуда: Харків
Сообщений: 1233
Всем здравствуйте!
Есть достаточно простой вопрос для практиков.
Существует табличка table1, в которой порядка тысячи записей с разными Id.
Существует несколько подчиненных таблиц.
Для примера одна из них RefTable, в которой для каждого из Id первой таблицы может быть от 10 до 1 млн. записей.
В RefTable всего около 300 млн. строк и около 50 колонок.
В основном это int и varchar. Самая "тяжелая колонка" - varchar(4096).
Основной пул запросов - это
select чего-нибудь из RefTable a
inner join table1 b on (a.refId = b.id)
where b.name = @name

Ну есть правда и b.name in (....)
Собственно начались тормоза с недавнего времени.
RefTable имеет кластерный индекс, но по своему сквозному Id. На table1 пока только PK.
MSSQL пока на продакшене 2005-й Enterprise.
Вопрос- с чего бы начать? С организации RefTable по кластерному индексу table1?
Или сразу смотреть в сторону партишенов?
Естесственно наполнение будет расти и количество Id в table1 будет потихоньку увеличиваться.
6 дек 11, 12:40    [11712427]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация  [new]
tpg
Member

Откуда: Novosibirsk
Сообщений: 23902
igor2222
...Вопрос- с чего бы начать?...
Начать с обновления статистики и с анализа планов выполнения.
6 дек 11, 12:44    [11712468]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация  [new]
igor2222
Member

Откуда: Харків
Сообщений: 1233
Предположим статистика обновляется. А избирательность таблицы получается такова, что имеем INDEX SCAN практически всегда по refid. И эта операция занимает 90% времени. При том что в запросах прицеплена еще куча справочников.
6 дек 11, 13:02    [11712657]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация  [new]
Maxx
Member [скрыт]

Откуда:
Сообщений: 24290
ето у вас такая селективность индекса ? Скорее всего или или нет (индекса) или он совершено бестолковый
6 дек 11, 13:06    [11712683]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация  [new]
igor2222
Member

Откуда: Харків
Сообщений: 1233
Представьте себе ситуацию.
Есть таблица TableRef (id, refid, parameter1, parameter2... parameter50)
Мне нужно выполнить 50 запросов:
select id, parameter1
from TableRef
where refid in (1, 2, 3)
(запрос вернет от 100 до 10 млн. строк из 300 млн.)

select id, parameter2
from TableRef
where refid in (1, 2, 3)
...

select id, parameter50
from TableRef
where refid in (1, 2, 3)


Запросы практически равнозначны и выполняются хаотично в смысле refid и возвращаемых параметров.
Я знаю что всего этих refid порядка 1000.
Мне в данном случае создать 50 индексов и мягко говоря повлиять на время инсертов и апдейтов? Или универсально выбирать select * from TableRef ?
Или может всё таки попытаться организовать таблицу так, чтобы мой единственный индекс со сканом работал максимально быстро?
Да, статистика здесь важна, особенно когда таблица изменится процентов на 5-7... Я это понимаю. Но я сейчас о "более глобальном".
6 дек 11, 13:36    [11712926]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация  [new]
aleks2
Guest
igor2222
запрос вернет от 100 до 10 млн. строк из 300 млн.

1. Ну и что вы ожидаете? Чтот при запросе трети таблицы вам index seek стрясется?
Это еще тормознутее выйдет.

2. Надо медитировать на тему: нафега козе баян, а мне 100млн. строк?
6 дек 11, 15:04    [11713779]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация  [new]
ттттееее
Guest
Эх, как красиво тут бы лег битмап индекс!!!
Партицирование в общем по refId из глобальных решений.
6 дек 11, 16:02    [11714337]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация  [new]
PaulYoung
Member

Откуда: Москва
Сообщений: 2566
igor2222
В RefTable всего около 300 млн. строк и около 50 колонок.
В глобальном смысле - пересмотреть структуру БД, 50 колонок - это безобразие...
6 дек 11, 22:54    [11717645]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
А вы анализировали данные? (Что обязательно)
Как разделяются строки с малым количеством строк (в RefTable) от c большим. По типу, али ещё как?
Если так, то можно логически/физически разделить, например на две части.

Допустим по типу (Type) в таблице table1. А,Б,В - имеют много строк в RefTable.
Можно зафигачить в 2 разные таблы или засунуть в RefTable колоку тип (Type) и создать два индекса с WHERE.
А запрос написать на основе двух. Тогда будут использоваться обе стратегии (для большинства мелких SEEK).
7 дек 11, 04:23    [11718451]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация  [new]
quote автор]Мне
Guest
автор
Мне в данном случае создать 50 индексов

зачем?
igor2222
При том что в запросах прицеплена еще куча справочников.

так план выполнения есть или нет?

для разбирательства может проще статистику столбца привести?
7 дек 11, 10:09    [11719030]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация  [new]
netivan
Member

Откуда:
Сообщений: 8768
если scan table может в вашей тестовой таблице записей штук 10?
7 дек 11, 10:41    [11719250]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация  [new]
igor2222
Member

Откуда: Харків
Сообщений: 1233
Mnior,
я же написал, что индентифицируются только по RefID. В каком АйДи какое количество - не поддается анализу. В одной базе может быть, что у первого десятка 2/3 всех строк, у другой- может быть что у последнего. Мне нужно стратегическое решение. Вот интересное предложение с битмапами буду пробовать. Спасибо. В остальном - никак. К этой таблице обращаются сотни процедур, разбить ее, отделить колонки и прочее - неприменимо. Есть только три реальных решения пока что- патишены, организация по кластеру примари таблицы и битмапы.
7 дек 11, 13:24    [11720844]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация  [new]
igor2222
Member

Откуда: Харків
Сообщений: 1233
зачем?

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

План выполнения не зависит и не должен зависеть от того какие столбцы я выбираю. Статистику какого столбца показать и в какой из баз? Я же написал - 1000 вариантов от 10 до 1 млн. строк.
7 дек 11, 13:29    [11720920]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация  [new]
igor2222
Member

Откуда: Харків
Сообщений: 1233
netivan
если scan table может в вашей тестовой таблице записей штук 10?

Где я написал про scan table ?
7 дек 11, 13:30    [11720927]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация  [new]
igor2222
Member

Откуда: Харків
Сообщений: 1233
Всё, всем спасибо! Будем заканчивать этот флуд. Я понял, что тут можно решить только экспериментально на основе анализа плана и времени выполнения. Возможно что в разных базах прийдется делать по разному.
Всё остальное исключительно индивидуально и решения типа ораклового: "Partitions and subpartitions - the best of the best" тут неприменимо.
7 дек 11, 13:33    [11720964]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация  [new]
вэлком эгейн
Guest
igor2222
Всё, всем спасибо! Будем заканчивать этот флуд.

чо приходил-то? ))

статистика про 2/3 записей на один ID - ну скан, только скан, ничего кроме скана.
партишн - можно да. очень вероятно что для партишна гораздо больше подойдет какой-то другой столбец.
тут семантика запросов, бизнес-смысл этих таблиц важны. "фильтр по id"? ну бей по ID.
50 колонок, в т.ч. varchar(4096) - высока вероятность того что работать мешает хлам, который в этой таблице даром не нужен.
одна запись на страницу - нормально вобще?

План выполнения не зависит и не должен зависеть от того какие столбцы я выбираю.

количество и порядок объединений, присутствие полей в индексах, а также джойн-хинты и option'ы - тоже не имеют никакого права влиять на план выполнения.
ага.
7 дек 11, 21:04    [11725247]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
вэлком эгейн
статистика про 2/3 записей на один ID - ну скан, только скан, ничего кроме скана.
партишн - можно да. очень вероятно что для партишна гораздо больше подойдет какой-то другой столбец.
тут семантика запросов, бизнес-смысл этих таблиц важны. "фильтр по id"? ну бей по ID.
50 колонок, в т.ч. varchar(4096) - высока вероятность того что работать мешает хлам, который в этой таблице даром не нужен.
одна запись на страницу - нормально вобще?
Оно правда. Но суть то в другом. Тут сразу две вещи подкачали.
Вера в модную вещь - универсальных монстров (© iap) и лучше хорошее сейчас, чем лучшее завтра, а там поправим.
В итоге монстр загнал в проблему, решить которую можно, но нет сил. И монстр растёт дальше.

А далее эген анд эген, только ники разные ...
8 дек 11, 00:23    [11726031]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить