MySQL - pomalé importování 13GB databáze

[Ivan Nový]

To by určitě šlo, stejně jako na začátek a konec přidat ty sql modifikátory. Je to spíše pro příště...

A nebylo by to přes csv a LOAD DATA rychlejší? V takové velikosti nemám vyzkoušené. Nemáte s tím nějaké zkušenosti?

[Reklama]

[gl]

ja pro import pouzivam toto, je to opravdu rychle
https://phpfashion.com/extreme-rychly-load-sql-file

Proč by to mělo být rychlejší?

[nnnmm]

vypni vsetky kotroly tj triggery, FK, PK a indexy (tie si nahodis neskor - tie su pravdepodobna pricina preco to tak dlho trva) samozrejme autocommit

13 giga v dumpe ~= 13 giga v db

zalezi na datach a indexoch zvaca je to ovela viac

[dustin]

A nebylo by to přes csv a LOAD DATA rychlejší?

Takový formát právě generuje ten mysqldump --tab. Jeho nalévání přes load data infile nebo mysqlimport je znatelně rychlejší. Navíc automaticky generuje strukturu (sql soubor) a data (txt soubor) pro každou tabulku odděleně, lépe se to na backup serveru deduplikuje, než jeden obří dump i s minimem změn.

[db]

tak si predstavte, ze ten import by bezel jeste ted i po "optimalizaci"

nemel jsem nervy s tim saskovat, tak jsem ten dump rozparsoval pythonem a extrahoval sloupce ktere potrebuju.

ten python script nebezel ani 10 minut.

[Reklama]

[mysqld]

Je to ostre zelezo nebo virtual? Na virtualu pomaha pred importem restartnout mysql demona, rozdil v rychlosti byva bratru nekdy i 5 nasobny !

[Vladimír Drgoňa]

Osobne by som sa pozrel ako je nastavený parameter:

Kód: [Vybrat]

innodb_flush_log_at_trx_commit

Ak je tam 0, je to bezpečnejšie ukladanie, ale na takéto importy príliš pomalé. Dal by som tam hodnotu 2 aspoň počas importu. Moje servery nastavujem na 1 a nikdy sa mi nestratili dáta, samozrejme servery sú vždy na UPS.

[dustin]

0 chce radic s write kesi a baterkou nebo ssd.