Portál AbcLinuxu, 26. července 2025 04:29
CREATE TABLE big (a integer);
insert into big values (1,2,3,4,5,6,7,8);
insert into big select a + (select max(a) from big) from big ;
insert into big select a + (select max(a) from big) from big ;
insert into big select a + (select max(a) from big) from big ;
insert into big select a + (select max(a) from big) from big ;
insert into big select a + (select max(a) from big) from big ;
insert into big select a + (select max(a) from big) from big ;
insert into big select a + (select max(a) from big) from big ;
insert into big select a + (select max(a) from big) from big ;
insert into big select a + (select max(a) from big) from big ;
insert into big select a + (select max(a) from big) from big ;
DO $$
declare r integer;
declare s integer;
declare t integer;
begin
t=0;
for r in 1..100000 loop
select sum(a) from big where a between (r % 8000) AND (r % 8000) + r % 50 into s;
t=t+s;
end loop;
end;
$$;
CREATE INDEX biga ON big(a) ;
SELECT hrac FROM tabulka_1 WHERE (datumpridania > 1307400000 AND datumpridania < 1307492665) AND team = 'barcelona';mal by som teda nadefinovať index takto:
CREATE INDEX ON tabulka_1 (team, datumpridania)je ten index správne nadefinovaný?
>>pokud je v sloupeci datum, tak bys k němu měl přistupovat jako k datupochopil som, ze tam teda bude lepšie, keď použijem datetime namiesto int, t.j. vo formate 0000-00-00 00:00:00. Je toto potom ok(?):
BETWEEN '2011-01-01' AND '2011-05-30'BETWEEN '2011-01-01 12:54:21' AND '2011-05-30 01:01:05'
BETWEEN '2011-01-01 00:00:00' AND '2011-05-30 23:59:59'alebo
BETWEEN '2011-01-01 00:00:00' AND '2011-05-31 00:00:00'(čo by malo vrátiť približne rovnaké výsledky v oboch prípadoch - avšak asi nevráti zápis s hodnotou 2011-05-30 23:59:59, vráti len tie čo sú menšie) vďaka za pomoc
CREATE INDEX prvy_index ON tabulka_1 (team) CREATE INDEX druhy_index ON tabulka_1 (datumpridania) namiesto CREATE INDEX meno_indexu ON tabulka_1 (team, datumpridania) ?v prípade meno_indexu by sa nejako tie dva stĺpce team+datumpridania previazali? narozdiel od tych prvy_index a druhy_index, kedy sa indexy vytvoria solo pre každý stĺpec? pýtam sa tak blbo, lebo nerozumiem, aký je tam rodiel v tých indexoch :/ ďakujem za trpezlivosť
, že jsem to nepředpokládal, že to musím explicitně vyslovit.
Pokud se "ale pravidelně" používají v systému nějaký dotazy na obě dvě složky indexu (a to zpravidla platí), tak je volba složených indexů ta, která dá největší poměr cena/výkon.
Statistiky to u rozumné databáze nezvoře, protože ty si může bez problémů evidovat po složkách. Jediná nevýhoda je větší velikost indexu, ta je ale furt menší, než dělat složenej a jednoduchej index najednou, popř. zpomalení dané větší velikostí indexu zdaleka není takové jako ztráta času, která by nastala při existenci pouze jednoduchého indexu díky sekvenčnímu zpracování druhé podmínky.
---
PS: V minulym postu jsem to trochu zjednodušil, chytrý databáze (např. postgresql) dokonce uměj kombinovat více indexů: udělaj bitmapovou mapu obou podmínek a pak jí mergnou, ale tadle metoda není zdaleka tak efektivní, jako složený index.
7.6.2011 21:32
moo | skóre: 7
| Praha
Ma to teda zmysel?Nema.
Tohle by se možná dalo označit za jednu z nejčastějších začátečnických chyb. Rozdělením stejných záznamů do několika tabulek docílíte jen toho, že v lepším případě budete místo jednoduchých dotazů tvořit nepřehledné, nesrozumitelné a neoptimalizovatelné konstrukce založené na union dvou dotazů přes jednotlivé tabulky. Tedy ve vašem případě, kdy jsou ty tabulky dvě; pokud jich je víc, obvykle to končí iterováním přes jednotlivé tabulky.
Desetitisíce záznamů v tabulce nejsou ani zdaleka důvodem k panice, natož k podobným šíleným konstrukcím. Databáze jsou stavěné na to, aby efektivně pracovaly s daty, a nemá smysl jim házet klacky pod nohy tím, že ze strachu budete uměle komplikovat strukturu těch dat.
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.