MySQL: многие таблицы или многие базы данных?

Ответ 1

Не должно быть существенной разницы в производительности между несколькими таблицами в одной базе данных и несколькими таблицами в отдельных базах данных.

В MySQL базы данных (стандартный SQL использует термин "схема" для этого) служат главным образом как пространство имен для таблиц. База данных имеет только несколько атрибутов, например. набор символов по умолчанию и сортировка. И это использование GRANT упрощает управление правами доступа для каждой базы данных, но это не имеет ничего общего с производительностью.

Вы можете получить доступ к таблицам в любой базе данных из одного соединения (при условии, что они управляются одним и тем же экземпляром MySQL Server). Вам просто нужно определить имя таблицы:

SELECT * FROM database17.accounts_table;

Это чисто синтаксическое различие. Он не должен влиять на производительность.

Что касается хранилища, вы не можете организовать таблицы в файл для каждой базы данных, как объясняет @Chris. При использовании механизма хранения MyISAM у вас всегда есть файл для каждой таблицы. С движком хранения InnoDB у вас либо есть один набор файлов хранилища, которые объединяют все таблицы, либо у вас есть файл для таблицы (он настроен для всего сервера MySQL, а не для каждой базы данных). В любом случае нет никакого преимущества или недостатка производительности для создания таблиц в одной базе данных по сравнению со многими базами данных.

В базе данных не так много параметров конфигурации MySQL. Большинство параметров, влияющих на производительность сервера, являются общими для всей области.

Что касается резервных копий, вы можете указать подмножество таблиц в качестве аргументов команды mysqldump. Может оказаться более удобным резервное копирование логических наборов таблиц на базу данных, без необходимости указывать все таблицы в командной строке. Но это не должно иметь никакого значения для производительности, только удобство для вас при вводе команды резервного копирования.

Ответ 2

Почему бы не создать отдельную таблицу для отслеживания ваших пулов (с идентификаторами PoolID и PoolName в виде столбцов и всего остального, которые вы хотите отслеживать), а затем на ваших 15-25 таблицах вы бы добавили столбец для всех них который будет внешним ключом к вам в таблицу пулов, чтобы вы знали, к какому пулу принадлежит эта конкретная запись.

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

Ответ 3

Если вам не нужен один набор таблиц с пулом poolID, как предлагал TheTXI, используйте отдельные базы данных, а не несколько таблиц, которые все делают то же самое.

Таким образом, вы ограничиваете разницу между доступом различных пулов к исходному оператору "use database", вам не придется каждый раз перекодировать ваши SELECT или иметь динамический sql.

Другими преимуществами этого подхода являются:

• Простое резервное копирование/восстановление
• Простой запуск/остановка экземпляра базы данных.

Недостатки:

• немного больше работы администратора, но не много.

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

Изменить: Если производительность - это единственное, что касается вас, вам нужно ее измерить. Возьмите представительный набор запросов и оцените их производительность.

Изменить 2: Разница в производительности для одного запроса между многими таблицами/многими базами данных баз данных будет небрежной. Если у вас есть одна база данных, вы можете настроить ее. Если у вас много баз данных, вы можете настроить ад из всех них.

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

Для меня лучшим вариантом является по-прежнему одна база данных с poolId, как предложила TheTXI, а затем несколько баз данных, в зависимости от ваших потребностей (в основном администрирования). Если вам нужно точно знать, какая разница в производительности между двумя вариантами, мы не можем дать вам этот ответ. Вам нужно настроить его и протестировать.

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

Ответ 4

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

Здесь есть действительно важный общий принцип: не думайте о том, как быстро это будет, профилируйте его.

Ответ 5

Я не слишком уверен, что полностью понимаю ваш сценарий. Вы хотите, чтобы все пулы использовали одни и те же таблицы, но просто отличались отличительным ключом? Или вам нужны отдельные пулы таблиц в одной базе данных с суффиксом в каждой таблице, чтобы отличать пулы?

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

Во-вторых, если ваш груз увеличивается (или по какой-либо другой причине), вы можете переместить пулы на отдельные физические машины с новыми серверами баз данных.

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

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

Ответ 6

Различие пулов по имени таблицы или помещению их в отдельные базы данных примерно такое же. Однако, если у вас много таблиц в одной базе данных, MySQL должен загрузить информацию о таблице и выполнить проверку безопасности во всех этих таблицах при входе/подключении.

Как уже упоминалось, отдельные базы данных позволят вам перемещать вещи и создавать оптимизацию, специфичную для определенного пула (т.е. сжатых таблиц). Это дополнительные административные издержки, но есть значительно больше гибкости.

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

Что касается истечения первичных ключей, вы всегда можете использовать составной первичный ключ, если используете таблицы MyISAM. Например, если у вас есть поле с именем groupCode (любой тип) и другое с именем sequenceId (auto increment) и создайте свой первичный ключ как groupCode + sequenceId. Последовательность будет увеличиваться на основе следующего уникального идентификатора в наборе групповых кодов. Например: AAA 1 AAA 2 BBB 1 AAA 3 CCC 1 AAA 4 BBB 2 ...

Хотя с большими таблицами вы должны быть осторожны в кэшировании и убедитесь, что файловая система, с которой вы работаете, обрабатывает большие файлы.

Ответ 7

Я не очень хорошо знаю mysql, но я думаю, что мне придется дать стандартный ответ производительности - "Это зависит".

Некоторые мысли (касающиеся только производительности/обслуживания, а не дизайна базы данных):

• Создание новой базы данных означает отдельный файл (или файлы) в файловой системе. Затем эти файлы можно поместить в разные файловые системы, если производительность одного должна быть отделена от других и т.д.
• Новая база данных, вероятно, будет обрабатывать кэширование по-разному; например. Все таблицы в одной БД означают общий кэш для БД, тогда как разделение таблиц на отдельные базы данных означает, что каждая база данных может иметь отдельный кеш [очевидно, что все базы данных будут использовать одну и ту же физическую память для кеша, но может быть предел на базу данных и т.д.].
• В связи с отдельными файлами это означает, что если один из ваших наборов данных становится более важным, чем другие, его можно легко отнести на новый сервер.
• Разделение баз данных дает дополнительное преимущество, позволяя вам быстрее развертывать обновления по сравнению с единой базой данных.

Однако, напротив, наличие нескольких баз данных означает, что сервер, вероятно, будет использовать больше памяти (поскольку он имеет несколько кешей). Я уверен, что существует много "минусов" для подхода с несколькими базами данных, но теперь я рисую пробел.

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

Ответ 8

Учитывая ограничения, которые вы разместили на нем, я предпочел бы развернуть больше таблиц в существующей базе данных, вместо того, чтобы подключаться к нескольким базам данных. Управление строками подключения. ТЕНДЬ будет сложнее, в дополнение к управлению различными оптимизациями базы данных, которые у вас могут быть.

Ответ 9

FTR, в обычных условиях я бы взял подход, описанный TheTXI.

В ответ на ваш конкретный вопрос, однако, я нашел, что он зависит от использования. (Копай, я знаю, но выслушай меня.)

Единственная база данных, вероятно, проще. Вам нужно будет беспокоиться только по одному соединению и все равно придется указывать таблицы. При определенных условиях несколько баз данных могли бы быть быстрее.

Если бы я был вами, я бы попробовал оба. Мы не сможем дать вам полезный ответ.