Использование индекса postgresql - плюсы и минусы

Question

Я использую python / django как язык программирования / фреймворк.То, что мне нужно знать, полностью о postgresql и индексации ...

Для тех, кто использует django, вероятно, знают Content Type и Django Admin Log.Но в скором времени журнал администратора регистрирует действия пользователя.Я также использую его для регистрации всех действий, выполненных на сайте.Так что у него есть 1.000.000+ записей.Я использую sql-запросы для фильтрации результатов, вот и все ...

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

Другое поле - идентификатор объекта, в котором хранится идентификатор связанного объекта, тип поля - varchar иполе не проиндексировано ...

Пример использования:

Select from django_admin_log where content_type_id=15 and object_id="12343545";

Поскольку content_type_id = 15 баллов, моя таблица blog_texts и идентификатор связанного объекта - 12343545, я могу легко получить связанноеdata ...

Но идентификатор_объекта не индексируется, и в таблице содержится более 1.000.000 записей. Запрос, подобный тому, который я пишу выше, занимает много времени.

Каковы будут преимущества иНедостатки использования индекса в object_id.Преимущества будут больше, чем недостатки или нет?

ОБНОВЛЕНИЕ: У меня нет обновлений в таблице журнала администратора.Он просто регистрирует каждое из действий пользователя ... 40.000-45.000 записей вставляются в таблицу каждый день.И система действительно занята в течение 2/3 дня, около 15-16 часов (с утра до вечера).Таким образом, 45.000 записей вставляются в период с 8:00 до 23:00 ...

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

ОБНОВЛЕНИЕ 2: Еще одновопрос.Другая таблица с 2.000.000+ записей с логическим полем.Поле - это что-то вроде «будет отображаться», и оно используется с другими критериями фильтра.Логично ли создать индекс для такого логического поля.

Вторым условием является индексирование полей логического и даты-времени вместе в таблице с 1 000 000 записей ...

Использование индексадля этих двух состояний хорошая идея или нет?

Answer 1

Просто для пояснения ....

Для этого конкретного SQL вы должны использовать один индекс, который включает оба столбца (content_type_id и object_id) - составной индекс.

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

Два индекса - существующий и новый только на object_id - вероятно, не дадут наилучшего результата для этого запроса.

РЕДАКТИРОВАТЬ : если выесли расширить существующий индекс на столбец object_id, снижение производительности для вставки будет незначительным, но ваш выбор будет работать намного быстрее.

РЕДАКТИРОВАТЬ 2 : если у вас есть подобные утверждения

WHERE bool = true

и другие подобные:

WHERE bool = true AND date > something

Я бы предложил объединитьсначала индексируйте по BOOL, а затем по DATE.

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

Однако, в зависимости от ваших данных, может иметь смысл НЕ индексироватьBOOL поле.Например, если 95% всех строк имеют значение true, приведенные выше операторы не будут фильтровать слишком много.В этом случае индекс может потенциально снизить производительность для оператора выбора.Однако хороший оптимизатор просто проигнорирует индекс.Тем не менее стоимость вставки / обновления / удаления останется.

---

Подробнее о сцепленных индексах в моей бесплатной электронной книге .

Answer 2

Какими будут преимущества и недостатки использования индекса в object_id.

Преимущества будут быстрее запросов. Недостатки вставок будут медленнее.

Преимущества будут больше, чем недостатки или нет?

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

Обновление:

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

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

Будет лучше создать составной индекс для (object_id, content_type_id).