Назад | Перейти на главную страницу

Слишком много таблиц в базе данных Mysql может повлиять на производительность?

Наличие слишком большого количества таблиц (например, 200) в одном экземпляре базы данных Mysql может снизить ее производительность?

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

Количество столов не имеет такого значения, как:

  1. Какие запросы вы выполняете - вы вряд ли будете запрашивать все 200 в рамках одного запроса
  2. Общая нагрузка запросов на систему в любой момент времени.

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

В общем, 200 таблиц не должны быть проблемой, но это зависит от ряда вещей.

Выделенный сервер MySQL по сравнению с сервером, совместно используемым с другим программным обеспечением, 128 МБ против 128 ГБ ОЗУ и т. Д., Небольшие таблицы с несколькими записями против таблиц с большими двоичными объектами и миллионами строк.

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

MyISAM обычно имеет три файла на таблицу .frm, .MYD, .MYI.

INNODB в обычном режиме имеет .frm со всеми данными, хранящимися в центральном файле

INNODB в одном файле в режиме таблицы имеет .frm, .idb

table_open_cache - это количество таблиц, которые могут быть открыты одновременно (по умолчанию 64). Это может быть больше, чем количество таблиц в вашей схеме, поскольку это связано с тем, сколько соединений запрашивает БД. 100 соединений, соединяющих 3 таблицы, могут означать, что у вас есть 300 кешированных таблиц плюс любые временные таблицы. Как правило, чем сложнее схема или соединения, тем больше число.

open-files-limit Я обычно устанавливаю это значение на 4x table_open_cache, что должно быть достаточно большим, нежели пытаться определить точное значение.

Ограничение обработки файлов операционной системы для пользователя mysql также может быть проблемой (в Linux значение по умолчанию часто может быть 1024, ulimit -n для отображения ограничений пользователя), это может вызвать проблему с большим количеством таблиц, когда оно меньше числа mysql требует. Это должно быть как минимум такое же, как ограничение на количество открытых файлов.

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

http://dev.mysql.com/doc/refman/5.1/en/table-cache.html

Надеюсь, поможет

Для индекса каждой таблицы MySQL имеет свой собственный индекс. Индекс требует памяти для хранения и использования, а для индексов существует глобальный предел. Когда имеется много таблиц, все индексы не могут находиться в ОЗУ, поэтому они отправляются на диск, что напрямую влияет на производительность. Попробуйте поднять это в my.cnf: key_buffer_size=256M: это объем ОЗУ, отведенный для хранения индексной информации.

Может это? Конечно. Но насколько сильно зависит от вашего приложения и его шаблонов доступа, а также от того, используете ли вы myisam или innodb, и находится ли innodb в режиме файл на таблицу или нет, а также от размера журналов innodb. Вам нужно будет сообщить нам больше подробностей.

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

Гораздо более вероятно, что ваши запросы не оптимизированы должным образом. Я бы посоветовал включить log-slow-queries и log-queries-not-using-indexes. Когда вы определяете медленные запросы, используйте explain возможность просмотреть план запроса для этих запросов, чтобы определить места, где отсутствуют индексы.

Видеть http://dev.mysql.com/doc/refman/5.0/en/slow-query-log.html Больше подробностей.