Django с использованием PostgreSQL - дублирующиеся индексы

Я использую Django вместо PostgreSQL, и мне трудно понять, как правильно использовать индексы для достижения наилучшей производительности. Вот пример модели:

class SomeObject(BaseAggModel):
    id = models.UUIDField(primary_key=True, default=uuid.uuid4, editable=False)
    element = models.ForeignKey(Element, on_delete=models.PROTECT, db_index=True)
    city = models.ForeignKey(City, on_delete=models.PROTECT, db_index=True)
    date_created = models.DateTimeField(null=True)

    class Meta:
        unique_together = ('element', 'city', 'date_created')
        
        indexes = [
            models.Index(fields=['city ', 'element'])
        ]

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

Поскольку у меня есть unique_together, а element является первой сущностью в этом индексе. Значит ли это, что я могу изменить поле element на db_index=False, поскольку у меня уже есть комбинированный индекс для этого поля?

Поскольку у меня есть индекс над city и element вместе, и city является первой сущностью в этом индексе. Означает ли это, что я могу изменить поле city на db_index=False, поскольку мне, вероятно, не нужен специальный индекс для него?

Альтернативно (вместо того, чтобы делать предыдущие изменения), поскольку у меня есть unique_together, а также Index. Если я изменю порядок unique_together так, чтобы он был над (city, element, date_created), сделает ли это индекс над (city, element) избыточным и может ли он быть удален без ущерба для производительности?

Вопрос об индексах не может быть де-коррелирован с запросами, которые будут выполнять пользователи. Нет никакой возможности с помощью волшебного хрустального шара заранее узнать, какими будут эти запросы. Поэтому создание и удаление индексов - это настоящая работа DBA, которая должна выполняться на регулярной основе, например, каждые 3 месяца. Некоторые РСУБД предоставляют информацию об отсутствующих индексах, которые, по их мнению, являются актуальными для некоторых запросов... Так обстоит дело в Microsoft SQL Server, начиная с версии 2005. Также необходимо иметь представление, которое подсчитывает доступ во времени ко всем индексам, чтобы знать, действительно ли индекс используется. Иногда индексы использовались часто, а затем устаревают, так как с выходом новой версии продукта изменились способы выполнения операций. Таким образом, в ходе регулярно проводимой кампании, которую я называю "кампанией индексирования", вы должны отказаться от неиспользуемых индексов и создать новые индексы на основе реальной эксплуатации...

Вернуться на верх