Я создаю базу данных, в которой будет около 30 таблиц, каждая таблица будет содержать десятки миллионов строк, а каждая таблица будет содержать один важный столбец и столбец первичного / внешнего ключа, чтобы максимизировать эффективность запросов перед лицом тяжелых обновления и вставки и интенсивно использовать кластерные индексы. Две таблицы будут содержать текстовые данные переменной длины, одна из них будет содержать сотни миллионов строк, а остальные будут содержать только числовые данные.
Поскольку я действительно хочу выжать каждую последнюю потерю производительности из имеющегося у меня оборудования (около 64 ГБ ОЗУ, очень быстрый SSD и 16 ядер), я подумывал о том, чтобы каждая таблица имела свой собственный файл, так что независимо от того, Я присоединяюсь к 2, 3, 4, 5 или более таблицам, каждая таблица всегда будет читаться с использованием отдельного потока, и структура каждого файла будет тесно выровнена с содержимым таблицы, что, как мы надеемся, минимизирует фрагментацию и сделает ее быстрее для SQL Server, чтобы добавить к содержанию любой данной таблицы.
Одно предупреждение, я застрял на SQL Server 2008 R2 Web Edition . Это означает, что я не могу использовать автоматическое горизонтальное разбиение, что исключает это как повышение производительности.
Будет ли использование одного файла на таблицу на самом деле максимизировать производительность, или я упускаю из виду характеристики встроенного механизма SQL Server, которые делают это избыточным?
Во-вторых, если выгодно использовать один файл на таблицу, почему create tableмне дается только возможность выделить таблицу для группы файлов, а не для конкретного логического файла? Это потребовало бы от меня создания отдельной файловой группы для каждого файла в моем сценарии, что наводит меня на мысль о том, что, возможно, SQL Server не предусматривает преимуществ, которые я предполагаю получить от выполнения того, что я предлагаю.
Моим первым предложением было бы не делать никаких предположений о производительности без проведения нагрузочного тестирования обеих конфигураций.
Думаю, что в прошлом я видел такие конфигурации (которые имеют смысл на бумаге), так это то, что размещение каждой таблицы в отдельном файле не окажет ощутимого положительного влияния на производительность ... и что дополнительная сложность компенсирует любое повышение производительности. даже если бы они были измеримы.
Наконец, когда дело доходит до вытеснения каждого снижения производительности из Sql Server, я отсылаю вас к следующей диаграмме (при условии, что мой Microsoft):
Любая потенциальная оптимизация, которая может быть сделана с точки зрения приложения, легко затмевает любую возможную оптимизацию на уровне конфигурации оборудования / базы данных ... поэтому сфокусируйте свое внимание соответствующим образом.
источник
Как отметили другие, нет прямой выгоды от одного файла на таблицу; Вот отличный обзор Стива Джонса о том, как возник этот миф: http://www.sqlservercentral.com/blogs/steve_jones/2009/10/13/sql-server-legend-data-files-and-threads/
Возможно, вы также захотите изучить секционированное представление, которое, я считаю, поддерживается 2008 Web Edition. Существуют некоторые приемы кодирования в секционированном представлении, но вы можете относительно легко имитировать многие функции секционированных таблиц.
источник
Я думаю, что отдельные файлы для каждой таблицы не принесут никакого выигрыша в производительности. Правильные индексы могут иметь потенциальное повышение производительности (чтение с диска) на сервере базы данных.
SQL Server 2008 R2 поддерживает сжатие? Если да, включите это.
Поправьте меня если я ошибаюсь.
источник