Производительность запросов MySQL с помощью справочных таблиц

Question

Производительность запросов MySQL с помощью справочных таблиц

0

Для следующих 2 табличных структур, если объем данных действительно высок:

cars table
Id | brand name | make year | purchase year | owner name

Есть ли какое-либо преимущество в производительности запросов при структурировании его таким образом и вместо этого вместо двух таблиц?

cars table
Id | brand_id | make year | purchase year | owner name

brands table
Id | name

Кроме того, если все 4 столбца попадают в мое предложение where, имеет ли смысл индексировать какие-либо?

aiiwa 05 июнь 2018, в 07:37

Источник

0

В любом случае новая таблица имеет преимущество в целостности данных. Производительность вам придется измерить. Это может или не может зависеть от ваших запросов. То же самое для индексации. Зависит от того, что вы делаете. Может быть 4 индекса, может быть один.
LoztInSpace 05 июнь 2018, в 05:50
0

Составной индекс по всем 4 столбцам (и в таком порядке) может быть полезен, но имейте в виду, что запрос, который не использует первые столбцы индекса, не может использовать последующие столбцы индекса.
Strawberry 05 июнь 2018, в 06:51
0

@LoztlnSpace, так что, если я сохраню название бренда в виде строки в таблице автомобилей или вместо этого сохраню его как int и присоединюсь к таблице брендов, разве это не повлияет на производительность?
aiiwa 05 июнь 2018, в 07:47
0

@Strawberry Straberry индексирование всех столбцов не похоже на индексирование вообще? не может идти с композитом, потому что не обязательно все 4 столбца попадут в мое предложение where
aiiwa 05 июнь 2018, в 07:48
0

Все 5 столбцов будут эквивалентны отсутствию индекса. Вам просто нужно определить, какой составной индекс будет работать для большинства ваших самых требовательных запросов. Вы можете решить это с научной точки зрения, но я, как правило, придерживаюсь подхода «отстой и посмотри».
Strawberry 05 июнь 2018, в 08:35

Показать ещё 3 комментария

Теги:

mysql

query-performance

1 ответ

Ещё вопросы

В любом случае новая таблица имеет преимущество в целостности данных. Производительность вам придется измерить. Это может или не может зависеть от ваших запросов. То же самое для индексации. Зависит от того, что вы делаете. Может быть 4 индекса, может быть один.
Составной индекс по всем 4 столбцам (и в таком порядке) может быть полезен, но имейте в виду, что запрос, который не использует первые столбцы индекса, не может использовать последующие столбцы индекса.
@LoztlnSpace, так что, если я сохраню название бренда в виде строки в таблице автомобилей или вместо этого сохраню его как int и присоединюсь к таблице брендов, разве это не повлияет на производительность?
@Strawberry Straberry индексирование всех столбцов не похоже на индексирование вообще? не может идти с композитом, потому что не обязательно все 4 столбца попадут в мое предложение where
Все 5 столбцов будут эквивалентны отсутствию индекса. Вам просто нужно определить, какой составной индекс будет работать для большинства ваших самых требовательных запросов. Вы можете решить это с научной точки зрения, но я, как правило, придерживаюсь подхода «отстой и посмотри».

Rick James · Accepted Answer · 2018-06-07T02-06-00.000Z

У меня был бы хотя бы INDEX(owner_name) поскольку он очень избирательный. Наличие INDEX(owner_name, model_year) не поможет сделать достаточно для этого типа данных. Существуют и другие случаи, когда я бы рекомендовал составной индекс из 4 столбцов.

"объем данных действительно высок". Если вы говорите, что есть 100K строк, то это не имеет большого значения. Если вы говорите миллиард строк, то нам нужно получить намного больше деталей.

"объем данных действительно высок". 10 запросов/секунд - Yawn. 1000/секунд - подробнее, пожалуйста.

2 таблицы против 1.

Целостность данных - кто-то может испортить данные в любом случае
Скорость - 1-байтный TINYINT UNSIGNED (диапазон 0,255) меньше, чем в среднем около 7 байт для VARCHAR(55) for бренда . But it is hardly enough smaller to matter on space or speed. (And if you goof and make . But it is hardly enough smaller to matter on space or speed. (And if you goof and make . But it is hardly enough smaller to matter on space or speed. (And if you goof and make Brand_ID a BIGINT", который 8 байт;! Ну упс)

Индексирование всех столбцов отличается от индексов. Но "индексирование всего" неоднозначно:

INDEX(user), INDEX(brand), INDEX(year),..., вероятно, будут эффективны для поиска или сортировки по любому из этих столбцов.
INDEX(user, brand, year),... делает особенно эффективным поиск по всем этим столбцам (с =) или определенным ORDER BYs.
Никакой индекс не требует сканирования всей таблицы для любого SELECT.

Другая интерпретация того, что вы сказали (плюс небольшое чтение между строками): Можете ли вы искать любую комбинацию столбцов? Возможно, non- = такие вещи, как year >= 2016? Или make IN ('Toyota', 'Nissan')?

Исследование http://mysql.rjweb.org/doc.php/index_cookbook_mysql

Аргумент для 1 таблицы

Если вам нужно сделать

WHERE brand = 'Toyota'
  AND year  = 2017

Тогда INDEX(brand, year) (в любом порядке) возможен и выгоден.

Но... Если эти два столбца находятся в разных таблицах (как и в примере с двумя таблицами), тогда у вас не может быть такого индекса, и производительность будет страдать.

Спасибо Рик Джеймс, приятно сказал. Просто для повторения, если я скажу все в одной таблице, будет "brand_name", которая является строкой. Если 2 таблицы, то "brand_id" + объединение. Производительность мудрая, 2 таблицы против 1 в этом случае? мои записи превышают 3 миллиона и растут.
только что проверил Помимо значения индекса, поиск в крошечной таблице брендов по строке и связывание с огромной таблицей с id (int) даст мне какое-то повышение производительности, как вы думаете?
@aiiwa - Это не будет иметь большого значения. Когда вы в следующий раз обнаружите проблему с производительностью, это, вероятно, будет в какой-то другой области.