Основное правило состоит в том, чтобы разделить файлы на разные тома, чтобы избежать конфликтов, однако величина увеличения производительности, которую вы получаете, сильно варьируется в зависимости от подсистемы ввода-вывода и рабочей нагрузки. Например, несколько файлов на одном физическом шпинделе будут отстойными с точки зрения производительности, но та же схема, что и для тома, находящегося на SAN LUN с несколькими сотнями дисков из массивов RAID 10, может быть просто идеальной. Счетчики длины очереди на диске - ваш друг, самый простой способ узнать, есть ли у вас узкое место ввода / вывода.
Вы смотрите на шаблоны ввода-вывода в базах данных - только для чтения, в основном для чтения, для чтения-записи, в основном для записи, только для записи - и основываетесь на этом. Вам также необходимо выбрать правильный уровень RAID и убедиться, что смещения дисковых разделов, размер полосы RAID и размер единицы размещения NTFS установлены правильно. Некоторым людям нравится разделять некластеризованные индексы в отдельной файловой группе, но прирост производительности здесь варьируется, как я объяснил выше.
Как и производительность, вы должны учитывать управляемость и возможность восстановления. Наличие одного файла монолитных данных для базы данных объемом 100 ГБ означает, что ваша единица восстановления - это файл. Разделение его на 4 файловых группы по 25 ГБ означает, что вы можете использовать частичную доступность базы данных и частичное восстановление, чтобы восстановить только одну файловую группу в случае ее повреждения. Разделив таблицы и индексы по нескольким файловым группам, вы также можете ограничить, какие части базы данных подвержены операциям обслуживания (например, удаление фрагментации индекса).
Tempdb - это особый случай, и я укажу вам на мой пост в блоге, который объясняет все, почему и как разделить tempdb - существует множество заблуждений.
Не давая вам рекомендации «широкого обобщения», я укажу вам на несколько статей и постов в блоге, которые вы можете прочитать:
Надеюсь, это поможет вам!