Здравствуйте, JazzzMaster, Вы писали:
JM>Странно, но мне то же самое поведение смоделировать не удалось. В обоих случаях случаях был использован full scan
Возможно при выборке уникальных ключей оркал научился использовать только данные индекса.
В любом случае count(1) = count(*), любой нормальный оптимизатор их будет считать одинаково.
Здравствуйте, Ziaw, Вы писали:
Z>Возможно при выборке уникальных ключей оркал научился использовать только данные индекса. Z>В любом случае count(1) = count(*), любой нормальный оптимизатор их будет считать одинаково.
тьфу, понял свой косяк — не собрал статистику по созданной таблице
Здравствуйте, Ziaw, Вы писали:
Z>Возможно при выборке уникальных ключей оркал научился использовать только данные индекса.
уникальность ключа здесь не имеет значения
данные, действительно, можно получить только из индекса, избегая чтения таблицы
но в случае select id from some_table выигрыша от использования индекса, разумеется, не будет
Здравствуйте, wildwind, Вы писали:
W>Почему же не будет, я ведь продемонстрировал это выше. Выигрыш будет, если индекс ощутимо меньше таблицы по размеру.
Вы сравнивали "select * " с "select pk "
сравнение, на мой взгляд, некорректное, ибо эти выборки возвращают, в общем случае, различный результат
повторюсь: в случае с "select pk " index FFS и FTS будут равноэффективны, только в первом случае юудет чтение индекса, а во втором — таблицы, соответственно
Здравствуйте, Niteshade, Вы писали:
N>Вы сравнивали "select * " с "select pk " N>сравнение, на мой взгляд, некорректное, ибо эти выборки возвращают, в общем случае, различный результат
Ты наверное не прочитал всю тему; этим сравнением я иллюстрировал ошибочность утверждения krot_av, что план и эффективность запроса не зависят от полей, перечисленных в выборке.
N>повторюсь: в случае с "select pk " index FFS и FTS будут равноэффективны, только в первом случае юудет чтение индекса, а во втором — таблицы, соответственно
Если ты по-прежнему не видишь разницы между чтением таблицы в 145 Мб и индекса в 2 Мб, то не поленись и проделай эксперименты сам.
Здравствуйте, wildwind, Вы писали:
N>>повторюсь: в случае с "select pk " index FFS и FTS будут равноэффективны, только в первом случае юудет чтение индекса, а во втором — таблицы, соответственно
W>Если ты по-прежнему не видишь разницы между чтением таблицы в 145 Мб и индекса в 2 Мб, то не поленись и проделай эксперименты сам.
На мой взгляд без WHERE или ORDER BY этот спор особого значения не имеет. План скажет full index scan, но базе все равно придется высосать всю таблицу.
Здравствуйте, Niteshade, Вы писали:
N>Здравствуйте, Ziaw, Вы писали:
Z>>Возможно при выборке уникальных ключей оркал научился использовать только данные индекса. N>уникальность ключа здесь не имеет значения N>данные, действительно, можно получить только из индекса, избегая чтения таблицы
вы правы, для оракла важно будет nullable поле или нет, null он не индексирует.
N>но в случае select id from some_table выигрыша от использования индекса, разумеется, не будет
а вот это очень странное утверждение, откуда вывод? тем более разумеется...
Важны количество прочитанных блоков и степень фрагментированности индекса и таблицы, в общем случае данные в таблице будут более разбросаны и чтений понадобится больше.
Здравствуйте, wildwind, Вы писали:
BG>>План скажет full index scan, но базе все равно придется высосать всю таблицу. W>C какой стати? Продемонстрируй! W>P.S. Случаи, когда результат команды explain plan отличается от реального плана, известны, но сейчас речь не о них, надеюсь.
Не, не о том.
утрированно: выполнение запроса состоит из двух шагов: построение плана (его оптимизация и т.д.) и собственно процесс выборки данных ("высасывания данных").
без where или order сравнивать запросы select * и select id особого смысла не имеет, т.к. высосать придется все данные в любом случае, и особых выигрышей мы не получим.
Другое дело сравнивать запросы вида:
select * from t where ID between 100 000 000 and 101 000 000
и
select * from t where to_char(id) like '1%'
тут выигрыши видны невооруженным глазом.
Здравствуйте, B0rG, Вы писали:
BG>без where или order сравнивать запросы select * и select id особого смысла не имеет, т.к. высосать придется все данные в любом случае, и особых выигрышей мы не получим.
Похоже, ты плохо представляешь, как хранятся и извлекаются данные. Почитай про организацию индексов, про пути доступа, попробуй сам выполнять такие запросы и, как ты говоришь, "выигрыш станет виден невооруженным глазом".
/
5901540 строк выбрано.
Затрач.время: 00:01:40.44
Статистика
----------------------------------------------------------
1 recursive calls
0 db block gets
71614 consistent gets
12695 physical reads
0 redo size
64209469 bytes sent via SQL*Net to client
649499 bytes received via SQL*Net from client
59017 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
5901540 rows processed
--==============================
/
5901540 строк выбрано.
Затрач.время: 00:07:38.10
Статистика
----------------------------------------------------------
1499 recursive calls
0 db block gets
127347 consistent gets
68535 physical reads
0 redo size
710351872 bytes sent via SQL*Net to client
649499 bytes received via SQL*Net from client
59017 SQL*Net roundtrips to/from client
108 sorts (memory)
0 sorts (disk)
5901540 rows processed
Хотя и без экспериментов очевидно, что чем больше объем данных, которые надо прочитать, тем больше времени на это уйдёт.
А с where и group by все как раз сложнее и менее очевидно, т.к. гораздо больше факторов играют роль.
Здравствуйте, wildwind, Вы писали:
W>Похоже, ты плохо представляешь, как хранятся и извлекаются данные. Почитай про организацию индексов, про пути доступа, попробуй сам выполнять такие запросы и, как ты говоришь, "выигрыш станет виден невооруженным глазом".
хммм... интресно что вас заставило сделать такое утверждение.
W>Хотя и без экспериментов очевидно, что чем больше объем данных, которые надо прочитать, тем больше времени на это уйдёт.
Ну дык, так о чем мы тогда говорим то?
только о том, что для SQL> select id from test_tab;
План выполнения
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=40 Card=83692 Bytes=418460)
1 0 INDEX (FAST FULL SCAN) OF 'TEST_TAB_PK' (UNIQUE) (Cost=40 Card=83692 Bytes=418460)
и для
SQL> select * from test_tab;
План выполнения
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=8264 Card=83692 Bytes=167802460)
1 0 TABLE ACCESS (FULL) OF 'TEST_TAB' (Cost=8264 Card=83692 Bytes=167802460)
просто так из любопытства посмотрите план для
select id, text from test_tab
(я только картиночный план могу видеть).
на моей десятке план такой же как и для select *, что в общем не удивительно, ведь если мы просим только индексируемое поле, то почему бы и не отдать только индексируемое поле, а если мы делаем select * вместе с индексируемым полем, но index scan нах не нужен, потому как все равно надо отдавать full table. О чем я собственно и говорил — без where, order by или group by спор будет несколько страннен.
W>А с where и group by все как раз сложнее и менее очевидно, т.к. гораздо больше факторов играют роль.
зато гораздо интереснеее... планы запросов для вашей таблицы (возвращаясь к исходному count() )
select count(id) from test_tab; : index scan
select count(text) from test_tab : full table
select count(2) from test_tab where id between 1 000 and 2 000 : выдает index range scan палюбому хоть для
select count(text) from test_tab where id between 1 000 and 2 000
о чем нам это говорит, о великий знаток путей организаций идексов и путей доступа?
Здравствуйте, B0rG, Вы писали:
BG>Ну дык, так о чем мы тогда говорим то?
Да похоже каждый о своем уже.
Резюмирую сказанное и показанное мною: для нескольких запросов, отличающихся только списком выборки (select ...) и одинаковых в остальных частях (from, where и т.д.) оптимальные планы выполнения также могут отличаться. И разница во времени выполнения и потребляемых ресурсах может быть весьма существенна.
Из этого, в частности следует, что в запросе нужно явно перечислять только необходимые столбцы, а не писать бездумно select * потому что "один фиг выполняться будет одинаково".
Здравствуйте, wildwind, Вы писали:
W>Ты наверное не прочитал всю тему; этим сравнением я иллюстрировал ошибочность утверждения krot_av, что план и эффективность запроса не зависят от полей, перечисленных в выборке.
поясню, если предыдущий пост был неверно понят: если поля, перечисленные в условии select, входят в индекс, по которому осуществляется доступ, то такой запрос, разумеется, будет эффективнее, т.к. позволит избежать обращения к таблице
W>Если ты по-прежнему не видишь разницы между чтением таблицы в 145 Мб и индекса в 2 Мб, то не поленись и проделай эксперименты сам.
пример, приведенный мной, был совершенно конкретный
если Вы сомневаетесь в его справедливости, приведите, пожалуйста, планы запросов, которые докажут обратное
причем здесь указанные Вами 145 и 10 Мб — непонятно)
указанные Вами ранее планы ни в коей мере не соотносятся с примером
Здравствуйте, Ziaw, Вы писали:
Z>Важны количество прочитанных блоков и степень фрагментированности индекса и таблицы
это справедливо
пример, конечно, относился к тому, что общий объем прочитанных данных будет одинаков
>в общем случае данные в таблице будут более разбросаны и чтений понадобится больше.
в общем случае, сложно сказать, что и как будет в таблице, организованной по куче)
