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

MySQL innodb_file_per_table и «слишком много таблиц»

Я использую MySQL (5.0, но я не думаю, что это имеет значение для чего-либо после 4.1), и я видел советы по использованию innodb_file_per_table вариант конфигурации для таблиц InnoDB. Обычно это делается для того, чтобы вы могли лучше контролировать, сколько дискового пространства используется таблицами InnoDB, поскольку это пространство никогда не восстанавливается, даже если эта таблица позже будет удалена.

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

У меня есть приложение, которое работает для множества разных клиентов (около 50, но, скорее всего, приблизится к 100), и в каждой базе данных 135 таблиц. 13 500 столов - это слишком много?

Это хорошее количество таблиц, но здесь нужно помнить, что не все из них будут открыты сразу - в большинстве случаев вы устанавливаете параметр MySQL для открытых файлов примерно на 300-500, а сам MySQL сохранит самые активные в вашей системе в пуле таблиц памяти (кэш, если вы will) очень похоже на то, как ядро ​​хранит страницы памяти для приложений.

Я лично твердо верю в то, что файл за таблицей является инструментом управления системой; хотя у него есть свои компромиссы, как вы правильно заметили, возможность сохранять таблицы каждого клиента отдельными (вы даже можете распределить их по разным дискам - RAID, SAN, DAS и т. д. - по базе данных клиентов!), поддерживать необработанные таблицы вручную, если необходимо, оптимизируйте их, если необходимо, и так далее в конце дня. Основная цена, которую вы платите, - это большее количество вызовов fsync () во время записи, что может снизить производительность, если у вас также записывается много таблиц, но в целом это не так уж плохо.