Ответы:
В целом, больше всего, что у вас есть, снизит производительность. Тем не менее, 200 кажется довольно небольшим числом. 2000 могут быть настоящим хитом производительности и определенно 20000. В целом, тем не менее, вы должны сохранять небольшое количество таблиц, поскольку MySQL может обрабатывать очень большое количество строк в таблице.
Количество таблиц не так важно, как:
Наличие избыточных таблиц означает, что память и место на жестком диске могут быть восстановлены и использованы для других целей. Имейте в виду, что денормализация ваших таблиц увеличивает риск неверных данных, потому что вы избавляетесь от ссылочной целостности.
В целом, 200 таблиц не должны быть проблемой, но это зависит от ряда вещей.
Выделенный сервер MySQL против сервера, совместно используемого с другим программным обеспечением, 128 МБ против 128 ГБ ОЗУ и т. Д., Небольшие таблицы с несколькими записями против таблиц с BLOB-объектами и миллионами строк.
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 для получения более подробной информации.