6 komentáře “MySQL nebezpečí průtokových tabulek, zamyšlení nad insert into … select from

  1. 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í :( .

  2. 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.

  3. „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.

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

  4. 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.

  5. 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).