Dotaz: Jak nahradit v Mysql cca ve 100 000 000 řádcích znak

[Amatherus]

Poradil by někdo sql dotaz, který by v tabulce s názvem insert a sloupci s názvem url přepsal znak _ za znak - ? Děkuji

Odpovědi

[l0gik]

To je to takovej problém se kouknout do dokumentace na funkce mysql?

UPDATE `insert` SET url = replace('_', '-', url)

[Amatherus]

Díky ale tohle nechci, za prvé to máš špatně, má to být takto ;) a za druhé ten příkaz umře, proto to s ním nejde

UPDATE `insert` SET url = replace( url, '_', '-')

[Marek]

To znamena co, ze umre? Dotaz je v poradku, takze jestli je nekde nejaky problem, je treba ho vyresit a ne se snazit najit zpusob jak to obejit. 100M radku neni zas takovy des.

[Amatherus]

No myslím tím to, že pokud již zmíněný sql dotaz spustím, tak se provede pouze na cca 500 000 row, nasleduje ukončení bez error hlášky, zkoušel jsem projet i kontrolu celé db pomocí mysqlcheck a žádný problém nezjištěn.

[Radek Miček]

A rozdělit ho do několika dávek nepomůže?

[Šangala]

Jak ho spouštíte?

[Amatherus]

Pouštím to přímo z command line...

[Marek]

Nejedna se o timeout? Jak sql poustite? Jak jsou na tom systemove prostredky ve chvili, kdy to spadne? Neni na sloupci nejaky index, ktery by vse neumerne zpomaloval?

[Amatherus]

Nejedna se o timeout?

myslím že určitě ne

Jak jsou na tom systemove prostredky ve chvili, kdy to spadne?

nerozumím

Neni na sloupci nejaky index, ktery by vse neumerne zpomaloval?

taky nerozumím

[Šangala]

Index a na upravovaném sloupci to může hodně zpomalit, ale nemělo by se to ukončit „jen tak“.
Rychlé řešení, které nedoporučuji je …ORDER BY `ID` LIMIT 0,200000; …ORDER BY `ID` LIMIT 200000,400000; atd…

[předevčírem]

limit ma syntaxi offset, row_count, a muze se stat, ze se nektere radky nezpracuji, trebas pokud odeberes zaznamy mezi dvema updaty. lepsi je takto: where id > 0 and id <= 10000, where id > 10000 and id <= 20000, ... az do max(id)

[Šangala]

Ano - chce to kontrolu,. S WHERE zas může být problém, že ID jsou velmi nepravidelně rozmístěna a bez nějaké hlubší analýzy se bude muset příkaz volat o hodně vícekrát.
Bral jsem to jako rychlé řešení a není problém si na konci ověřit kolik řádků obsahuje ještě daný znak.

[l0gik]

Myslím že ne na základě čeho? V každém případě, spusťte to na několikrát s limitem...

[Josef Kufner]

myslím že určitě ne

To jsi napsal pěknou blbost

[pavlix]

Toto mělo být součástí dotazu, aby to nebyl totálně lamerský dotaz, který samozřejmě dostane správnou odpověď, která ti z nějakého nefunguje :).

[Heron]

To je dost zvláštní, ten dotaz by měl běžet v transakci a pokud "umře", tak se provede rollback celé transakce. Stav, kdy to umře v polovině a některé řádky jsou změněné a jiné ne je hodně špatný.

[jekub]

Urcite bych do update pridal jeste podminku, zda url vubec nahrazovany znak obsahuje. Mozna to ale MySQL dela sama (neznam) a proto opravi jen tech 500k radku.

ps: insert jako jmeno tabulky je takove ... svojske

[l0gik]

Blbina. Na to zjistit jestli tam znak je se to stejně musí přečíst a update řádek kterej nic nedělá je levnej (v mysl snad nic neprovede).

[jekub]

Takze napr.

update `insert` set url=url

nic nedela? A bude to levne i v pripade existence triggeru a constraintu na tabulce, resp. sloupci?

[DK]

to je jako reagovat na namitku, ze tygr v zoo ti nic neudela, vetou "takze kdyz potkas tygra v africe, tak ti nic neudela? a ani s organy?"

[jekub]

Takze update na celou tabulku je v MySQL stejny jako update na vybrane zaznamy (tj. pouze ty, ktere obsahuji znak _). Zadne zamky, zadna konkurennce? Zadne zbytecne fyzicke zapisy na disk?

[jekub]

a kdyz uz sme u tech analogii, tak v zoo tygr nejspis navstevnikum (~ uzivatelum) nic neudela, osetrovatel (~ spravce) by mel ale byt obezretny a k tygrovi se chovat jako by byl "na volno" (ten tygr).

[Heron]

Nemusí dělat hledání toho znaku, to by bylo hodně drahé. MySQL client zobrazuje kolik řádků se změnilo (a nikoliv kolik řádků bylo součástí datasetu).

Jo, pojmenovat tabulku klíčovým slovek je hodně ... přidělávající problémy.

[předevčírem]

kolik je ti, prosim te, let, ze si myslis, ze tady budeme cist tvoje myslenky? ptal ses na sql dotaz, dostal jsi sql dotaz. jestli jsi ve skutecnosti chtel vedet, proc tvuj sql dotaz nedobehne, tak jsi to mel napsat do dotazu, a ne ze se zeptas na sql dotaz, dostanes sql dotaz, a ty na to napises, ze tohle nechces, ale vlastne chces neco uplne jineho, co s puvodnim dotazem vubec nesouvisi.

[Ivo]

UPDATE `insert` SET url = replace('_', '-', url) where url like '%_%';

a spustil by som to niekolko krat za sebou kym to nevrati 0 riadkov updated

[kuka]

Hm tak toto je v zasade pouze prepsane not null, podtrzitko v like matchuje libovolny znak.

[Šangala]

Doufám, že máte zálohu…

[jekub]

proc?

[l4m4]

No schválně, co ten příkaz udělá?

[pavlix]

+1

[Šangala]

Je tak těžké si to zkusit?
Uvedený příkaz má v sobě velkou chybu, díky které ničí nalezené url a chybu, díky které ničí všechna url.
A napovím těmito ukázkami:

SELECT REPLACE('_','-','Very important string') AS suprise;

+---------+
| suprise |
+---------+
| _       |
+---------+

SELECT COUNT(*) FROM `kuk2`;

+----------+
| COUNT(*) |
+----------+
|        5 |
+----------+

SELECT * FROM `kuk2` WHERE `t` LIKE '%_%';

+------+
| t    |
+------+
| aaa  |
| a%a  |
| a-a  |
| a_a  |
| %_%  |
+------+

[Heron]

a spustil by som to niekolko krat za sebou kym to nevrati 0 riadkov updated

Proboha! SQL je deterministické, pokud je ten příkaz napsaný správně, tak se transkakce dokončí celá už napoprvé a pokud není, tak se změny vrátí zpět. Neexistuje žádná situace, kdy se to zkouší, dokud to omylem nedoběhne.

[d.c.]

Doufam, ze to nebudete brat jako OT, ale resil jsem pred nedavnem podobny problem (jen to bylo asi 130 mil. radku) a na testovacim stroji jednoduchy update dobehl asi do 30 % po dvou dnech (kdy jsem se k tomu vratil a vypnul to). Uprava dumpu pomoci kolony v shellu (hlavnim akterem sed) trvala cca 6 sec.

[Jooky (inactive)]

ja som riesil upravu cca 1,5 miliona riadkov a tiez som narazil na problem s rychlostou. Ako by sa dalo ocakavat, tak stacilo zacat tranzakciu pred takym updatom a v momente dokoncenia ju potvrdit. Cele updatovanie trvalo nepomerne kratsie. Ono sa to az dalo ocakavat, ale nenapadlo ma to hned.

[Josef Kufner]

InnoDb automaticky zahajuje a ukončuje transakci kolem každého dotazu. Tím, že to obalíš do jedné transakce, tahle režie odpadne. Případně ještě může pomoct odstranění/zakázání indexu na modifikovaném sloupci.

[George O.]

Docela jasny timeout DB connection IMHO, standartne byva nekde kolem jedne minuty, pokud nenastavis jinak a protoze jsi reagoval stylem "myslim, ze se nejedna o timetout", tim padem je jasne, ze jsi jej asi nenastavil na nejakou mnohem vyssi, nez defaultni hodnotu, kdyz to nevis jiste

Update s offsetem to vsechno resi. Nechapu tu omacku tady kolem toho. Mozna je nejake idealnejsi reseni, nez offset, ale proc resit detaily, kdyz mame naprosto jednoduche, rychle a hlavne bezpecne reseni