
Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
05.08.2002, 10:09:43
|
|||
|---|---|---|---|
|
|||
Причина неверной физической сортировки Select into. |
|||
|
#18+
Можно ли использовать запрос типа Select... into.. GROUP BY.. ORDER BY.. для получения физически отсортированной таблицы? (Она нужна для использования далее в ACCESS в запросе типа Select... First ...) Проблема: Почему при первом, а иногда при повторном выполнении этого же запроса порядок физической сортировки нарушается. Я заметил, что после видоизменения сортируемого поля например на Left(...) порядок снова восстановлен, но следующий запуск опять его нарушает. Впечатление что SQLServer не выполняет запрос, а использует предыдущий план и при этом неверно. В чем причина?Что не так? Привожу упрощенный пример drop table t2 SELECT ID, max(OrderDate) as OrderDate INTO t2 FROM t1 GROUP BY ID, OrderDate ORDER BY ID, OrderDate где ID - varchar, OrderDate - datetime Почему нет надежной физической сортировки ?, может из-за varchar ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
05.08.2002, 10:24:55
|
|||
|---|---|---|---|
Причина неверной физической сортировки Select into. |
|||
|
#18+
А кто Вам обещал физическую сортировку? Как сервер будет это у себя хранить - это его дело(если конечно нет кластерного индекса) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
05.08.2002, 10:35:38
|
|||
|---|---|---|---|
|
|||
Причина неверной физической сортировки Select into. |
|||
|
#18+
You must to builld a clustered index on the ID and OrderDate fields - so you'll get the physically sorted table. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
05.08.2002, 10:40:27
|
|||
|---|---|---|---|
Причина неверной физической сортировки Select into. |
|||
|
#18+
2Bor: насколько я помню, я нигде не встречал обещаний того, что выборка будет произведена в порядке физического расположения данных... Единственный 100% надежный способ - это применение Order By в итоговой выборке. А при выборке типа Код: plaintext ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
05.08.2002, 12:45:26
|
|||
|---|---|---|---|
|
|||
Причина неверной физической сортировки Select into. |
|||
|
#18+
Так всетаки как используя запрос типа Select... into.. GROUP BY.. ORDER BY.. получить физически отсортированную таблицу? Как сразу же создать кластерный индекс ведь эта таблица создается в запросе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
05.08.2002, 13:16:37
|
|||
|---|---|---|---|
Причина неверной физической сортировки Select into. |
|||
|
#18+
Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
06.08.2002, 16:46:19
|
|||
|---|---|---|---|
|
|||
Причина неверной физической сортировки Select into. |
|||
|
#18+
The guy wants to store data physically sorted? Fine, use clustered index for the primary key then. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
06.08.2002, 17:12:04
|
|||
|---|---|---|---|
|
|||
Причина неверной физической сортировки Select into. |
|||
|
#18+
Сервер хранит данные в хипе (если нет кластерного индекса) - то есть неупорядоченно. кроме того, часть необходимых строчек могут оказаться в кэше и возьмутся оттуда. поэтому в каком порядке строки возникнут в запросе - принуипиально непредсказуемо. Даже если это один и тот же запрос выполненный повторно по одному плану с небольшим интревалом. А все Order BY сервак осуществляет таща данные в темпдб и там их уже сортирует во временных таблицах. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|

start [/forum/topic.php?fid=46&mobile=1&tid=1821333]: |
0ms |
get settings: |
8ms |
get forum list: |
10ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
42ms |
get topic data: |
6ms |
get forum data: |
2ms |
get page messages: |
24ms |
get tp. blocked users: |
1ms |
| others: | 211ms |
| total: | 308ms |

| 0 / 0 |
