Komentáře k příspěvku: MySQL nebezpečí průtokových tabulek, zamyšlení nad insert into … select from

Od: Otec Fura

Otec Fura — Sat, 19 Mar 2011 19:16:15 +0000

No tahle moje část kódu si sice řídila vlastní transakce, ale pokud existovala nějaká širší transakce, tak se do ní jen zapojila (PROPAGATION_REQUIRED) – tj. nemohl jsem zaručit vytvoření tabulky před transakcí .

Od: Maaartin

Maaartin — Thu, 17 Mar 2011 16:45:10 +0000

Samozrejme vytvoreni temp tabulky je DDL a dela commit, ale me se vzdy podarilo posunout to pred zacatek transakce. Netusim v jakym pripade by to nemelo jit. Takze si ji vytvoris, v ramci transakce naplnis a na konci vyprazdnis. Pokud ji potrebujes opakovane, pak musis jen dat pozor, abys ji nepouzil vickrat soucasne, ale to by se stat nemelo. Tez je treba dat pozor aby dva kusy kody od ruznych lidi – ci od jednoho – nepouzily omylem stejny nazev, ale to lze lehce resit vhodnou konvenci a pro jistotu grep-em. Pri poolovani pripojeni je treba zacit necim jako „DROP TEMPORARY TABLE IF EXISTS“, coz se hodi i tehdy kdyz si chces kus kodu opakovane vyzkouset.

Celkove mam pocit, ze temporalni tabulky jsou v MySql naprosta nutnost. Hodne prikazu jinak proste nejde napsat efektivne, protoze vnoreny dotazy jsou nekdy neskutecne pomaly (a to z toho duvodu, ze MySql to neumi udelat poradne). Databazisti se na temporalni tabulky mraci, ale me prijde ze je to obdoba lokalnich promennych – zvysuje citelnost a zprehlednuje kod. Samozrejme kdyby DB doopravdy umely lokalni promenne, tj. vcetne typu TABLE, tak by to bylo mnohem lepsi.

Od: Otec Fura

Otec Fura — Wed, 16 Mar 2011 09:52:09 +0000

Na MySql je vytvoření temporární tabulky považované za DDL příkaz, který přeruší aktuální transakci (commitne ji).

Od: lzap

lzap — Wed, 16 Mar 2011 08:56:41 +0000

„Jelikož jsem potřeboval zachovat transakčnost, nemohl jsem využít temporárních tabulek…“

Copak to nejde vytvořit záznam v temp tabulce v rámci jedné transakce? V Oracle i na Postgresu lze tedy vytvořit temp tabulku v rámci transakce (ona se dokonce na konci transakce smaže).

Zajímavé každopádně. Je to dobré vědět.

Od: Otec Fura

Otec Fura — Wed, 03 Feb 2010 09:03:09 +0000

Nepodporuje – má alternativní zápisy, ale takhle to přímo použít nejde:

http://dev.mysql.com/doc/refman/5.0/en/ansi-diff-select-into-table.html

Mě se to celé naštěstí podařilo předělat na vnořené selecty, které zdá se jsou i výkonnější než původní řešení – hádám právě pro to, že se to celé dokáže odehrát v paměti a nemusí se to fyzicky dostat do té odkládací tabulky, což by zahrnovalo IO operace.

Od: milos

milos — Wed, 03 Feb 2010 07:37:38 +0000

Resili jsme podobne problemy. Dost casto se zpracovani zrychlilo, kdyz jsme selecty (i updaty) rozdelili a ukladali mezivysledky.

Zda se ale, ze vsechny enginy musi resit stejne problemy a reseni se lisi jen v detailech. Takze zpusob ukladani na stranky a politika zamku bude podobna. Delam na Sybase a tzv. Deleted rows (ale i Forwarded rows – radky, ktere se nevesly po update a nachazeji se na jine strance, nez by mely byt) se nam objevuji take. U kmenovych tabulek jsme provedli po jedne reorganizaci, to je ale narocne na misto.

Nejlepsi asi bude mit casovou ulohu, ktera v klidove dobe provozu udela truncate. Ten je navic vyhodny i z hlediska indexu.

INSERT .. SELECT se navic v Sybase chova jeste lepe, nez SELECT…. INTO tabulka (nevim, zda to v MySQL jde).