Большая производительность таблицы против небольшой таблицы с некоторыми объединениями

Question

Большая производительность таблицы против небольшой таблицы с некоторыми объединениями

0

Я хочу знать, есть ли у меня большая таблица (50 столбцов и 50 миллионов записей), и я хочу использовать запрос выбора, и если я разделил свою большую таблицу на меньшую таблицу (20 столбцов и 50 миллионов записей) с некоторыми объединениями в некоторых небольшие таблицы (около 5 столбцов), и я хочу использовать один и тот же выбор, какой из этих манер лучше с точки зрения скорости?

Например:

Первый случай с огромной таблицей:

select username,password,nationalAdd from baseTBL

Второй случай с меньшей таблицей и несколькими соединениями:

select username,password,nationalAdd from baseTBL
inner join dependTBL1 on baseTBL.user_id=dependTBL1.id 
inner join dependTBL2 on baseTBL.national_id=dependTBL2.id

ahmadi morteza ali 05 апр. 2018, в 08:19

Источник

0

Рассматривали ли вы разделы dev.mysql.com/doc/refman/5.7/en/partitioning-overview.html
P.Salmon 05 апр. 2018, в 07:33
0

Там нет общего ответа. Попробуйте и посмотрите на ваш случай. Но гораздо важнее аномалии обновления. Предположим, пользователь меняет свой пароль. С вашим большим столом вы должны искать все случаи старого paswwrd и исправлять их все. Какой беспорядок! Если вы не строите хранилище данных, вы хотите избежать этих аномалий обновления. Рассмотрим нормализацию данных обучения.
Walter Mitty 05 апр. 2018, в 13:09

Теги:

mysql

database

database-design

1 ответ

Ещё вопросы

Рассматривали ли вы разделы dev.mysql.com/doc/refman/5.7/en/partitioning-overview.html
Там нет общего ответа. Попробуйте и посмотрите на ваш случай. Но гораздо важнее аномалии обновления. Предположим, пользователь меняет свой пароль. С вашим большим столом вы должны искать все случаи старого paswwrd и исправлять их все. Какой беспорядок! Если вы не строите хранилище данных, вы хотите избежать этих аномалий обновления. Рассмотрим нормализацию данных обучения.

Rick James · Answer 1 · 2018-04-26T19-15-00.000Z

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

Я адресую Вертикаль здесь.

Не массируйте массив по столбцам. Примеры: домашние/рабочие/номера сотовых телефонов; несколько адресов. Лучше иметь отношение 1: много к другой таблице.
Если у вас есть несколько столбцов, которые "редко" присутствуют, рассмотрите вертикальное разбиение на них, но оставьте строки вместо NULLs.
Если у вас будет предложение WHERE, касающееся обеих таблиц после раздела, это очень плохо для производительности. Сохраните все критерии поиска в главном разделе.
Если в какой-либо колонке много повторяющихся значений, а значения являются "длинными", рассмотрите "нормализацию" этих значений. (Это очень похоже на вертикальное разбиение, но оно считается другим.)
Не переустанавливайте. Пример: вывести город + состояние + почтовый_код + страну в единую таблицу Location, а не 4 таблицы.

Итог: ваш вопрос слишком расплывчатый, чтобы дать вам ответ, который относится к вашей схеме.