|
|
|
Ну почему не работает индех
|
|||
|---|---|---|---|
|
#18+
Всем привет MS SQL 7.0 Есть вот такой запроc, в котором объединяются две таблички. Код: plaintext 1. 2. 3. 4. 5. 6. 7. CDRTmp -- несколько тысяч записей, WMasterCall --миллионы. Индекс WMasterCall_IDX_Time_Out_Trunk построен по трем полям: Код: plaintext 1. 2. 3. 4. 5. 6. Статистика обновлялаcь. Долго долго мучил запрос, наконец оптимизатор решил со мной согласиться и использовать сразу все три колонки индекса, когда вместо inner join стал использовать left outer join. Ну хрен с ним, я смирился. Запрос стал летать. Раз 10 выполнился на ура. А потом оптимизатор опять решил, что надо использовать только два первых поля от индекса (по ним выборка в пол миллиона строк получается), а дальше букмаркать таблицу, сохранять ее во временную и потом в nested loop объединять по времени. И теперь запрос вообще не открывается... Вопрос собственно такой, что туда еще добавить чтоб оптимизатор заткнулся?!!! Еще поле m.Carr_call_id неоднократно обновлялось. Это могло навредить индексу? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2002, 22:02:53 |
|
||
|
Ну почему не работает индех
|
|||
|---|---|---|---|
|
#18+
1. Я бы проверил что статистика обновляется на базе 100% записей 2. Всё-таки не стал использовать составной индекс. Попробуй разнести эти 3 поля и сделай 3 индекса вместо одного. Да, на забудь что в таблице почти всегда ОБЯЗАН быть кластерный индекс. Особенно когда таблица такого размера. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2002, 03:21:33 |
|
||
|
Ну почему не работает индех
|
|||
|---|---|---|---|
|
#18+
1) Статистика обновлялась с подным сканированием 2) Попробую, хотя не уверен, что будет лучше ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2002, 14:04:51 |
|
||
|
Ну почему не работает индех
|
|||
|---|---|---|---|
|
#18+
Да, забыл, кластерный индекс там конечно есть ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2002, 14:10:51 |
|
||
|
Ну почему не работает индех
|
|||
|---|---|---|---|
|
#18+
А что мешает в самом запросе использовать хинты, явно указывающие оптимизатору, какие именно индексы нужно использовать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2002, 16:41:37 |
|
||
|
Ну почему не работает индех
|
|||
|---|---|---|---|
|
#18+
Посмотри внимательно эдесь:http://www.swynk.com/friends/vartanyan/SQL70Joins.aspSWYNK.COM: Join Strategies in SQL Server 7.0. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2002, 18:45:36 |
|
||
|
Ну почему не работает индех
|
|||
|---|---|---|---|
|
#18+
Да я все это читал, там в любом случае используется loop join. Только в одном случае (который мне нужен) берется выборка сразу по всем полям, а потом происходит объединение, а в другом (который работает несколько часов) выборка берется только по первым двум полям, которые должны быть равны константам, а в loop join используется фильтрация в офигительной выборке. Я не знаю, может это глюк 7-го SQL сервера, наверно пора переходить на 2000 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2002, 20:59:32 |
|
||
|
Ну почему не работает индех
|
|||
|---|---|---|---|
|
#18+
Из BOL: Consider using nonclustered indexes for: - Columns that contain a large number of distinct values, such as a combination of last name and first name (if a clustered index is used for other columns). If there are very few distinct values, such as only 1 and 0, most queries will not use the index because a table scan is usually more efficient. - Covering all columns from one table in a given query. This eliminates accessing the table or clustered index altogether. и т.д. Так вот - попробуй сделать индекс просто по полю call_date_time_k. Еще вариант - сделать covered index по всем полям, участвующим в запросе. Что-нибудь типа Код: plaintext 1. 2. 3. 4. 5. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2002, 21:28:48 |
|
||
|
|

start [/forum/topic.php?fid=46&msg=32035210&tid=1821909]: |
0ms |
get settings: |
9ms |
get forum list: |
18ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
35ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
50ms |
get tp. blocked users: |
1ms |
| others: | 215ms |
| total: | 349ms |

| 0 / 0 |
