Klíče v MySQL – je třeba nějakého sdíleného klíče napříč všemi zúčastněními tabulkami?

Ahoj všem, nikde se mi nepodařilo vygooglit.. mám dotaz, kde je where B.USERID=C.USERID and A.ID=B.product and B.active=1 and B.schvaleno=1... Klíče mám v tabulce B společně na USERID+product+active+schvaleno v tabulce A na ID v tabulce C na USERID je to ok? Nebo je třeba nějakého sdíleného klíče napříč všemi zúčastněními tabulkami? Děkuji velice, Pavel

Nemáte namysli vytažení z více tabulek více hodnot a základě stejného klíče? Pokud ano zkuste nastudovat JOIN.

nevim, jestli je to uplně přesně to, co mě zajímalo..Ptal jsem se, zda v případě dotazů do více tabulek (formou joinu) existuje něco jako sdílený klíč pro všechny sloupce dohromady na kterých jsou podmínky.

Zdravím, klíče jsou takto v pořádku. Pokud jde o rychlost dotazu možná by stálo za úvahu přidat samostatný index na na B.userid. Otázka je, zda se indexy při vykonávání dotazu uplatní. Pokud výsledku bude odpovídat větší počet řádků, možná se full scanu nevyhneš. Když si spustíš explain daného dotazu, uvidíš zda mají indexy význam.

předpokládám, že máš engine innodb, jinej nemá smysl. Každá tabulka musí mít indexy samostatně a nemůžeš je sdílet napříč tabulkami, teda kromě foreign key.Podle rychlého pohledu z těch málo informací by to mělo být takhle:C.USERID - primary keyB.USERID - foreign key of C.USERIDA.ID - primary keyB.product - foreign key of A.IDB.ACTIVE a B.SCHVALENO - vícesloupcový indexLépe bych dokázal poradit, kdybych mohl vidět konkrétní dotaz, vidět schéma tabulek, vědět kolik záznamů bude v tabulkách. Nebo stačí pokud máš explain, ten také řekne hodně.Mysql data získává v několika krocích a poměrně složitou alchymií se rozhoduje co a jak použije. V první řadě musí spojit tabulky dohromady, k tomu poslouží velice dobře foreign key, je to svižné i na 100M záznamů. Jakmile jsou tabulky spojeny, začně se pídit po dalších podmínkách, v tomhle případě filtrovat podle active a schvaleno. Je tady ale riziko, že usoudí, že bude jednodušší záznamy proskenovat a ten vícesloupcových index nepoužít, to ti řekne explain.Pokud by existovalo riziko, že záznamů v B je obrovské množství, může vyjít výhodněji nejprve je vyfiltrovat podle active a schvaleno a poté vynutit použití foreing indexu na spojení zbytku. Na to dá odpověď explain a plánovaný (či skutečný) počet záznamů v tabulkách.

Děkuji všem za rady, pokusím se z toho vzít si vše potřebné a pomocí google dojít ke zdárnému řešení.Když už vás tu mám, dovolte mi ještě jeden dotaz:- v tabulce často hledám podle sloupce A + B + C nebo jen dle B+C nebo dle A+C- společné klíče je třeba dát na A+B+C a také pouze na B+C apod. nebo stačí, když podmínka B+C je součástí klíče A+B+C?Tzn. netvořil bych klíče na sloupcách A+B+C a B+C a A+C, ale jen A+B+C a pokud by byla podmínka při selecu A+C, tak by se vzaly z klíče A+B+CDíky

Na úvod první tři pravidla:- mysql nepoužije indexy pokud je ve sloupci 3/4 stejných hodnot- mysql umí použít pro jednu tabulku pouze jeden index na dotaz poté se to obchází index hintami- uč se používat explain, ten ti přesně odpoví na to, jak se to chová v tvém případěSkalární (složené) indexy jsou uloženy jako b-tree, je možné je částečně použít, ale pouze z levé strany, tj. pro index (A, B, C) můžeš do where dát (A,B,C), (A), (A,B), ale už nikoliv (C), (A,C), (B,C), na to bys musel mít další indexy.Hodně ale záleží na rozložení dat, v malé granualitě jsou indexy pomalejší než skenování. Jen pár věcí je platných obecně, zbytek je podle dané struktury.

Děkuji velice!