Таблицы SQl Server: кучи или не кучи? - PullRequest
Новая
       19

Таблицы SQl Server: кучи или не кучи?

1 голос
/ 10 июня 2009

Я недавно заметил, что у нас есть несколько таблиц, хранящихся в кучах (без кластерного индекса). Будете ли вы создавать кластерные индексы на них выборочно, по всем направлениям или нет вообще? Любая другая мудрость или совет?

Есть несколько таблиц "кодов" с 25 или более строками. Однако есть несколько с более чем миллионными строками.

EDIT из «больших таблиц» все они уже имеют индексы, но не кластеризованные. некоторые из них являются журнальными таблицами, куда они просто вставляют, с небольшим чтением. Некоторые из них очень важны и в основном просто вставляются в приложение, а затем читаются приложением несколько раз.

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

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

В другом «типе» этих таблиц строки многократно вставляются в группы связанных строк, причем разные группы вставляются все время. на экране, полная группа должна быть возвращена. например, со временем эти группы строк вставляются (где группа может быть 5-50 строк): 

 1:00pm  A1, B1, C1,
 1:30pm  A2, B2, C2,
 2:00pm  A3, B3, C3, D1
 2:30pm  A4,     C4, D2
 3:00pm          C5, D3, E1
 3:30pm              D4, E2

экран должен отображать полный набор A: A1 + A2 + A3 + A4

EDIT Основываясь на ответе @gbn о упоминании о фрагментации, я использовал этот запрос из marc_s и нашел следующую информацию о фрагментации для таблиц кучи с миллионами строк, которые много раз читаются и используются экранами: 

TableName index_type alloc_unit_type index_depth index_level avg_fragmentation_in_percent fragment_count avg_fragment_size_in_pages page_count avg_page_space_used_in_percent record_count ghost_record_count Version_ghost_record_count min_record_size_in_bytes max_record_size_in_bytes avg_record_size_in_bytes forwarded_record_count
--------- ---------- --------------- ----------- ----------- ---------------------------- -------------- -------------------------- ---------- ------------------------------ ------------ ------------------ -------------------------- ------------------------ ------------------------ ------------------------ ----------------------
TABLE_A   HEAP       IN_ROW_DATA     1           0           95.8294717330862             2069           8.18511358144031           16935      98.2659995058068               1125786      3                  0                          80                       164                      117.671                  0
TABLE_A   HEAP       IN_ROW_DATA     1           0           95.8294717330862             2069           8.18511358144031           16935      98.2659995058068               1125786      3                  0                          80                       164                      117.671                  0
TABLE_A   HEAP       IN_ROW_DATA     1           0           95.8314034275127             2070           8.18212560386473           16937      98.2559303187546               1125793      11                 0                          80                       164                      117.672                  0
TABLE_B   HEAP       IN_ROW_DATA     1           0           99.2541594951233             1734           6.44982698961938           11184      94.5866567828021               1222729      0                  0                          68                       82                       68.037                   0
TABLE_B   HEAP       IN_ROW_DATA     1           0           99.2541594951233             1734           6.44982698961938           11184      94.5866567828021               1222729      0                  0                          68                       82                       68.037                   0
TABLE_B   HEAP       IN_ROW_DATA     1           0           99.197247706422              1735           6.44726224783862           11186      94.5725228564369               1222745      23                 0                          68                       82                       68.038                   0
TABLE_C   HEAP       IN_ROW_DATA     1           0           71.5785224061365             1777           10.9527293190771           19463      97.4122807017544               2237831      0                  0                          9                        84                       66.588                   2485
TABLE_C   HEAP       IN_ROW_DATA     1           0           71.5785224061365             1777           10.9527293190771           19463      97.4122807017544               2237831      0                  0                          9                        84                       66.588                   2485
TABLE_C   HEAP       IN_ROW_DATA     1           0           71.589991928975              1778           10.9476940382452           19465      97.4023844823326               2237832      0                  0                          9                        84                       66.588                   2485
TABLE_D   HEAP       IN_ROW_DATA     1           0           40.0769404842725             1773           19.7535250987028           35023      98.0193106004448               2778169      0                  0                          98                       112                      98.041                   0
TABLE_D   HEAP       IN_ROW_DATA     1           0           40.0904977375566             1774           19.7480270574972           35033      98.0175315048184               2778821      0                  0                          98                       112                      98.044                   0
TABLE_D   HEAP       IN_ROW_DATA     1           0           40.1040488577245             1775           19.7385915492958           35036      98.0142451198419               2778948      0                  0                          98                       112                      98.045                   0
TABLE_E   HEAP       IN_ROW_DATA     1           0           97.1619365609349             2911           8.11473720371007           23622      99.390066716086                3333693      0                  0                          55                       69                       55.017                   0
TABLE_E   HEAP       IN_ROW_DATA     1           0           97.1628838451268             2912           8.11332417582418           23626      99.3852359772671               3334016      0                  0                          55                       69                       55.018                   0
TABLE_E   HEAP       IN_ROW_DATA     1           0           97.1638304971638             2913           8.11122554067971           23628      99.3799357548802               3334100      0                  0                          55                       69                       55.018                   0
TABLE_F   HEAP       IN_ROW_DATA     1           0           21.9911471599199             8903           36.3093339323823           323262     94.6116753150482               4734053      44                 0                          521                      535                      521.046                  0
TABLE_F   HEAP       IN_ROW_DATA     1           0           21.9911471599199             8903           36.3093339323823           323262     94.6116876698789               4734053      50                 0                          521                      535                      521.046                  0
TABLE_F   HEAP       IN_ROW_DATA     1           0           21.9930761622156             8904           36.3057053009883           323266     94.6112428959723               4734079      78                 0                          521                      535                      521.047                  0
TABLE_G   HEAP       IN_ROW_DATA     1           0           66.1932151660993             5649           11.9943352805806           67756      96.7873733629849               6632610      0                  0                          78                       92                       78.047                   0
TABLE_G   HEAP       IN_ROW_DATA     1           0           66.1932151660993             5649           11.9943352805806           67756      96.7873733629849               6632610      0                  0                          78                       92                       78.047                   0
TABLE_G   HEAP       IN_ROW_DATA     1           0           66.1971830985916             5650           11.9925663716814           67758      96.7855572028663               6632648      11                 0                          78                       92                       78.048                   0
TABLE_H   HEAP       IN_ROW_DATA     1           0           11.5377268385864             5585           67.4340196956132           376619     92.3860637509266               6897347      0                  0                          9                        427                      406.418                  3
TABLE_H   HEAP       IN_ROW_DATA     1           0           11.5449915110357             5576           67.5530846484935           376676     92.3849023968372               6898289      0                  0                          9                        427                      406.419                  3
TABLE_H   HEAP       IN_ROW_DATA     1           0           11.5487458087518             5578           67.5313732520617           376690     92.3848035581913               6898534      0                  0                          9                        427                      406.42                   3
TABLE_I   HEAP       IN_ROW_DATA     1           0           96.7330677290837             9715           8.23201235203294           79974      96.3321225599209               3152049      0                  0                          76                       534                      195.879                  0
TABLE_I   HEAP       IN_ROW_DATA     1           0           96.7333930883378             9716           8.23157678056814           79978      96.3298122065728               3152142      0                  0                          76                       534                      195.879                  0
TABLE_I   HEAP       IN_ROW_DATA     1           0           96.7337183827923             9717           8.23114129875476           79982      96.3323696565357               3152420      0                  0                          76                       534                      195.876                  0
TABLE_J   HEAP       LOB_DATA        1           0           0                            NULL           NULL                       87553      95.5205090190264               7790594      0                  0                          84                       98                       84.91                    NULL
TABLE_J   HEAP       IN_ROW_DATA     1           0           31.2985438510012             23539          25.4966651089681           600166     96.4532863849765               7807684      0                  0                          435                      1213                     598.261                  0
TABLE_J   HEAP       IN_ROW_DATA     1           0           31.2994591137993             23540          25.4959218351742           600174     96.4530145787003               7807780      0                  0                          435                      1213                     598.26                   0
TABLE_J   HEAP       IN_ROW_DATA     1           0           31.3022047558782             23543          25.4936074417024           600196     96.4526068692859               7808096      0                  0                          435                      1213                     598.255                  0

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

Ответы [ 6 ]

5 голосов
/ 10 июня 2009

Похоже, что база данных была создана кем-то, кто знал, что он делал. Таблицы журналов и небольшие кодовые таблицы - именно то, где кучи имеют смысл.

Если нет текущих проблем с базой данных, я бы оставил все как есть!

3 голосов
/ 11 июня 2009

Всегда добавлять кластеризованный индекс. Без кластеризованного индекса вы не сможете быстро сжать или дефрагментировать таблицу. Без этого вы не сможете.

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

2 голосов
/ 11 июня 2009

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

0 голосов
/ 13 июня 2009

Одна проблема с кластеризованным индексом для больших таблиц состоит в том, что буферная память (ОЗУ), необходимая для хранения индекса, равна размеру таблицы. Там нет отдельного индекса. Некластеризованный индекс хранит только данные индекса, а затем первичный ключ таблицы или refid. Таким образом, нормальный индекс может в большей степени соответствовать размеру ОЗУ. Если вы выполняете поиск по кластерному индексу, а таблица велика, вы можете легко замедлить процесс. Если ваш кластеризованный индекс является частью даты, и все ваши поиски выполняются по последним датам, то, возможно, кластерный индекс не повлияет на производительность поиска, поскольку вы никогда не получаете доступ ко всем этим.

Я не согласен с постерами, утверждающими, что кластерный индекс уменьшит фрагментацию данных. Это увеличивает фрагментацию данных. На обычной таблице только удаление приводит к фрагментации. Когда вы добавляете строки в кластеризованную таблицу или изменяете поле кластеризованного индекса, SQL вынужден физически переупорядочивать таблицу. Это означает разбиение и добавление страниц данных, что увеличивает фрагментацию. Вот почему каждый рекомендует быть осторожным, чтобы выбрать поле для кластеризации, которое а) не меняется часто, если когда-либо, и б) всегда увеличивается.

Я считаю, что кластеризованный индекс полезен для больших таблиц, когда ваши запросы должны часто возвращать несколько «связанных» строк. Вы можете использовать кластер, чтобы связанные строки хранились последовательно и было проще для извлечения SQL. Не обязательно кластеризовать большую таблицу, чтобы у меня был новый индекс для поиска.

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

В конце концов, вам нужно вывести профилировщик и запустить несколько тестов.

Я правильно понял или что-то упустил?

0 голосов
/ 10 июня 2009

Зависит от того, как используются таблицы. Обычно я хочу кластеризованный индекс для таблицы с миллионами записей, но вы также должны рассмотреть, как эта таблица используется. Добавление индекса замедлит вставки, потому что он должен искать нужную страницу для каждой новой записи (и, возможно, вставить новую страницу), а не просто добавлять ее. Если эти заголовки в основном представляют собой «дампы» для данных и редко проверяются (например, аварийное ведение журнала), лучше оставить их в покое.

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

0 голосов
/ 10 июня 2009

Я хотел бы рассмотреть кластерный индекс для больших таблиц. Кластерный индекс определяет физический порядок хранения записей. Следствием этого является то, что строки в таблице могут храниться более эффективно, что уменьшает фрагментацию. Я уверен, что в таблице будет хотя бы один столбец, который мог бы стать кандидатом для размещения кластерного индекса. (А если нет, вы можете создать новый столбец, который содержит дату и время создания записи, и вы поместите кластерный индекс в этот столбец. Я думаю, что это все же лучше, чем вообще никакой CI).

Редактировать: если большие таблицы действительно являются журнальными таблицами, которые не читаются часто, их можно оставить в виде кучи.

...