[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"question-postgresql-chto-takoe-mvcc-i-kak-on-realizovan-v-postgresql":3},{"id":4,"slug":5,"topicId":6,"topicSlug":7,"topicName":8,"topicEmoji":9,"question":10,"answer":11,"codeLang":12,"codeSrc":12,"important":12,"commonMistakes":12,"modernUsage":12,"difficulty":13,"tags":14,"related":15,"progress":16,"seo":17},946,"chto-takoe-mvcc-i-kak-on-realizovan-v-postgresql",28,"postgresql","PostgreSQL","🐘","Что такое MVCC и как он реализован в PostgreSQL?","MVCC (Multi-Version Concurrency Control) — механизм управления конкурентным доступом, при котором каждая транзакция видит свой «снимок» (snapshot) данных. Главный принцип: читатели не блокируют писателей, а писатели не блокируют читателей.\n\n> **Аналогия из жизни:** MVCC — это как Google Docs с историей версий. Каждый пользователь видит свою версию документа на момент открытия, а изменения других пользователей появляются только после «обновления страницы» (нового оператора или транзакции).\n\n### Реализация в PostgreSQL\n\nКаждая строка (tuple) содержит скрытые системные столбцы:\n\n- `xmin` — ID транзакции, которая создала эту версию строки\n- `xmax` — ID транзакции, которая удалила (или обновила) эту версию (0, если строка «живая»)\n- `ctid` — физический адрес строки на странице\n\n### Что происходит при UPDATE\n\n1. Текущая версия строки **не изменяется** — у неё устанавливается `xmax` равным ID текущей транзакции\n2. Создаётся **новая версия** строки с изменёнными данными, `xmin` = ID текущей транзакции\n3. Обе версии физически присутствуют в таблице\n\n```sql\n-- Наглядно: смотрим системные столбцы\nSELECT xmin, xmax, ctid, * FROM accounts WHERE id = 1;\n-- Результат: xmin=100, xmax=0, ctid=(0,1), id=1, balance=5000\n\n-- После UPDATE в другой транзакции (txid=200):\n-- Старая версия: xmin=100, xmax=200, ctid=(0,1)\n-- Новая версия:  xmin=200, xmax=0,   ctid=(0,5)\n```\n\n### Видимость строк\n\nТранзакция видит строку, если:\n- `xmin` зафиксирована (committed) и \u003C ID текущей транзакции (или это она сама)\n- `xmax` не установлен (0) или не зафиксирован, или > ID текущей транзакции\n\n### Последствия MVCC\n\n- При обновлении и удалении создаются «мёртвые» (dead) версии, которые занимают место\n- Необходим процесс VACUUM для очистки мёртвых версий\n- Индексы также содержат ссылки на все версии строк\n- Таблицы могут «раздуваться» (table bloat) без регулярного VACUUM\n\n### Преимущества MVCC\n\n- Читатели не блокируют писателей — высокая производительность при конкурентном доступе\n- Консистентные snapshot-чтения без блокировок\n- Это фундамент всех уровней изоляции в PostgreSQL\n\n> **На собеседовании:** MVCC — один из самых частых вопросов по PostgreSQL. Обязательно упомяните xmin\u002Fxmax и то, что UPDATE создаёт новую версию строки (а не изменяет существующую). Связка MVCC -> dead tuples -> VACUUM показывает системное понимание.","","middle",[7],[],null,{"title":18,"description":19,"ogTitle":18,"ogDescription":20,"keywords":21,"schemaAnswer":22,"featuredSnippetReady":23},"Что такое MVCC и как он реализован в PostgreSQL? — Gymterview","MVCC (Multi-Version Concurrency Control) — механизм управления конкурентным доступом, при котором каждая транзакция видит свой «снимок» (snapshot) данных. Главн","MVCC (Multi-Version Concurrency Control) — механизм управления конкурентным доступом, при котором каждая транзакция види",[7,13],"MVCC (Multi-Version Concurrency Control) — механизм управления конкурентным доступом, при котором каждая транзакция видит свой «снимок» (snapshot) данных. Главный принцип: читатели не блокируют писателей, а писатели не блокируют читателей.",true]