2015-12-15 5 views
0

Предположим, у меня есть миллионы строк в таблице. Таблица имеет первичный ключ (pk индексируется по умолчанию в postgresql) в столбце id.Выбор по первичному ключу и другим индексам

Также в таблице есть дополнительные столбцы, такие как year, name, phone и что-то еще.

Я хочу, чтобы найти строку по идентификатору или группы идентификаторов и year колонки так:

SELECT * 
FROM mytable 
WHERE year = '1996' AND id = 123123 

или как то:

SELECT * 
FROM mytable 
WHERE year = '1996' AND id IN (123123, 456456, 789789) 

Должен ли я создать индекс year столбца, если у меня есть первичный ключ на id? Какой тип индексации более эффективен для этого случая?

Что делать, если у меня было всего два года в моем столе (например, 1996 и 1997 годах), было бы лучше, если бы я создал индекс на столбце year?

+0

Не сравнивать числа и строки. '' 1996'' - это строковое значение, а не число. Некоторые СУБД могут не использовать поиск индекса, если вы не используете постоянное значение, соответствующее типу данных столбца (хотя в течение двух разных лет в «миллионах» строк индекс вряд ли был бы выбран в любом случае). –

+0

Какие РСУБД это? Добавьте тег, чтобы указать, используете ли вы 'mysql',' postgresql', 'sql-server',' oracle' или 'db2' - или что-то еще. –

ответ

1

Не имеет смысла создавать индекс для вашего сценария. Идентификатор - это первичный ключ, а индекс по идентификатору всегда будет использоваться, когда вы смешиваете его с Годом (используя AND).

+1

По крайней мере, как есть И год. (ИЛИ был бы совсем другим.) – jarlh

+0

@jarlh Да. Но OP не спрашивает об OR. Когда будет OR и в таблице будет всего 2 года, тогда будет использоваться FULL SCAN. – dcieslak

+0

Я просто хотел добавить эту дополнительную информацию, так как вы сказали «смешайте ее с годом». Хорошо знать, что это зависит от того, как вы смешиваете. – jarlh

0

1) Если у вас установлен PK, вам не нужен индекс только для этого поля. http://www.postgresql.org/docs/current/interactive/sql-createtable.html

«PostgreSQL автоматически создает индекс для каждого уникального ограничения и ограничения первичного ключа для обеспечения уникальности. Таким образом, нет необходимости явно создавать индекс для столбцов первичного ключа».

2) Однако, если вам нужно регулярно сортировать по году И id, я бы рекомендовал создать индекс, который включает в себя оба. Я обнаружил, что PG работает лучше, когда вы получаете порядок индекса правильно, например. У меня был стол с store_number и product_number в нем, который имел тот же продукт в нескольких магазинах. Сначала он работал лучше с store_number, потому что это был общий фильтр для пользовательских запросов и сократил набор записей миллионами - есть больше продуктов, чем магазинов!

3) Я предлагаю изменить год как целое. Делает это проще для выполнения логических операций.

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