2, как минимум - айди и value. Чаще - больше, ибо архитектура бд разная бывает.

Всмысле?

Я про то, что при поиске или джойне на одну таблицу может использоваться только 1 индекс. Он может быть составным, но только 1

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

Если на коленке решаешь разовую задачу с временными таблицамм, то можно все

Я про продакшн))

Best practice

И прочее

Например, дерево категорий. Почти всегда при формировании всего дерева или куска на 2+ уровней в одном запросе будет использоваться несколько индексов. А подзапросы да, желательно делать, чтобы они юзали один индекс.
И составной индекс при формированиее дерева - это не гуд. Намного быстрее оно будет искать по отдельности детей/родителей, а потом отдельно айди, чем, когда придется рыться в составном индексе айди+родитель/дети.

в продакшене и про кэширование нужно забыть. Трэба так запросы писать и архитектуру проектировать, чтобы кэшировать ничего не нужно было. Кэшинг - это костыль на случай, если что-то долго формируется, но прямо здесь и сейчас нужно сделать что-то уже после формирования выборки. Закэшировал, сделал, а потом ищешь, почему оно тупит. )

"Ну да", на оба сообщения

Но в первым - мы просто немного о разном говорили)

Но даже кеширование иногда бывает полезным для использования. В отрыве от практический задачи достаточно сложно вести диалог о таких тонкий материях)

вчера решил просто затестить при создании таблицу тип json,при создании эта тема,значит нужно обновить сервер?

Понимаю

Приветствую!

Кто-нибудь выполнял  задачу "База данных хроники восхождений в альпинистском клубе"?

Благодарю конечно, но это я уже всё читал. Там таблицы в Access

А в чем проблема то?