1) index(a,b,c)
order by a desc, b desc , c desc
по индексу будет работать?

Вроде бы нет, на сколько я помню, сканирование индексов в обратном направлении MySQL делать не умеет.
Кроме того, может ли быть вообще применим индекс для запроса может зависить от остальных его частей, в частности, where.

2) select count(*) from table where did=1 => using index, using where
select count(id) from table where did=1 =>using index collation
did определен not null (разумеется)

Не знаю, что тут написать, могу только прокоментировать.
2.1) если в explain запросе идет index collation, это значит что данные берутся чисто из индекса?

Если в плане есть использование индекса, это не обязательно значит, что все данные берутся только из индекса.
Так что вопрос странен.

2.3) если так, то почему при полностью загруженном в память индексе оно может выполяться дольше чем using index, using where ?

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

2.4) почему в первом варианте не используется индекс из памяти?

Не существует индексов в памяти.


3) index (a,b,c,d)
select * from table where a=1

3.1) теоретически насколько я помню из курсов по БД, в такой ситуации нет смысла делать index(a), т.к. он и так присутствует в составном, верно?

В принципе, да. Но важно, что не только присутствует, но и стоит на лидирующем месте.
Кроме этого, важна длина индексной записи, и высота индексного дерева, иногда индекс только по префиксу может
быть лучше, но это тем не менее не значит, что его нужно обязательно создавать.

3.2) Почему index(a) отрабатывает заметно быстрее чем index(a,b,c,d) при том что в обоих случаях длина индекса одна?

Длина индексной записи меньше, высота дерева меньше (поскольку больше записей на странице), чтений для сканирования индекса нужно меньше. Однако при всём этом заметно быстрее он работает скорее всего не
по этим причинам. Хотя может и по этой.

Вообще, скорость (т.е. время) выполнения запроса не может являться критерием его оптимальности, это только один из главных целевых параметров.


4) как должны быть проставлены индексы на 2 страницах что бы выборка сработала по пересечению индексов и была взята из памяти? я точно не помню как это выглядит, но что-то такое есть (аналог с index collation но для 2 таблиц)

Нет индексов в памяти. Не бывает.
Пересечение иднексов -- тоже достаточно сомнительная стратегия выполнения запросов, она используется в некоторых СУБД, но в больших промышленных практически не используется. Сложно предстазать трудоёмкость и
эффективность.


5) myisam vs innodb. прибегал админ по БД, настроил оба движка вроде как положено, но доступа к настройкам не дал и не показал их.
myisam не нравится тем что лочит всю таблицу при хитрых апдейтах, которые длятся по 2-3 минуты, а это на рабочем сайте не очень, innodb такой проблемы не создает, но и работает по 15-20 минут


Прежде всего myisam нетранзакционен и работает без кэширования данных.
Это позволяет с полной уверенностью утверждать, что mySQL + MyISAM --это вообще не СУБД, а хрень какая-то.
Потому как две основные технологии СУБД -- кэширование и индексирование. MyISAM может кэшировать только индексные записи.


плюс innodb на прямых выборках с легкими джоинами работает на порядок (не шучу) дольше.
вопрос - это нормальное соотношение производительности или надо пойти и выдрать тому админу руки за настройку innodb ?


В первом приближении -- надо настроить правильно, да. Вообще, MyISAM & Inno - антогонисты, им обоим нужен
кэш, и совместно использовать они их не могут. Но возможно и просто тупо наличие неоптимизированных запросов.
Их надо тюнить отдельно, для одного и другого.



myisam при чем после его настройки прям залетал, innodb тоже ускорился но сравнение сильно не в его пользу
в принципе я знаю что myisam рулит на чтении, но удивил РАЗМЕР руления и так же тот факт что запись тоже не кисло тормозит.


Как раз наоборот, рулит на чтение Inno, а MyISAM рулит на запись . Но при этом что и куда он записывает -- никто не знает, никто не гарандирует Durability на нём.


Ну и твоё сравнение одного движка с другим скорее некорректно и субъективно, потому что чтобы нормально сравнивать, нужно очень хорошо постараться.

индексаторЕсть небольшая учебно-тестовая MySQL-БД: "пациент", "город", "карточка", "рост", "вес", "больница", "диагноз", "контакты" - занимаюсь самообучением. Записано в базе порядка 1000 человек. Клиент написан на Delphi. Всё нормально работает, но начитался вчера про индексы и засомневался - надо ли мне их создавать, и если надо, то на каких именно полях? Или при таком мизерном количестве записей от индексов вреда больше будет, чем пользы?
это очень маленькая бд, на которой, безусловно, можно отрабатывать мастерство по уборке и обработке данных, семантику запросов, но для работы над проблемами производительности это очень мало, ты просто не увидишь их.

надо иметь 2-3 таблицы с размерами несколько сотен тысяч записей, лучше 5-7, а идеально по миллиону.

индексатор? Или при таком мизерном количестве записей от индексов вреда больше будет, чем пользы?

вреда не будет точно, но и пользы особенно не жди...