2016-03-01 3 views
0

У меня есть таблица в PostgreSQL со следующей информацией:Создание оптимального индекса для моей базы данных

rawData (fileID integer references otherTable, lineNum integer, data1 double, ...) 

Когда я ищу эту таблицу, я делаю это с помощью следующего запроса:

SELECT lineNum, data1, ...other data FROM rawData WHERE 
fileID = ? AND data1 < ? ORDER BY lineNum; 

В общем, данные в этой таблице представляют собой количество записей для каждого идентификатора файла, и каждый файлID имеет строку lineNum от 0 до x, при этом строка LineNum никогда не повторяется для каждого файлаID (но она повторяется для разных файлов fileID). Тогда data1 является фактически случайным числом, которое может перекрывать или не перекрываться.

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

индекс Идея 1:

CREATE INDEX searchIndex ON rawData (fileID, data1, lineNum); 

индекс Идея 2:

CREATE INDEX searchIndex ON rawData (fileID, lineNum, data1); 

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

И, наконец, должен ли я изменить свой поисковый запрос, чтобы использовать индекс, или автоматически будет использовать этот индекс при поиске в таблице?

ответ

1

Вы должны смотреть на использование вместо этого:

CREATE INDEX searchIndex ON rawData (fileID, lineNum); 

несколько вещей:

  • В частности, за docs, Indexes with more than three columns are unlikely to be helpful unless the usage of the table is extremely stylized.

  • С вашего второго поискового запроса требует фильтрации без data1 колонны, держа второй столбец lineNum должно быть достаточно (так как вы говорите, что будет квазислучайный), и в редком возникновении что есть повторы, таблица Fetches должны обеспечить правильность. Но что это будет означать, что индекс будет 1/третий меньше по размеру, что является большой выигрыш (Think индекс малого достаточно, чтобы быть в памяти/индекс-только-сканов и т.д.)

0

Можно использовать любой из индексов. Скорее всего, это будет зависеть от многих вещей, например, от количества строк в таблице, от количества lineNum за fileID, насколько избирательным является предложение data1 < ?, каково ваше оборудование, каковы наши настройки конфигурации, какая версия PostreSQL вы используя, какой физический порядок лежат в строках таблицы и т. д.

Единственный способ узнать наверняка - попробовать его собственными данными в своей собственной системе и посмотреть.

Я бы только что построил индекс на (fileID, lineNum, data1), или даже просто (fileID, lineNum), потому что это кажется более естественным, а затем забудьте об этом. Скорее всего, это будет достаточно быстро.Когда есть очевидная проблема с производительностью, чем у вас будет тестовый пример, который необходим, чтобы прийти к реальному выводу.

Смежные вопросы