|
|
|
Странный выбор индекса
|
|||
|---|---|---|---|
|
#18+
Добрый день! Есть таблица: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. и запрос: Код: sql 1. 2. 3. 4. 5. 6. При построении плана выполнения запроса используется просмотр индекса IX_RashodL_CurDate_usID. Почему не используется поиск по кластерному главному ключу? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.02.2018, 13:13:11 |
|
||
|
Странный выбор индекса
|
|||
|---|---|---|---|
|
#18+
добавьте хинтом в запрос использование кластерного как вы хотите и посмотрите какие будут на нём оценки по IO и CPU и сравните с оценками для не кластерного который сервер выбирает. где меньше? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.02.2018, 13:46:24 |
|
||
|
Странный выбор индекса
|
|||
|---|---|---|---|
|
#18+
saszay , У вас таблица RashodL_CurDate маленькая и оптимизатор выбирает предпочтительнее сканирование, либо у вас устаревшая на ней статистика. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.02.2018, 13:51:47 |
|
||
|
Странный выбор индекса
|
|||
|---|---|---|---|
|
#18+
Да, таблица маленькая. Не больше 100 записей ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.02.2018, 14:40:16 |
|
||
|
Странный выбор индекса
|
|||
|---|---|---|---|
|
#18+
от таблицы RashodL_CurDate нужно только поле ralID, так зачем лезть в кластерный, в котором все поля, если есть IX_RashodL_CurDate_usID, в котором тоже есть ralID (это ключ кластерного), и полей меньше, всего 2: usID + ralID по этому полю никакой не поиск, просто соединение. его упорядоченность не нужна. банально выбирается минимальный индекс, содержащий это поле ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2018, 11:44:56 |
|
||
|
|

start [/forum/topic.php?fid=46&msg=39607278&tid=1690211]: |
0ms |
get settings: |
7ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
189ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
30ms |
get tp. blocked users: |
1ms |
| others: | 234ms |
| total: | 490ms |

| 0 / 0 |
