Индексирование против отсутствия индексации при вставке записей

Question

У меня есть несколько вопросов о том, будет ли лучше не использовать индексацию.

Предпосылка: Мои записи имеют атрибут метки времени, и записи будут вставлены в порядке их меток времени (т.е. вставлены в хронологическом порядке).

ВОПРОСЫ:

1. Если я не использую индексирование, обычно ли для базы данных вставлять записи в том порядке, в котором они были вставлены?

2. Если ответ на вопрос № 1 положительный, то при выполнении запроса типа «SELECT .. WHERE timestamp> X» будет эффективна база данных или придется проходить каждую запись, поскольку не проиндексированы? Я бы предположил, что если бы не было индекса, база данных не «знала бы», что записи были вставлены в отсортированном порядке, и поэтому не могла бы использовать отсортированное свойство базы данных.

Я предполагаю, что кластерный индекс будет лучшим для этих типов записей и их вставок.

Пожалуйста, дайте мне знать, что вы, ребята, думаете.

Спасибо, JBU

Answer 1

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

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

Answer 2

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

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

Если вы выполняете пакетную вставку, вы, вероятно, будете иметь несколько записей, вставленных с одной и той же отметкой времени. Очевидно, что это не может быть первичным ключом.

Чтобы выполнить запрос типа «SELECT .. WHERE timestamp> X», индекс в поле «timestamp» улучшит производительность этого запроса, независимо от того, кластеризован он или нет.

Будет ли кластеризован индекс в поле 'timestamp', и понадобятся ли вам другие индексы, будет зависеть от всех запросов, которые вам нужно будет выполнить с данными.

Answer 3

Какая база данных?

1)
Таблица без индексов называется кучей. Куча будет хранить записи в том порядке, в котором они были вставлены. Пока вы не вставляете из нескольких потоков, вы сможете предсказать порядок, в котором база данных будет хранить записи. Как уже отмечали другие, это предполагает, что вы не делаете удаления, и в этом случае ваша СУБД заполнить пустые страницы новыми строками.

2)
Без индексов СУБД должна будет выполнить полное сканирование таблицы (которое выполняется за линейное время по отношению к количеству записей). Для записей, в которые вы вставляете записи с увеличивающимися временными метками, лучше использовать кластеризованный индекс. Пока вы не вставляете старые временные метки, СУБД должна физически переставлять строки из-за кластеризованного индекса.

Answer 4

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

Любой SELECT из таблицы без индексов приведет к сканированию таблицы. Индексы - это то, как вы «сообщаете» базе данных о таких вещах, как «отметки времени в порядке возрастания».

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

Answer 5

Конечно, это зависит от базы данных, которую вы используете!

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

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

Answer 6

Вам нужно создать индекс для столбца метки времени, чтобы иметь возможность искать мою метку времени. Просто сделай это (ТМ).

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

Answer 7

Я считаю, что согласно стандарту sql, вы никогда не можете быть уверены в порядке выбора строк в неупорядоченном столбце. Даже если вы протестируете заданную базу данных и обнаружите, что в настоящее время она соответствует действительности, это может не иметь место при следующей редакции базы данных. Мой опыт секунд Стивена Лоу. Если вы вставляете большое количество строк в таблицу, отключите (или удалите) строки перед вставкой. Воссоздание индексов после вставки займет меньше времени, чем вставки с включенными индексами.

Alan

Answer 8

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

Кластерный индекс на временной метке в вашем случае действительно не имеет недостатков. Вы можете заполнить 100% своих страниц данных, и вы все равно будете не хуже, чем куча. Запросы, однако, могли бы воспользоваться этим и были бы где угодно от незначительно (если вы возвращаете, например, 90% таблицы) до смешного (если вы возвращаете, например, 1% таблицы) быстрее .

Answer 9

Я jbu, создатель поста.

Спасибо всем за быстрый ввод.

Чтобы ответить на дополнительные вопросы:

Да, у меня есть статические данные - я не буду удалять.

Я тестирую несколько разных баз данных: Sybase SQL Anywhere, Oracle Berkeley DB, H2, Firebird, SQLite и, возможно, несколько других.

Стивену Лоу: В моей таблице будет миллионы записей (максимум - до 32 ГБ). Если я отключу индексирование на некоторое время, а затем заново создаю индекс, разве это не займет очень много времени - по крайней мере, несколько минут (я предполагаю, что это может занять гораздо больше времени)? Кроме того, я думаю, что вы предполагаете, что будет непрерывный поток вставок. Я почти постоянно буду вставлять с использованием командных вставок, поэтому я не думаю, что у моего ЦП и диска когда-либо будет перерыв для переиндексации.

Опять же, спасибо за вклад, ребята.

JBU