что B-дерево индексирует больше чем на 1 столбце, похожи?
Вы можете использовать свою исходную папку, поэтому всякий раз, когда вы создаете, эти файлы автоматически копируются в каталог классов.
Вместо использования файла свойств используйте файл XML.
Если данные слишком малы, вы даже можете использовать web.xml для доступа к свойствам.
Обратите внимание, что для любого из этих подходов потребуется перезапуск сервера приложений, чтобы изменения отражались.
6 ответов
Представьте, что ключ представлен кортежем Python (col1, col2, col3) ... операция индексации включает сравнение tuple_a с tuple_b ... если вы не знаете, какое значение col1 и col2 вас интересует, а знаете только col3, тогда ему придется прочитать весь индекс ("полное сканирование индекса"), что не так эффективно.
Если у вас есть индекс для (col1, col2, col3), то вы можете ожидать, что любая СУБД будет использовать индекс (прямым образом), когда предложение WHERE содержит ссылку на (1) все 3 столбца (2) оба col1 и col2 (3) только col1.
В противном случае (например, только col3 в предложении WHERE) либо СУБД не будет использовать этот индекс вообще (например, SQLite), либо выполнит полное сканирование индекса (например, Oracle) [ если нет лучшего индекса].
В вашем конкретном примерепредполагая, что id является уникальным идентификатором клиента, бессмысленно отображать его в индексе (кроме индекса, который ваша СУБД должна настроить для первичного ключа или столбца, отмеченного как UNIQUE).
В большинстве реализаций ключ является просто более длинным ключом, который включает все значения ключа с разделителем. Никакой магии там нет; -)
В вашем примере значения ключей могут выглядеть примерно так
"123499|John Doe|Conway, NH" "32144|Bill Gates| Seattle, WA"
Одна из характеристик этих индексов с составными ключами заключается в том, что можно использовать промежуточные узлы дерева. в некоторых случаях «покрыть» запрос.
Например, если запрос состоит в том, чтобы найти имя и город с заданным идентификатором, поскольку идентификатор является первым в индексе, индекс может эффективно выполнять поиск по этому индексу. Оказавшись в промежуточном узле, он может «анализировать» имя и город по ключу, и ему не нужно идти к конечному узлу, чтобы прочитать то же самое.
Если, однако, запрос также должен отображать номер телефона, то логика будет следовать по листу, когда будет найдена полная запись.
В Oracle может использоваться составной индекс ключа, даже если ведущие столбцы не фильтруются. Это делается с помощью трех механизмов:
- Быстрое сканирование полного индекса, при котором многоблочные чтения используются для прохождения всего сегмента индекса.
- Полное сканирование индекса, при котором индекс читается в логическом порядке блоков (я полагаю, я читал, что в последних версиях Oracle может использовать многоблочные чтения для этого, но на самом деле вы должны рассчитывать на чтение одного блока) ]
- Сканирование с пропуском по индексу, при котором очень низкая мощность для необязательных ведущих столбцов позволяет Oracle выполнять несколько сканирований диапазона индексов, по одному для каждого уникального значения ведущего столбца (столбцов). Это довольно редко в моем опыте.
Ищите статьи Ричарда Фута или Джонатана Льюиса для получения дополнительной информации о внутренностях индекса Oracle.
Он может использовать индекс (id, name, city) для удовлетворения предиката «City =?», Но очень и очень неэффективно.
Чтобы использовать индекс для удовлетворения этого запроса, ему нужно пройтись по большей части древовидной структуры в поисках записей с нужным городом. Вероятно, это все еще на порядок быстрее, чем сканирование таблицы!
Индекс (city, name, id) будет лучшим индексом для вашего запроса. Он легко найдет все нужные записи о городе и не будет нуждаться в доступе к базовой таблице для получения значений идентификатора и имени.
Некоторые реализации просто объединяют значения в порядке столбцов с разделителями.
Другое решение - просто иметь b-дерево внутри b-дерева. Когда вы нажимаете на лист в первом столбце, вы получаете как список совпадающих записей, так и мини-дерево следующего столбца, и так далее. Таким образом, порядок столбцов, указанных в индексе, имеет огромное значение для того, будет ли этот индекс полезен для конкретных запросов.
Вот связанный с этим вопрос, который я написал на прошлой неделе:
Выполняет ли SQL Server переход на выходы при использовании составного кластерный индекс?
Помимо уже описанного механизма "составного ключа", одной из возможностей является kdtree , которое работает как двоичное дерево, но по мере прохождения каждого уровня вы циклически проходите через ] k размеры. То есть первый уровень дерева разделяет первое измерение на две части, второй уровень разделяет второе измерение, k + 1 -й уровень снова разделяет первое измерение и т. Д. Это позволяет эффективно разделение данных на любое количество измерений. Этот подход распространен в «пространственных» базах данных (например, Oracle Spatial, PostGIS и т. Д.), Но, вероятно, не так полезен в «обычных» многоиндексированных таблицах.