⚡ Подходы разные:
- MySQL (InnoDB) стремится всё держать под своим контролем
- Postgres больше доверяет операционной системе
MySQL / InnoDB
- Своя память под кэш:
innodb_buffer_pool_size обычно = 70%+ RAM на выделенном сервере - Обход кэша ОС: с
innodb_flush_method='O_DIRECT' InnoDB работает напрямую с диском - Двухсекционный LRU: страницы сначала в
old, только потом (через innodb_old_blocks_time`) в `young. Это спасает от «выметания» кэша при больших сканах Postgres
- Внутренний кэш + page cache ОС:
shared_buffers обычно около 30% RAM, остальное оставляют ОС - Clock-sweep: у страницы счётчик обращений, уменьшается при «прокрутке часов». Когда падает до нуля — страница освобождается
Практические выводы
- Bulk-операции: InnoDB устойчивее к «пробиванию» кэша, в Postgres часть нагрузки идёт в кэш файловой системы
- Тюнинг памяти: в MySQL раздувают buffer pool, в Postgres shared_buffers умеренный, а остальное доверяют ОС
Что стоит проверить в бенчмарках Postgres
- Размер
shared_buffers: 4% / 10% / 30% / 50% RAM - Сценарии: OLTP, последовательные сканы, смешанные нагрузки
- Рабочий набор: меньше / равен / больше доступной RAM
- Метрики: TPS/QPS, p95/p99 латентность, hit ratio, про
https://github.com/postgres/postgres/blob/master/src/backend/storage/buffer/README