Влияние основного ключа на производительность в SQLite - PullRequest
4 голосов
/ 06 августа 2009

У меня есть база данных sqlite, используемая для хранения информации о заданиях резервного копирования. Каждый прогон увеличивается примерно на 25 МБ в результате добавления около 32 000 записей в конкретную таблицу.

Эта таблица является "таблицей карт", используемой для связи определенной информации с записями в другой таблице ... и у нее есть первичный ключ (autoincrement int), который я не использую.

sqlite зарезервирует 1, 2, 4 или 8 байтов для столбца INT в зависимости от его значения. Эта таблица содержит только 3 дополнительных столбца, также типа INT.

Я добавил индексы в базу данных по столбцам, которые я использую в качестве фильтров (ГДЕ) в своих запросах.

При наличии индексов и т. Д. И в описанной ситуации первичные ключи имеют какое-либо полезное преимущество с точки зрения производительности?

Примечание. Производительность очень и очень важна для этого проекта - но не в том случае, если 10 мс, сэкономленные на 32000 заданиях, означают дополнительные 10 МБ данных!

Ответы [ 2 ]

3 голосов
/ 06 августа 2009

Индекс первичного ключа используется для поиска строки для данного первичного ключа. Он также используется для обеспечения уникальности значений первичного ключа.

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

Ненужный индекс тратит место на диске и замедляет выполнение операторов INSERT и UPDATE. Это не должно оказывать негативного влияния на производительность запросов.

0 голосов
/ 06 августа 2009

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

Другая возможность - сохранить столбец, но отбросить первичный ключ. Это будет означать, что приложение должно заботиться о предоставлении уникального идентификатора для каждого оператора вставки. До и после каждой пакетной операции вы должны проверить, является ли этот столбец уникальным. Это не работает, например, в MySQL и Oracle из-за проблем с множественным параллелизмом, но работает в sqlite.

...