|
|
|
Обход Natural
|
|||
|---|---|---|---|
|
#18+
Код: plaintext 1. 2. 3. 4. 5. 6. 7. Код: plaintext Natural Код: plaintext Создаем индекс. делаем коммит, вновь вводим запрос и опять имеем Natural. Пишем Код: plaintext 1. . index ID_IND cannot be used in the specified plan. ' Почему? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2003, 15:33 |
|
||
|
Обход Natural
|
|||
|---|---|---|---|
|
#18+
Что-то у тебя странное, во where поле NUM указано, а в индексе ID, естественно, не подходит ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2003, 15:37 |
|
||
|
Обход Natural
|
|||
|---|---|---|---|
|
#18+
Имей ввиду два момента: 1) В плане IB не всегда показывает все индексы, которые он использует 2) Натурал не всегда плохо. Иногда он эффективней чем индексная выборка. Я вобще придерживаюсь мнения что планы руками лучше не писать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2003, 15:53 |
|
||
|
Обход Natural
|
|||
|---|---|---|---|
|
#18+
Сорри, Очепятка Код: plaintext 1. Не хочет использовать и упрямо пишет Natural, что естественно не убыстряет работу и без того тормозящей процедуры. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2003, 15:56 |
|
||
|
Обход Natural
|
|||
|---|---|---|---|
|
#18+
Я вобще придерживаюсь мнения что планы руками лучше не писать. Я на самом деле тоже) Просто пытаюсь разобраться в причинах тормозов. Да и всё таки - в явном то виде почему он не хочет его использовать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2003, 15:59 |
|
||
|
Обход Natural
|
|||
|---|---|---|---|
|
#18+
Считает, что с ним будет медленнее. НА выбор плана влияет многое, и порядок выражений во where, и количество записей в таблицах, и селективность индекса... А natural здесь скорее всего из-за distinct. Попробуй group by O2.ID вместо него ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2003, 16:01 |
|
||
|
Обход Natural
|
|||
|---|---|---|---|
|
#18+
Вот объясните мне почему это Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. выполняется за 1.15сек, a Код: plaintext 1. 2. 3. 4. 5. 6. 7. При замене distinct на group by, Natural исчезает, но выполняется при этом оно за 4 минуты :\ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2003, 17:25 |
|
||
|
Обход Natural
|
|||
|---|---|---|---|
|
#18+
Откудова мы знаем почему. Посмотри статистику в эксперте по индексированным и неиндексированным чтениям. Возможно 1-й запрос в несколько раз ограничивает количество обрабатываемых записей - вот оно и быстрее. В любом случае смотри статистику. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2003, 17:38 |
|
||
|
Обход Natural
|
|||
|---|---|---|---|
|
#18+
Естественно смотрел) И если бы она проясняла, не спрашивал бы... Нет неиндексированных и по ~190тысяч индексированных чтений из каждой из 4х табличек для первого(быстрого) и ~1.300.000 к fulfildoc, ~1.400.000 к ORdITEMSTATE - индексированные и ~59000 к ORD неиндексированных для второго. Почему так я без понятия) - 2й запрос работает с меньшим числом табличек и выбирает меньше данных)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2003, 18:29 |
|
||
|
Обход Natural
|
|||
|---|---|---|---|
|
#18+
Фух, что за человек. Ну сделай же ты индекс по ORD.NUM и по ORDITEMSTATE.ORDNUM !!! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2003, 18:58 |
|
||
|
Обход Natural
|
|||
|---|---|---|---|
|
#18+
А, так это ещё и под ИБ7 все крутиться Ну тогда не удивляйся если странные планы будешь получать ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2003, 19:00 |
|
||
|
Обход Natural
|
|||
|---|---|---|---|
|
#18+
Этой базе лет эдак уже несколько Есть все там индексы :/ Под IB7.0 всё ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2003, 19:22 |
|
||
|
Обход Natural
|
|||
|---|---|---|---|
|
#18+
Код: plaintext 1. Сделай так: Код: plaintext IB5 и IB6 очень чутко реагировали на это. IB7 я ещё не проверял. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2003, 08:33 |
|
||
|
Обход Natural
|
|||
|---|---|---|---|
|
#18+
Zmeishe Там Natural не из-за AND (F.INPDATE >= :D1) AND (F.INPDATE <= :D2). У меня тоже одна из 3-х всегда Natural ... Best regards, Dnico. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2003, 10:12 |
|
||
|
Обход Natural
|
|||
|---|---|---|---|
|
#18+
>hyh Если тебе действительно интересно плановое хозяйство, то ходи сюда krista.ru, очень полезно...:) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2003, 10:20 |
|
||
|
Обход Natural
|
|||
|---|---|---|---|
|
#18+
Это только одна из причин, из моего опыта. Другие возможные причины: - имеет значение порядок полей в индексе. Я как-то игрался с порядком полей и нашёл комбинацию, при которой Natural изчез. - имеет значение разбить один запрос по нескольким таблицам на несколько запросов через ХП for select do ... for select do Например в запросе три таблицы. Если все известные мне способы, избавиться от Natural, исчерпаны, я разбиваю на один запрос из двух таблиц и один запрос из одной таблицы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2003, 10:26 |
|
||
|
Обход Natural
|
|||
|---|---|---|---|
|
#18+
1. Тормоза точно из-за NATURAL, а не из-за SORT? Убери DISTINCT и сравни время выполнения. 2. Ты подсовываешь серверу неправильный явный план. Если не разбираешся в выполнении джойнов сервером, то за их ручную оптимизацию лучше не берись. 3. Сервер сможет использовать индексы для всех потоков джойна только в одном случае - если (а) есть индексы по FULFILDOC.INPDATE и ORDITEMSTATE.FFDOCNUM и (б) таблица FULFILDOC стоит первой в порядке соединения. Т.е. явный план должен быть примерно такой (имена индексов условны): Код: plaintext 4. Даже в случае вышеуказанного плана выполнение может быть медленее. Как тут уже правильно сказали, NATURAL - это зачастую не есть зло. Если у тебя в таблице ORD записей немного, а индекс по FULFILDOC.INPDATE имеет плохую селективность, то оптимизатор тебе выдал наилучший план из возможных. 5. Какую производительность дает следующий запрос: Код: plaintext 1. 2. 3. 4. 5. 6. 7. ??? 6. Если ничего из вышесказанного не помогает, то IB7 must die, однозначно ;-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2003, 12:15 |
|
||
|
Обход Natural
|
|||
|---|---|---|---|
|
#18+
На Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. Код: plaintext И выполняется на 3 с небольшим секунды )) По 33 тысячи запросов идет к ORD, ORDITEMSTATE - индексированных, почти ~12.5 тысяч - неиндексированных к FULFILDOC ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2003, 13:28 |
|
||
|
Обход Natural
|
|||
|---|---|---|---|
|
#18+
Zmeishe, Тут ведь нужны ID для филиалов у которых есть документы нужного типа в нужном промежутке времени Если, например, выбрать все у которых есть нужного типа, а потом все у кого нужной даты, то попадут те, у кого нет нужного типа в этом временном промежутке, зато есть документы других типов)) то есть так Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. На самом деле разбивать я пробовал разбивать по уникальному вобщем-то ORDNUMу(текст уже потер), но вис этот вариант с неменьшим энтузиазмом) То есть разбивка 1) может быть корректна только с виду 2) К сожалению не всегда помогает Johnmen, Почитаем) Жаль только оно 2х летней давности - видимо когда разбирались с ИБ написали) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2003, 13:47 |
|
||
|
Обход Natural
|
|||
|---|---|---|---|
|
#18+
2hyh Т.е. индекса по INPDATE у тебя нет, получается? Тогда можешь дописать к своему первоначальному запросу план: Код: plaintext и радоваться тем же 3 секундам. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2003, 13:57 |
|
||
|
|

start [/forum/topic.php?fid=40&gotonew=1&tid=1579452]: |
0ms |
get settings: |
6ms |
get forum list: |
11ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
171ms |
get topic data: |
8ms |
get first new msg: |
5ms |
get forum data: |
2ms |
get page messages: |
43ms |
get tp. blocked users: |
1ms |
| others: | 199ms |
| total: | 452ms |

| 0 / 0 |
