|
|
|
Оптимизация индексов регистра бухгалтерии в 1С
|
|||
|---|---|---|---|
|
#18+
В этой ветке Почему никто не спроектирует ИС, тесно взаимодействующую с 1С? Я немного рассказал о своей оптимизации индексов для регистра бухгалтерии 1С 8.1 Выкладываю скрипты создания таблиц и индексов: Create Tables.sql - создание таблиц Create Indexes Old.sql - индексы, созданные 1С Create Indexes New.sql - мои индексы ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.01.2008, 10:33 |
|
||
|
Оптимизация индексов регистра бухгалтерии в 1С
|
|||
|---|---|---|---|
|
#18+
Вложение не прицепилось ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.01.2008, 10:33 |
|
||
|
Оптимизация индексов регистра бухгалтерии в 1С
|
|||
|---|---|---|---|
|
#18+
vogenut iscrafm vogenut Тынц это ваши домыслы? или вы убирали могучий кластерный индекс из регистра накопления и возникали сразу проблемы с проведением документов? Нет, не домыслы. Что-бы понять в чем суть, ответьте себе на вопрос, что будет, если вообще индекс убрать из данной таблицы? Прошу прощения, отвечу на вопрос из соседней ветки, модератор закрыл ее на полуслове. vogenut , будет таблица без индексов . Надеюсь правильно ответил на ваш вопрос. Но на будушее, лучше, вникайте немного в суть обсуждаемого. Речь идет об отказе от кластерного индекса, включающего в себя десяток REF...-ов и замене его на индекс другой конструкции, допустим такой как предложил RMih . p.s. Если вам требуется уточнение вопроса, то скажите об этом прямо, не стесняйтесь. Если не требуется, то каким образом вынесение ref.. за скобки кластерного индекса и включение их в обычный приводит к проблемам с проведением документов? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.01.2008, 11:41 |
|
||
|
Оптимизация индексов регистра бухгалтерии в 1С
|
|||
|---|---|---|---|
|
#18+
>скобки кластерного индекса и включение их в обычный кластерный индекс входит во все обычные Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.01.2008, 11:58 |
|
||
|
Оптимизация индексов регистра бухгалтерии в 1С
|
|||
|---|---|---|---|
|
#18+
ScareCrow >скобки кластерного индекса и включение их в обычный кластерный индекс входит во все обычные Posted via ActualForum NNTP Server 1.4 астральные мысли я не понимаю, к сожалению. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.01.2008, 12:00 |
|
||
|
Оптимизация индексов регистра бухгалтерии в 1С
|
|||
|---|---|---|---|
|
#18+
а, простите предмет разговора (сиреч кластерные индексы) вы вообще знаете? Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.01.2008, 12:16 |
|
||
|
Оптимизация индексов регистра бухгалтерии в 1С
|
|||
|---|---|---|---|
|
#18+
ScareCrow а, простите предмет разговора (сиреч кластерные индексы) вы вообще знаете? Posted via ActualForum NNTP Server 1.4 Вам занятся нечем? Если нечем, то ответьте хотя-бы на вопросы из соседней ветки, в которой вы выступили невпопад. Если если есть чем заняться - займитесь делом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.01.2008, 12:22 |
|
||
|
Оптимизация индексов регистра бухгалтерии в 1С
|
|||
|---|---|---|---|
|
#18+
iscrafmРечь идет об отказе от кластерного индекса, включающего в себя десяток REF...-ов и замене его на индекс другой конструкции, допустим такой как предложил RMih . p.s. Если вам требуется уточнение вопроса, то скажите об этом прямо, не стесняйтесь. Если не требуется, то каким образом вынесение ref.. за скобки кластерного индекса и включение их в обычный приводит к проблемам с проведением документов?Замечательно, с количеством индексов разобрались. Значит предлагаете один кластерный по _Period и один некластерный по измерениям. В этом случае ситуация конечно лучше, но: при обращении к этой таблице должен будет использоваться вариант Index Seek + Clustered Key Lookup, в лучшем случае. Давайте посмотрим, чем это будет отличаться от оригинального индекса: 1. Во первых, конечно нет гарантии что SQL Server выберет такой план запроса. На маленьких таблицах или при относительно большой выборке может получиться Clustered Index Scan. Последствия, я думаю, вы понимаете (замечу, что к регистрам доступ идет с уровнем serializable при записи/проведении документов). 2. Стоимость Index Seek + Clustered Key Lookup гораздо выше чем у Clustered Index Seek. Даже выше чем у Bookmark Search, потому как во втором случае мы имеем в индексе RID и можем сразу перейти к данным, а так нам надо еще прыгать по кластерному индексу, что-бы до них добраться. 3. При выполнении Index Seek + Clustered Key Lookup накладываются дополнительные блокировки, в частности Range блокировки (например, при обновлении). 4. Исходя из пункта 3 некоторые записи, логически не связанные с обновляемыми будут заблокированны. Это приведет к лишним блокировкам и ожиданиям при проведении параллельных документов. 5. Опять же из пункта 3 следует, что момент эскалации блокировок будет наступать чаще. Отсюда, опять же лишние блокировки записей. 6. SQL Server 2000, насколько мне известно, работает хуже при выполнении/анализе плана запроса для случая Index Seek + Clustered Key Lookup, нежели SQL Server 2005. Это тоже надо знать. 7. Может я еще что пропустил... И конечно, по данной теме лучше разговаривать в другой ветке, например по SQL Server. Там выше вероятность получить грамотный совет :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2008, 01:31 |
|
||
|
Оптимизация индексов регистра бухгалтерии в 1С
|
|||
|---|---|---|---|
|
#18+
vogenut у вас план запроса показывает сканирование индекса или поиск по индексу? Как насчет дидлоков ситуация? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2008, 10:50 |
|
||
|
Оптимизация индексов регистра бухгалтерии в 1С
|
|||
|---|---|---|---|
|
#18+
To vogenut А теперь, как было в реальности, а не "теоретически". При индексах созданных 1С и запросах не по одному значению, а по списку, выполнялся Clustered Index Scan в 2-х таблицах, одна 50 миллионов строк, другая 200 миллионов строк. Видимо из-за большого размера индексов SQL Server считал неэффективным их использование. После удаления индексов 1С и создания моих, SQL стал использовать Index Seek и Bookmark Lookup. Т.е. читать не всю таблицу, а примерно то, что надо, не на много больше. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2008, 11:01 |
|
||
|
Оптимизация индексов регистра бухгалтерии в 1С
|
|||
|---|---|---|---|
|
#18+
И еще, общий размер индексов для таблиц проводок (50 млн. строк) и субконто проводок (200 млн. строк) уменьшился примерно в 2 раза, а скорость запросов, как я уже говорил, возросла больше чем в 20 раз. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2008, 11:05 |
|
||
|
Оптимизация индексов регистра бухгалтерии в 1С
|
|||
|---|---|---|---|
|
#18+
iscrafm vogenut у вас план запроса показывает сканирование индекса или поиск по индексу? Как насчет дидлоков ситуация?Когда как, зависит от "размера" таблицы. Если маленькая - сваливается в скан. С дидлоками тьфу-тьфу, проблем не было. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2008, 11:06 |
|
||
|
Оптимизация индексов регистра бухгалтерии в 1С
|
|||
|---|---|---|---|
|
#18+
RMihИ еще, общий размер индексов для таблиц проводок (50 млн. строк) и субконто проводок (200 млн. строк) уменьшился примерно в 2 раза, а скорость запросов, как я уже говорил, возросла больше чем в 20 раз.Я так понимаю, вы про бухгалтерский регистр говорите? Может в вашем случае это лучше, не знаю. Мы же пока вашу первую инновацию разбираем, про регистр накопления :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2008, 11:09 |
|
||
|
Оптимизация индексов регистра бухгалтерии в 1С
|
|||
|---|---|---|---|
|
#18+
С регистром накопления на практике не экспериментировал, но думаю, там будет то же самое. Основная мысль: индексы должны быть маленькими, особенно кластерный. Большие индексы не используются, т.к. SQL считает это неэффективным ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2008, 11:21 |
|
||
|
Оптимизация индексов регистра бухгалтерии в 1С
|
|||
|---|---|---|---|
|
#18+
RMihС регистром накопления на практике не экспериментировал, но думаю, там будет то же самое. Основная мысль: индексы должны быть маленькими, особенно кластерный. Большие индексы не используются, т.к. SQL считает это неэффективнымДык ваша комбинация маленький кластерный плюс все остальное в обычном на самом деле будет больше страниц занимать, чем кластерный по всем полям. Приблизительно в два раза. А еще bookmark search... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2008, 11:25 |
|
||
|
Оптимизация индексов регистра бухгалтерии в 1С
|
|||
|---|---|---|---|
|
#18+
Конечно больше, вот только если кроме кластерного по всем полям в таблице создать еще один любой индекс, то он будет гораздо больше занимать, в 2 раза. У меня и в обычном индексе не "все остальное", а только 1 нужное поле. Другие поля 1С пихает в индекс для уникальности, наверное разработчики 1С переоценивают значимость уникальных индексов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2008, 11:29 |
|
||
|
Оптимизация индексов регистра бухгалтерии в 1С
|
|||
|---|---|---|---|
|
#18+
RMihКонечно больше, вот только если кроме кластерного по всем полям в таблице создать еще один любой индекс, то он будет гораздо больше занимать, в 2 раза. У меня и в обычном индексе не "все остальное", а только 1 нужное поле. Другие поля 1С пихает в индекс для уникальности, наверное разработчики 1С переоценивают значимость уникальных индексов.Если в индексе присутствуют поля кластерного индекса, то они-же используются как clustered key в записи индекса. А у 1С доп индексы на этой таблице (итоги регистра накопления) и так включают поля из кластерного. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2008, 11:36 |
|
||
|
Оптимизация индексов регистра бухгалтерии в 1С
|
|||
|---|---|---|---|
|
#18+
Пример Структура таблиц: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. Индексы 1С Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. Предлагаемые мной индексы Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. Угадайте, какие индексы будут меньше? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2008, 12:14 |
|
||
|
Оптимизация индексов регистра бухгалтерии в 1С
|
|||
|---|---|---|---|
|
#18+
ТЕСТ выполнялся на базе 1.7 Gb (меньше ждать) на запросе СальдоИОбороты за периол по счету (и все): Если предлагаемые индексы добавить в таблицы БухРег, то разницы по времени нет (как будто план запроса не изменился). Если предлагаемые индексы вставить единственными в таблицы БухРег, то время выполнения запроса увеличится в 4 раза. ВОТ ТАК!!! Очень жаль, что это не помагает. Т.к. 1С 8.x просто достала своими тормозами. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2009, 16:02 |
|
||
|
|

start [/forum/topic.php?fid=29&msg=35096523&tid=1526726]: |
0ms |
get settings: |
11ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
67ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
63ms |
get tp. blocked users: |
2ms |
| others: | 233ms |
| total: | 412ms |

| 0 / 0 |

Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
... ля, ля, ля ...