Допустим, у нас есть несколько серверов MySQL, один мастер и несколько подчиненных. Таблица-член, которая содержит более 5.000.000 человек.
Есть ли какие-либо причины (производительность, атомарность и т. Д.) Для использования повторяющихся таблиц, таких как member_1, member_2, member_3, а затем случайного переключения при выполнении операций с ними? (особенно запрос SELECT)?
По соображениям производительности да, это было бы быстрее.
Фактически, именно так несколько лет назад использовались таблицы MERGE.
У вас будет несколько таблиц, например member_1, member_2 ... и таблица-член, которая будет механизмом MERGE.
Вы бы запросили отдельные таблицы, если бы знали, что данные, которые вы ищете, будут там: например, если у member_2 есть участники, зарегистрированные на сайте 6 месяцев или раньше, и это поиск, который вы хотите выполнить.
Или вы могли бы выполнить поиск в таблице MERGE, когда вам нужно выполнить поиск по всей таблице или разделение таблицы не было тем, что было необходимо. Например, если фамилия участника - Смит.
Вы должны быть осторожны при использовании MERGE, если вы планируете использовать его для повышения производительности, потому что, хотя это может помочь в некоторых случаях, в других случаях это может повредить.
Сказав, что РАЗДЕЛЕНИЕ - это новая технология, которая очень много для вас делает.
Посмотрим, поможет ли это тебе.
Единственный раз, когда я когда-либо считал приемлемым дублировать таблицу, это при тестировании результатов сложного оператора SQL на ней. Даже в этом случае вы обычно делаете это в тестовой базе данных, а не в тестовой таблице в производственной базе данных.
Я не знаю конкретно для MySQL, но некоторые механизмы БД (например, Oracle) могут разбивать таблицы. Это немного похоже на то, о чем вы говорите. Разделение может улучшить производительность, если вы знаете, что большую часть времени будете работать только с подмножеством данных.
Тем не менее, будьте очень осторожны. Если все сделать неправильно, перегородки могут снизить производительность. В хорошем разделе могут быть записи, архивируемые каждый год, ключом к разделу может быть год записи.
Я не знаю, возможно ли это в MySQL, но разбиение таблицы на разделы может быть полезным и даже повысить производительность. Давайте рассмотрим географическое приложение, в котором вы храните адреса людей 48 смежных нижних штатов.
Тогда у вас будет то, что мы можем назвать базовой таблицей, которая будет разделена на 48 других таблиц, по одной для каждого состояния.
В зависимости от определения раздела эта базовая таблица после SELECT «знает», к какой таблице выполнять запрос, чтобы иметь необходимые информационные данные в зависимости от того, какое состояние запрашивается. Это похоже на интеллектуальный интерфейс, который вы можете запросить, и запрос просто перенаправляется в нужную базовую таблицу, не сообщая пользователю об этой базовой таблице.
Будьте осторожны, я говорю не о создании VIEW, а о разделении таблиц данных, что совсем другое дело.
В конце концов, такое разбиение должно улучшить производительность.
Теперь перед нами таблица с данными в 5 000 000 строк. Это не должно сильно повредить производительности, если ИНДЕКСЫ подходят для нужд запроса. Возможно, вам сначала следует поискать оптимизацию ИНДЕКСОВ. Впоследствии, если некоторые проблемы с производительностью все еще присутствуют, рассмотрите возможность разделения таблицы на основе различимого значения.
Here's some details about partitioning database tables in SQL Server, это может дать вам некоторое представление о MySQL. И here's an interesting article about performance partitioning in MySQL.