Zaprvé si myslím, že by bylo užitečné jako pozadí přečíst si o kontrole souběžnosti více verzí (MVCC) jako pozadí této odpovědi.
InnoDB implementuje MVCC, což znamená, že může používat nezamykatelné čtení pro běžné SELECT . To nevyžaduje vytvoření „snímku“ a ve skutečnosti InnoDB nemá žádný skutečný koncept snímku jako objektu. Místo toho každý záznam v databázi sleduje své vlastní číslo verze a udržuje "ukazatel převrácení" na záznam "zrušit protokol" (který může nebo nemusí stále existovat), který upraví řádek na jeho předchozí verzi. Pokud je potřeba starší verze záznamu, přečte se aktuální verze a sledují se tyto ukazatele a záznamy se vrátí zpět, dokud nebude vytvořena dostatečně stará verze záznamu.
Normálně systém neustále čistí tyto protokoly zpět a znovu využívá místo, které zabírají.
Kdykoli jakékoli dlouhotrvající transakce (poznámka, nemusí to být nutně jeden dotaz), musí být protokoly zpět uchovávány (ne vyčištěny), aby bylo možné dostatečně znovu vytvořit dostatečně staré verze všech záznamů pro uspokojení dané transakce. Ve velmi vytíženém systému se tyto protokoly zpět mohou velmi rychle nahromadit a spotřebovat gigabajty místa. Navíc, pokud jsou konkrétní jednotlivé záznamy velmi často upravovány, může vrácení tohoto záznamu na dostatečně starou verzi, aby vyhovovalo dotazu, vyžadovat mnoho aplikací pro vrácení zpět (tisíce).
To je to, co dělá „dlouhodobé dotazy“ drahé a odsuzované. Zvýší spotřebu místa na disku pro uchování protokolů zpět v systémovém tabulkovém prostoru a budou fungovat špatně kvůli aplikaci undo log record, která po přečtení vrátí verze řádků.
Některé databáze implementují maximální množství prostoru pro protokol zpět, který lze spotřebovat, a jakmile dosáhnou tohoto limitu, začnou zahazovat starší záznamy protokolu zpět a znehodnotit probíhající transakce. Tím se uživateli vygeneruje chybová zpráva „snímek je příliš starý“. InnoDB žádný takový limit nemá a umožňuje neomezenou akumulaci.