it-swarm-eu.dev

Kód chyby 1117 Příliš mnoho sloupců; MySQL sloupec-limit na tabulce

Mám tabulku s 1699 sloupci a když se snažím vložit další sloupce, dostanu,

Kód chyby: 1117. Příliš mnoho sloupců

V této tabulce mám jen 1000 řádků. Pro mě je nejdůležitější počet sloupců. Jsou na stole nějaká omezení? Chci vytvořit 2000 sloupců. Je to možné?

38
OHLÁLÁ

Proč byste potřebovali vytvořit tabulku s 20 sloupci, natož 2000?

Udělená, denormalizovaná data mohou zabránit tomu, aby bylo nutné načíst mnoho sloupců dat pomocí JOIN. Pokud však máte více než 10 sloupců, měli byste se zastavit a přemýšlet o tom, co by se při načítání dat stalo pod kapotou.

Pokud tabulka sloupců 2000 podstoupí SELECT * FROM ... KDE byste během zpracování vygenerovali velké dočasné tabulky, načtili sloupce, které jsou zbytečné, a vytvořili mnoho scénářů, kde by byly poslány komunikační pakety ( max_allowed_packet ) na pokraji každého dotazu.

V mých dřívějších dobách jsem pracoval jako vývojář ve společnosti v roce 1995, kde byla hlavní RDBMS DB2. Společnost měla jednu tabulku, která měla 270 sloupců, desítky indexů a měla problémy s načítáním dat. Kontaktovali IBM a nechali konzultanty, aby prozkoumali architekturu svého systému, včetně této jedné monolitické tabulky. Společnost byla informována: "Pokud tuto tabulku normalizujete v následujících 2 letech, DB2 selže při dotazech provádějících zpracování Stage2 (všechny dotazy vyžadující řazení na neindexovaných sloupcích)." To bylo řečeno společnosti s více biliony dolarů, aby normalizovala tabulku 270 sloupců. O co víc tedy tabulka sloupců 2000.

Pokud jde o mysql, museli byste kompenzovat takový špatný design nastavením možností srovnatelných s produktem DB2 Stage2 Processing. V tomto případě by tyto možnosti byly

Tweeking těchto nastavení, aby nahradil přítomnost desítek, natož stovek, sloupců funguje dobře, pokud máte TB RAM.

Tento problém se geometricky znásobí, pokud používáte InnoDB, protože budete muset vypořádat s MVCC (Multiversion Concurrency Control) se snaží chránit tuny sloupců s každým SELECT, UPDATE a DELETE prostřednictvím izolace transakce.

[~ # ~] závěr [~ # ~]

Neexistuje žádná náhrada nebo pomoc s bandou, která by mohla nahradit špatný design. Prosím, z důvodu své duševní zdraví v budoucnosti, normalizujte tuto tabulku ještě dnes !!!

37
RolandoMySQLDBA

Mám potíže s představou, kde by datový model mohl legitimně obsahovat 2000 sloupců ve správně normalizované tabulce.

Můj odhad je, že pravděpodobně děláte nějaký druh "vyplnění mezer" denormalizovaného schématu, kde ve skutečnosti ukládáte všechny různé druhy dat v jedné tabulce a místo toho, abyste je rozdělili do samostatných tabulek a navázali vztahy , máte různá pole, která zaznamenávají, jaký „typ“ dat je uložen v daném řádku, a 90% polí je NULL. Ale i tak se chcete dostat k 2000 sloupcům ... jo.

Řešením vašeho problému je přehodnocení vašeho datového modelu. Pokud ukládáte velkou hromadu dat o hodnotě klíč/hodnota, která jsou spojena s daným záznamem, proč to tak nemodelovat? Něco jako:

CREATE TABLE master (
    id INT PRIMARY KEY AUTO_INCREMENT,
    <fields that really do relate to the
    master records on a 1-to-1 basis>
);

CREATE TABLE sensor_readings (
    id INT PRIMARY KEY AUTO_INCREMENT,
    master_id INT NOT NULL,   -- The id of the record in the
                              -- master table this field belongs to
    sensor_id INT NOT NULL,
    value VARCHAR(255)
);

CREATE TABLE sensors (
    id INT PRIMARY KEY AUTO_INCREMENT,
    <fields relating to sensors>
);

Poté, abyste získali všechny položky senzorů spojené s daným „hlavním“ záznamem, stačí SELECT sensor_id,value FROM sensor_readings WHERE master_id=<some master ID>. Pokud potřebujete získat data pro záznam v tabulce master spolu se všemi daty senzoru pro tento záznam, můžete použít spojení:

SELECT master.*,sensor_readings.sensor_id,sensor_readings.value
FROM master INNER JOIN sensor_readings on master.id=sensor_readings.master_id
WHERE master.id=<some ID>

A pak se připojí, pokud potřebujete podrobnosti o tom, co je každý senzor.

25
womble

Je to měřicí systém s 2000 senzory

Ignorujte všechny komentáře, které křičí o normalizaci - to, co požadujete, by mohl být rozumný návrh databáze (v ideálním světě) a dokonale dobře normalizovaný, je to prostě velmi neobvyklé a jak bylo uvedeno jinde, RDBMS obvykle nejsou jednoduše navrženy pro tento počet sloupců. .

Přestože nenarazíte na MySQL pevný limit , jeden z dalších faktorů uvedených v odkazu vám pravděpodobně zabraňuje jít výš

Jak ostatní navrhují, toto omezení byste mohli obejít tím, že budete mít podřízený stůl s id, sensor_id, sensor_value nebo jednodušeji, můžete vytvořit druhou tabulku, která bude obsahovat pouze sloupce, které se do první nevejdou (a použít stejný PK)

MySQL 5.0 omezení počtu sloupců (zvýraznění přidáno):

Existuje pevný limit 4096 sloupců na tabulku , ale efektivní maximum může být pro danou tabulku menší. Přesný limit závisí na několika vzájemně se ovlivňujících faktorech.

  • Každá tabulka (bez ohledu na úložný stroj) má maximální velikost řádku 65 535 bajtů. Úložné motory mohou na tento limit ukládat další omezení, což snižuje efektivní maximální řádek velikost.

    Maximální velikost řádku omezuje počet (a možná velikost) sloupců, protože celková délka všech sloupců nemůže tuto velikost překročit.

...

Jednotlivé úložné stroje mohou ukládat další omezení, která omezují počet sloupců tabulky. Příklady:

  • InnoDB umožňuje až 1000 sloupců.
15
lg_

Nejprve další planoucí, pak skutečné řešení ...

Většinou souhlasím s plameny, které se na vás již hodily.

Nesouhlasím s normalizací klíč-hodnota. Dotazy skončí jako hrozné; výkon ještě horší.

Jedním „jednoduchým“ způsobem, jak se vyhnout okamžitému problému (omezení počtu sloupců), je „svisle rozdělit“ data. Mějte, řekněme, 5 tabulek po 400 sloupcích. Všichni by měli stejný primární klíč, kromě jednoho by to mohl být AUTO_INCREMENT.

Možná by bylo lepší rozhodnout se o tuctech nejdůležitějších polí a vložit je do „hlavního“ stolu. Pak senzory logicky seskupte a vložte je do několika paralelních tabulek. Při správném seskupení pravděpodobně nebudete muset spojovat všechny tabulky pořád.

Indexujete některou z hodnot? Potřebujete na nich hledat? Pravděpodobně hledáte datetime?

Pokud potřebujete indexovat mnoho sloupců - punt.

Pokud potřebujete indexovat několik, vložte je do hlavní tabulky.

Zde je skutečné řešení (pokud se to týká) ...

Pokud nepotřebujete velké množství indexovaných senzorů, pak neřešte sloupce! Ano, slyšeli jste mě. Místo toho je sbírejte do JSON, komprimujte JSON a uložte je do pole BLOB. Ušetříte spoustu místa; budete mít pouze jednu tabulku bez problémů s limitem sloupců; atd. Vaše aplikace bude nekomprimovat a poté použije JSON jako strukturu. Hádej co? Můžete mít strukturu - senzory můžete seskupit do polí, víceúrovňových atd., Stejně jako by vaše aplikace chtěla. Další „vlastnost“ - je otevřená. Pokud přidáte více senzorů, nemusíte tabulku ALTER měnit. JSON, pokud je tak flexibilní.

(Komprese je volitelná; pokud je váš datový soubor obrovský, pomůže vám s diskovým prostorem, tedy s celkovým výkonem.)

7
Rick James

Vidím to jako možný scénář ve světě velkých dat, kde možná nebudete provádět tradiční vybrané * typy dotazů. Zabýváme se tím v prediktivním modelovacím světě na úrovni zákazníka, kde modelujeme zákazníka napříč tisíci dimenzí (všechny mají hodnoty 0 nebo 1). Tento způsob ukládání usnadňuje navazující aktivity spojené s vytvářením modelů atd., Pokud máte rizikové faktory ve stejném řádku a také příznak výsledku ve stejném řádku. To lze normalizovat z místa úložiště s nadřazenou podřízenou strukturou, ale lze jej normalizovat. prediktivní model bude muset převést zpět na ploché schéma. Používáme redshift, který dělá sloupcové úložiště, takže vaše 1000+ sloupce, když načítáte data, jsou ve skutečnosti uloženy ve sloupcovém formátu ...

Pro tento design je čas a místo. Absolutně. Normalizace není řešením každého problému.

4
BigDataGuy