Administrace komentářů

Když to tak po sobě čtu, Tak bych měl i pro Tebe jednu radu. Připraven? Tvoje rada tazateli platí i Tobě.

Touché… Ale já se tím řídím Doby kdy jsem ztrácel čas zkoumáním intimních detailů fungování databází už je dávno pryč. Časem jsem dospěl k tomu že 1) Databáze nepíší blbci. Dokonce ani MySQL ne 2) Většinu věcí umí DB zoptimalizovat lépe než já. Nejlepší co můžu udělat je neplést se do cesty, maximálně občas trochu napovědět. 3) Když už výjimečně udělám nějakou rádobyvyfikundovanou optimalizaci tak o pár verzí DB dál může mít nulový nebo právě opačný efekt.

Nad velkými daty to samozřejmě tak jednoduché není, ale pro mrzácké tisíce uživatelů a stovky tisíc řádků o kterých mluvil Adrinko to IMO platí.

U neMVCC databází jsou většinou data uložená clustrovaná dle primárního klíče (či jiného daného indexu). V tu chvíli záznamy prostě nebudou fragmentovány…

V MySQL/InnoDB se clusteruje pouze obsah primárního klíče… zbytek řádky == seek. Sklepávání řádek do stejného bloku jak píšeš může hodně pomoci, o tom žádná. Ale třeba v MySQL to vede AFAIK k zamykání celých bloků i bloků s PK. U paralelně pracující aplikace (což afaik je adrinkův případ) se mi neosvědčilo takové věci vyvádět moc často. V lepším případě to zpomaluje, v horším je MySQL schopná uhnít na deadlocku. Ale moje rada se nezakládá na takových detailech, ale naopak na tom že tyhle věci by se neměly řešit dokud to není opravdu nutné.

Poslední Tvé tvrzení IMHO není pravda (už proto, že na těch tabulkách mohou být pověšené triggery, on update current timestamp a podobná zvířátka)

Však proto taky píšu že to "může" být lepší tj. že je to potřeba změřit. AFAIK pokud to nebude dobře oklíčované tak by se stejně muselo seekovat. Optimalizaci tím že se nějaký kód _nenapíše_ bych ze všech vylomenin co tu padly považoval za nejmenší ztrátu času.