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

0

Настройка

Я использую однонаправленное наследование (STI) в Rails, упрощенное до следующего:

class Vehicle
  belongs_to :user
end

class Car < Vehicle
end

class Plane < Vehicle
end

Каждая запись в таблице vehicles будет иметь столбец type, установленный либо в 'Car', либо 'Plane' в дополнение к внешнему ключу user_id. Он также может иметь дополнительные значения, если добавлено больше типов транспортных средств, однако type всегда будет иметь гораздо меньшую мощность, чем user_id. Как и в реальной жизни, я ожидаю, что в этой таблице будет больше автомобилей.

В [:user_id, :type] (в указанном порядке) есть составной индекс, и эти записи просматриваются подклассами.

Вопрос (ы)

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

Что происходит в случае, когда существует равное разделение?

  • Будет ли индекс сокращать записи пополам и, следовательно, иметь приличный эффект?
  • Будет ли стоимость базы данных, поддерживающая составной индекс над одним (т.е. просто user_id), превышать или отрицать любую экономию?

Пример SQL

Пример вызова ActiveRecord будет Car.where(user_id: 10), который генерирует следующий SQL:

SELECT `vehicles`.* FROM `vehicles` WHERE `vehicles`.`type` IN ('Car')
  AND `vehicles`.`user_id` = 10
  • 0
    Я удалил тег Postgres, потому что синтаксис MySQL.
  • 0
    Прости за это. Какая часть делает его специфичным для MySQL, а не для Postgres? Хотя в настоящее время я использую MySQL, меня больше интересует ответ, не относящийся к конкретному поставщику.
Показать ещё 2 комментария
Теги:
indexing

1 ответ

1
Лучший ответ

Стоимость поддержания индекса (одностолбцовый или многостолбцовый) почти всегда перевешивается улучшением производительности при использовании этого индекса. Это небольшое приращение для каждого INSERT/DELETE плюс стоимость, если изменить значение индексированного поля через UPDATE. (Случай UPDATE редок.) Итак, не беспокойтесь о стоимости "поддержания составного индекса".

WHERE `vehicles`.`type` IN ('Car')
  AND `vehicles`.`user_id` = 10

требуется INDEX(user_id, type).

Оптимизатор будет

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

Включить индекс; не беспокойтесь об этом.

Я упорядочил поля таким образом, а не (type, user_id) на основе вашего IN, что означает, что иногда вы можете иметь несколько значений для type.

Если все строки в таблице имеют type = 'Car', никаких проблем. Все, что я сказал, все равно применяется. Отходы включения ненужного type несущественны.

Лучше иметь все столбцы "=" сначала в индексе, то не более одного другого поля. Дальнейшее обсуждение здесь.

  • 0
    Спасибо за ответ и дальнейшее чтение!

Ещё вопросы

Сообщество Overcoder
Наверх
Меню