caHek2x,

у тебя уже мускл начал медленно работать??? типо изза команды вставки, запрос к сайту обрабатываеться 2 сек, изза того что вставка 1.5 сек?
тогда не лезь.

внесу ясность работы с винчестером субд.

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

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

когда нашей програмой являеться субд, вноситься маленькое но в работу с ФС - субд сама пишет файл, не пользуясь оптимизациями работы с ФС заложенные в ОС.

поэтому логика(опыт) работы с файлами на наших програмках не подходит сдесь.

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

АХТУНГ
знаете редкие случаи, когда изза отключения питания ошибка в файле на винчестере может выйти, или при вытягивании влешки когда на наеё чтотописалось...
вот оно и есть - файловый буфер потерялся при отключении = внём были данные , которые с точки зрения приложения писавшего в файл, записаны, в реальности ещо нет. вот их мы и теряем.

так вот теперь понятно что сделает значение 2!? оно посути отключает со стороны субд контроль над реальной работой с файлом данных.

это не означает что как в доках написано последние 1-2 секунды вы потеряете. возможно и больше. тут уже как какрта ляжет, всё зависит от того кто и сколько и куда и как пишет в другие файлы. для ОС файл базы не приоритетней, его файловый буфер будет обрабатываться на равне со всеми. если другой софт перегрузит винчестер, что файловые буферы разростуться до 50мг, ну сами можете прикинуть сколько последних секунд вы потеряете, особено если авария с ос возникнет имено по принципу

винчестер начал барахлить ,действия с ним стали медленными, фалйовые буферы ос медлено начинают наполняться, ибо винт не успевает делать всё что нужно, дорастают до таких размеров что оперативка заканчиваеться ии... нессать! ОС в этом случае умеет аварийно блок памяти с файловыми буферами(кучей) скинуть на винчестер, мол потом разребу, но винчестер наш барахлит, эта операция пройдёт с ошибкой, и файловым буферам хана - при таком развитии событий, вы можете и последние пол часа потерять, если работа вплане обьёма записей была не большой, а винчестер просто начал подыхать конкретно.
но это всё не частые события. так что обычно да, секундами меряеться потеря при аварии ОС
авария субд не приведет к потере, ибо с точки зрения субд при значении 2 данные записаны!
только авария ОС даст потерю.

ну а теперь значение 0

СУБД пытаеться по сути помочь ОС оптимизировать запись на винчестер, суть сводиться к тому, что если в какуюто таблицу мы делаем вставку(длина записи и бабуйня прочая на 100 байт) раз в секунду, то впринципе субд, может ваще копить таких вставок много и долго, не давая данные на винчестер...тоесть как ОС буферизирует работу с файлами, тут сама субд ещо начнёт это делать.
в этом случае, таки да, повышение реально произойдёт и заметно

при значении 2, тут смотря какая специфика работы у субд...если у неё файл на 300гб, и изменения мелкие равномерно по всему файлу, то сами понимаете, буферизация субд мало что даст...ведь один чорт все эти мелкие изменения попадают в совершенно разные части поверхности диска. а вот если буферы ОС накапливают изменения на винчестере, которые попадают в один или смежные кластеры(особено для САТА винчестеров последнее-смежность) то выигрыш будет - вместо нескольких обращений к шдд, будет сделано за одно.

при значении 0 впринципе тоже можно не заметить прироста, но обычно он всётаки будет!!!
данные индекса храняться в одном месте на шдд, и субд про это знает, она может изменения в индексе буферизировать очень долго, чего не произойдёт при значение 2
ибо ОС понятия не имеет что это за мелкие изменения поступают... она в цикле пытаеться все файловые буферы как можно быстрее сохранить на диск. при слабой нагрузке на шдд, по сути буферы ОС будут всегда пустые.
можно сказать что суть буферизации ОС(значение 2) - упростить работу шдд под нагрузкой(когда буферы не успевают быстро на шдд падать, в них изменения одних и тех же кластеров/смежных, агрегируються)

суть буферизации субд - вне зависимости от текущей нагрузки шдд, уменьшить его работу.

==========
поэтому, стоит 1 пускай стоит

если у тебя будет проблема на сервере именно изза шдд, ставишь 2 - для того оно и есть.

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