Как уже упоминалось ранее, наиболее узким местом для производительности является поиск на диске. Эта проблема становится все более и более очевидной по мере того, как объем данных увеличивается настолько, что эффективное кэширование становится невозможным. Для крупных баз данных, где доступ к данным осуществляется более или менее случайным образом, можно с уверенностью сказать, что потребуется по меньшей мере один поиск по диску для чтения и пара поисков по диску для записи некоторой информации. Чтобы свести эту проблему к минимуму, следует использовать диски с малыми временами поиска.

Можно увеличить количество доступных дисковых "блоков" (и, таким образом, уменьшить нагрузку на диски). Это делается либо путем установления символических ссылок на разные диски, либо использованием RAID (stripe).

Для надежности можно использовать режим RAID 0+1 (разделение на RAID-блоки + зеркальное отображение), но в этом случае будет необходимо 2*N дисководов для хранения информации N дисководов данных. Если возможности позволяют, то такой вариант выбора - наилучший! Однако при этом могут понадобиться также инвестиции и в программное обеспечение для эффективного управления этим объемом оборудования.

Существует еще одна неплохая возможность: хранить не слишком важные данные (которые могут быть воспроизведены) на диске RAID 0, а действительно важные данные (такие как информация о хостах и журналы) - на диске RAID 0+1 или диске RAID N. Использование RAID N может оказаться проблемой, если у вас много операций записи, потому что обновление битов четности занимает время.

Можно также задать требуемые параметры для используемой базой данных файловой системы. Легко поддается изменению монтирование файловой системы с опцией noatime. Использование этой опции позволяет пропускать обновление при последнем обращении в данном режиме и тем самым избежать поиска по диску.

Под Linux можно получить намного большую производительность (под нагрузкой нередко вплоть до 100%), используя hdpram для конфигурации интерфейса диска! Приведенные ниже опции для hdparm зарекомендовали себя как очень полезные для MySQL (и, возможно, для многих других приложений):

hdparm -m 16 -d 1

Следует учитывать, что производительность/надежность при использовании приведенных выше рекомендаций зависит от конкретного оборудования, так что мы настоятельно рекомендуем вам основательно протестировать систему после использования hdparm! Для получения более подробной информации о применении hdparm, обращайтесь, пожалуйста, к соответствующей странице руководства! Некомпетентное применение hdparm может привести к разрушению файловой системы. Прежде чем экспериментировать, сделайте полную резервную копию!

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

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