Интересует теоретический вопрос, понятно что на практике такого делать не надо.

Влияет ли на скорость выполнения SELECT порядковый номер поля в таблице, указанного как условие SELECT?

Т.е., например, в таблице бд нет индексов, все поля CHAR10, в таблице 70 полей.
Поля с col03 по col70 не ключевые.
1. select * from dbtab where col70 = условие.
1. select * from dbtab where col03 = условие.
Какой селект отработает быстрее 1 или 2; оба отработают одинаково?

Одинаково, либо разница будет в пределах статистической погрешности.
БД загружает данные сначала в память, а там что третье по счету поле, что семидесятое - роли не играет

Minimize the Search Overhead

Костя, быстрее будет тот вариант, под который ты индекс слепишь ) @ Капитан Очевидность

То John Doe: это понятно) Интересовала именно та ситуация, что я описал.
То ArmAnn: Спасибо за ответ)

Зависит от СУБД и релиза СУБД.

Например, оптимизатору ORACLE 9i иногда это важно для выбора нужного индекса. 10g пишут, что все равно.

Интересно посмотреть на такой запрос. На практике при работе со связкой 4.7 / Oracle 9 такого не наблюдал

а вот у меня было - правда лечилось сбором более подробной статистики оптимизатора для таблицы. Иногда приходилось хардкодить нужный индекс хинтами. После переезда на 10g ушло.

УПД.
Вообще по большому счету проблема может возникнуть при неаккуратном размножении индексов на таблице. Если есть два похожих индекса - оптимизатор путается и может создать неоптимальный план. С каждой новой версией оракла оптимизатор все умнее становится.
Если память не изменяет, в OPTIMIZATION GUIDE для 9i написано, что вперед наиболее селективные поля нужно использовать, остальные дальше, а в 10g - не написано.

То есть порядок следования полей в запросе ни при чем

для выбора индекса - при чем был, то есть оптимизатор безошибочно хватал верный индекс, если в условии поля как в индексе шли, но при точной статистике хватал правильно даже если порядок другой. А при стандартном 1% estimate для таблицы большого размера генерировался плохой план с большим числом вынужденных обращений к диску.
както так.

Я исхожу из того, что в программе не нужно менять порядок полей в Where, если статистика собрана верно.
Если она собрана неверно - это работа администраторов БД, а не разработчиков
ЗЫ: У нас кстати оценка индексов минимум по 10% собирается.

1% для больших объектов не то чтобы неверно, просто иногда недостаточно и надо перенастраивать размер семпла для объекта (зависит от каждого конкретного случая). Для всех крутая точность не нужна - место ж не бесплатное. Да и время сбора...

вопрос был задан без оглядки на качество статистики, добросовестность дба и т.д., поэтому и ответ был дан "в общем". При опред. условиях иногда важно получается. Я с таким сталкивался, вдруг кто-то не дай бог тоже столкнется - мож сей пост кому поможет.

Все-таки я для себя решил стараться порядок полей соблюдать исходя из того, на какой индекс нацеливаюсь. Почему бы не обезопасить себя от ленивых админов, аккуратно выстроив условие...

а разработчикам неплохо бы тоже в общих чертах засаповскую матчасть представлять...

Аккуратность естественно не помешает, я сам так пишу условия выборки.
Но не надо путать наглядность с быстродействием - посмотрите план выполнения запросов в ST05 и выставляйте претензии ленивым администраторов БД

+100 каждому
Накувыркавшись в свое время с SYBASE и Informix, я тоже стараюсь не искушать оптимизатор!
А еще, лучше не плодить похожих индексов...

Ну что ж, чем не подход.



это точно.