Можем даже заниматься системной оптимизацией полнотекстового. Надо просто поставить задачу.

То же что и обычно - ключ, полученный какими-то преобразованиями данных.

Там хранится ключ и указатель на физическое местоположение строки (RowId) в datafile.
Это для листовых узлов индекса. Для не-листовых - там линки на соседние блоки индекса.

Его формат немного отличается от указателя. Например Oracle хранит группу целых
чисел (номер файла, номер блока в файле (это тот самый 8к блок файловой системы),
и номер строки внутри блока). И дополнительно objectId. Это кажется надо для поддержки
кластеризованных таблиц.

Например. Фрагмент блока индекса.

(Я пишу в формате JSON чтоб было понятно. На самом деле там - RAW.)
keyrow_id (in JSON)mayton{ file=1, block=25, row=3, objId=... }Petro{ file=1, block=25, row=4, objId=... }........

В таблице есть блок номер 25 где лежат 2 строки проиндексированные по ключам mayton, Petro.

Понятно что file=1 это уже не файл где лежит индекс а файл где лежит индексируемая таблица.

Тоже работает. С точки зрения Oracle (например) - все индексы являются Unique по своей структуре данных.

Неуникальные там достигаются изменением алгоритма в плане оптимизатора. Как точно - я щас не помню
надо почитать. Дядка Том писал об этом.

Абсолютную копию этой-же строки. Тоесть строка "mayton" будет физически скопирована с таблицы в индекс.

Но если тебя интересует экономия места - то можно строить Index-Organized-Tables (это гибрид таблицы и индекса).
Но там есть ограничения. Нельзя дополнительные поля проиндексировать. Только primary.

В онлайне. Оно растет от листьев к корню. Грубо говоря - малый индекс - это 1 блок.

Когда инфа больше чем 8 килобайт - происходит split блока на 2 части вверх поднимается
новый ключ-медиана который делит условно все пространство ключей на 2 диапазона.
Те что больше ключа ложаться в правое поддерево. А те что меньше в левое.

Корневой узел хранит 1 ключ и два указателя влево и справо. А а дочерние узлы - листовые
хранят уже ключи и ROW_ID.

А вот примерно так будет выглядеть индекс с 3 уровнями. Это когда после сплитов наш корневой узел
опух до предела и произошел новый сплит с поднятием нового корня еще выше вверх.



Работает тоже самое алгоритм бинарного дерева просто заточенный под работу дисковыми блочками
чтоб не создавать лишней нагрузки.

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

Есть там еще такой интересный параметр как фактор кластеризации. Он .. грубо говоря показывает
насколько сильно мы будем промахиваться мимо кеша (таблицы) если будет скан индекса с первого ключа
по последний. Это актуально для запросов в RANGE-предикатом. Типа where date between d1 and d2.

Есть отдельный API который бегает мимо кешей. DIRECT. Типа прямой.
Он нужен для массовых операций типа count(*). И чтобы count своей селективностью
не засирал кеш - его кидают отдельной операцией которая не влияет на состояние кеша.

Тоже самое к массовым процессам типа ETL.

Я ведь тоже не могу ответить на этот вопрос при такой обобщённой постановке.

Прямой ответ - смотрите в excecution plan и добивайтесь того чтобы FTS операция была
заменена на index-scan, index-range, e.t.c. Есть еще варианты - использовать partition iterator
но это все требует деталей которых у меня нет.

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

По поводу войны и мира.

Что ты хочешь найти? Страницу документа? Номер строки? Или Строка и номер слова в строке?
Хочешь ли ты строгий поиск по совпадению? Или ты хочешь поиск по основе слова?
Или ты хочешь стемминг и лематизацию и способность кода находить синонимы и похожие
слова и опечатки.

Это все дополнения которые на 100 и более % меняют постановку и заставляют нас прыгать
от обычного индекса - к индексу Би-грамм и к фильтру Блума. И к фасетизации всех данных.

Текстовый поиск это вообще офигенски сложная дисциплина. И я в ней плаваю.
Я знаю ее где-то на 10% и там много подводных камней.

Всё что я описывал выше это обычный классический поиск в БД который к тексту вообще-то
отношения не имеет.

Хорошо. Тогда я умолкаю. Подожду Алексея с его тера-массивом структур.

Нет конешно. Еслиб такой ужас был тогда и загрузка данных в таблицу лагала-бы.

В наихудшем случае может быть split. Но это вместо 4 IOPS, будет чуть больше.