Максимальное количество работоспособных таблиц в SQL Server и MySQL

Question

Я знаю, что в SQL Server максимальное количество «объектов» в базе данных составляет чуть более 2 миллиардов. Объекты содержат таблицы, представления, хранимые процедуры, индексы, между прочим. Меня совсем не волнует выход за пределы 2 миллиардов объектов. Однако я хотел бы знать, что SQL Server страдает от снижения производительности из-за большого количества таблиц. Имеет ли каждая добавляемая вами таблица снижение производительности или в принципе нет разницы (при условии постоянного объема данных). У кого-нибудь есть опыт работы с базами данных с тысячами таблиц? Мне также интересно то же самое о MySQL.

Answer 1

Без разницы, при условии постоянного количества данных.

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

Производительность определяется запросами и индексами (на самом базовом уровне): не количество объектов

Answer 2

С точки зрения максимального количества таблиц у меня была база данных с 2 миллионами таблиц. Нет производительности вообще. мои столы маленькие, около 15 МБ каждый.

Answer 3

Я сомневаюсь, что у SQL Server будут проблемы с производительностью при работе с тысячами таблиц, но я уверен, что это так.

Я без проблем работал с базами данных с сотнями таблиц в SQL Server.

Answer 4

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

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

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

Answer 5

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