|
Странное поведение сервера при попытке оптимизации
|
|||
---|---|---|---|
#18+
Резюме такое - совсем без индекса работает менее чем за 2 минуты на более слабом сервере, чем с кластерным на мощном сервере (9 минут). Замеры из одной студии, с одного сетевого соединения. msLex - оказался прав! Респект и уважуха. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.02.2020, 17:09 |
|
Странное поведение сервера при попытке оптимизации
|
|||
---|---|---|---|
#18+
SQL2008, обычно наоборот - просмотр кластерного выгоднее адресации через IAM. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.02.2020, 17:22 |
|
Странное поведение сервера при попытке оптимизации
|
|||
---|---|---|---|
#18+
SQL2008 совсем без индекса работает менее чем за 2 минуты на более слабом сервере, чем с кластерным на мощном сервере (9 минут). совершенно бессмысленно сравнивать скорость выполнения запросов на двух разных серверах под разной нагрузкой даже на одном сервере без посторонней нагрузки это проблематично из-за "кеширования" данных ... |
|||
:
Нравится:
Не нравится:
|
|||
12.02.2020, 17:24 |
|
Странное поведение сервера при попытке оптимизации
|
|||
---|---|---|---|
#18+
msLex пропущено... а с чего вы вязли, что так будет лучше? А почему кластерный индекс, он же PK, может быть хуже чем его отсутствие? Плохо продумали кластерный индекс, в таблице было много вставок и удалений, он стал разреженным. Это привело к тому что количество операций чтения из медленной памяти увеличилось пропорционально тому, насколько разрежен индекс. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.02.2020, 19:53 |
|
Странное поведение сервера при попытке оптимизации
|
|||
---|---|---|---|
#18+
msLex SQL2008 совсем без индекса работает менее чем за 2 минуты на более слабом сервере, чем с кластерным на мощном сервере (9 минут). совершенно бессмысленно сравнивать скорость выполнения запросов на двух разных серверах под разной нагрузкой даже на одном сервере без посторонней нагрузки это проблематично из-за "кеширования" данных Полностью согласен. + ещё если делать без понимания, то можно криво сделать кластерный индекс и он не будет давать прироста в производительности. Например, сделали кластерный индекс по нескольким полям, а первый столбце кластеризованного индекса в запросе не указали или указали криво - считайте, что никакого индекса в этом случае у вас нет. Есть ещё одна частая ошибка при работе с индексами. Например, индекс по полю "День_рождения" типа datetime, а в запросе сделали так: YEAR(День_рождения) - в этом случае индекс тоже не будет использоваться (практически во всех случаях применение функции поверх поля с индексом убирает использование индекса в плане запроса. Есть конечно исключения, но о них долго рассказывать). ... |
|||
:
Нравится:
Не нравится:
|
|||
12.02.2020, 20:00 |
|
Странное поведение сервера при попытке оптимизации
|
|||
---|---|---|---|
#18+
Александр Бердышев Плохо продумали кластерный индекс, в таблице было много вставок и удалений, он стал разреженным. После установки индекса ничего не добавлялось, не удалялось, не обновлялось. Дефрагментация индекса была сотые доли процента. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.02.2020, 22:37 |
|
Странное поведение сервера при попытке оптимизации
|
|||
---|---|---|---|
#18+
Факт остается фактом - индекс только мешал, без него запрос выполняется в три раза быстрее. 3 минуты вместо 9-ти ... |
|||
:
Нравится:
Не нравится:
|
|||
12.02.2020, 22:46 |
|
Странное поведение сервера при попытке оптимизации
|
|||
---|---|---|---|
#18+
SQL2008, Все может быть еще проще. У Вас сложный запрос (15+ таблиц). Сервер просто не успевает найти хороший план. И Вы ему еще параметров подкинули в виде индексов. Попробуйте запустить ваш запрос без ограничения по времени формирования плана и посмотрите, что получится. Ну и если будет гораздо лучший результат, тут уже дело магии это зафиксировать :). ... |
|||
:
Нравится:
Не нравится:
|
|||
12.02.2020, 23:33 |
|
Странное поведение сервера при попытке оптимизации
|
|||
---|---|---|---|
#18+
Idol_111 Попробуйте запустить ваш запрос без ограничения по времени формирования плана и посмотрите, что получится. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.02.2020, 02:40 |
|
Странное поведение сервера при попытке оптимизации
|
|||
---|---|---|---|
#18+
Ennor Tiegael Idol_111 Попробуйте запустить ваш запрос без ограничения по времени формирования плана и посмотрите, что получится. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.02.2020, 08:44 |
|
Странное поведение сервера при попытке оптимизации
|
|||
---|---|---|---|
#18+
SQL2008 Есть сервер, достаточно мощный - 16 ядер, 192 памяти. Не пробовали Columnstore? Тупо на все большое. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.02.2020, 09:34 |
|
Странное поведение сервера при попытке оптимизации
|
|||
---|---|---|---|
#18+
a_voronin SQL2008 Есть сервер, достаточно мощный - 16 ядер, 192 памяти. Не пробовали Columnstore? Тупо на все большое. Columnstore хорош для массовых запросов на чтение и appendonly изменения данных. Если это классическая OLTP с update-ми, delete-ми и select-ми по ключам, то почти наверняка Columnstore сделает только хуже. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.02.2020, 09:51 |
|
Странное поведение сервера при попытке оптимизации
|
|||
---|---|---|---|
#18+
Убрал вообще все индексы, запустил план выполнения, создал (по рекомендации оптимизатора) покрывающий индекс на все (даже на время модификации записи, что меня немного смутило!) и время выполнения еще уменьшилось до полутора минут. В общем не всегда то, что кажется (кластерный индекс) хорошо в реальности. Всем спасибо за горячее участие и помощь! ... |
|||
:
Нравится:
Не нравится:
|
|||
13.02.2020, 10:28 |
|
Странное поведение сервера при попытке оптимизации
|
|||
---|---|---|---|
#18+
msLex Если это классическая OLTP с update-ми, delete-ми и select-ми по ключам, то почти наверняка Columnstore сделает только хуже. Нет. Это буферные таблицы, в которые данные заливаются одноразово и потом используются для построения отчетов. На них можно вешать какие угодно индексы и сколько угодно. Оперативной работы с данными нет. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.02.2020, 10:31 |
|
Странное поведение сервера при попытке оптимизации
|
|||
---|---|---|---|
#18+
SQL2008 msLex Если это классическая OLTP с update-ми, delete-ми и select-ми по ключам, то почти наверняка Columnstore сделает только хуже. Нет. Это буферные таблицы, в которые данные заливаются одноразово и потом используются для построения отчетов. На них можно вешать какие угодно индексы и сколько угодно. Оперативной работы с данными нет. В этом случае CS может быть эффективен. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.02.2020, 11:18 |
|
|
start [/forum/topic.php?fid=46&gotonew=1&tid=1686499]: |
0ms |
get settings: |
12ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
39ms |
get topic data: |
14ms |
get first new msg: |
9ms |
get forum data: |
3ms |
get page messages: |
56ms |
get tp. blocked users: |
1ms |
others: | 343ms |
total: | 499ms |
0 / 0 |