Помогите составить быстрый запрос SElect затем Update

[greatbart]

А это что за золотое правило такое? Если вы им пользуетесь - ждите эпик фэйлов в своей работе.

Количество индексов должно быть достаточным и что не маловажным - правильным (что касается типа индекса и состава полей), иначе в некоторых случаях такие "индексы на все что после where" вам могут дать такую регрессию, что мало не покажется.

Объясните на примере

 

[BaBL]

Объясните на примере

При использовании индексов есть очень много нюансов, вплоть до порядка условий в WHERE и полей в составном индексе. Условие неравенства (<>) как и like, начинающйся с '%' вообще разрывают индексы. А некорректные индексы могут вытеснить эффективные. Если у тебя есть составной индекс и индексы по отдельным полям - эффективный составной может не быть использован.

К примеру, в таком запросе:

SELECT * FROM TABLE WHERE f1 = 1 AND f2 <> 0 AND f3 = 1

индекс по f1, f2, f3 будет бесполезен, будут использоваться только f1 и f2.

SELECT * FROM TABLE WHERE f1 = 1 AND f2 = 0

будет использован составной индекс f1, f2, если у тебя будут f1 и f2 отдельно, f2 скорее всего использован не будет.

Так же куча нюансов есть по ORDER BY.

Индексы надо проектировать исходя из бизнес логики приложения и реляционной модели. Это отдельная наука, ею занимаются DBA. Если бы было достаточно на все поля напихать индексов - база бы это делала сама по дефолту.

Так же исполнение одного и того же SQL может отличаться не только от разновидности сервера, но и даже от его версии. Каждый запрос проходит через оптимизатор, а там уже остается только надеяться, что он правильно ваш запрос разгребет и исполнит. Я в своей работе встречался с тормозящими индексами, удаление которых в 50 раз ускоряло работу на селектах на MySQL. Что касается UPDATE/INSERT - они вообще индексы не любят. Каждая вставка перестраивает индексы (а это не быстрый процесс), при массовой вставке индексы удаляются и воссоздаются когда все что нужно уже вставлено.