Fehlercode 1117 zu viele Spalten; Mysql Spaltenlimit auf der Tabelle

dba.stackexchange https://dba.stackexchange.com/questions/3972

  •  16-10-2019
  •  | 
  •  

Frage

Ich habe eine Tabelle mit 1699 Spalten und wenn ich versuche, weitere Spalten einzulegen, bekomme ich,

Fehlercode: 1117. Zu viele Spalten

In dieser Tabelle habe ich nur 1000 Zeilen. Für mich ist das Wichtigste die Anzahl der Spalten. Gibt es irgendwelche Einschränkungen auf dem Tisch? Ich möchte 2000 Spalten erstellen. Ist das möglich?

War es hilfreich?

Lösung

Warum müssten Sie eine Tabelle mit sogar 20 Spalten erstellen, geschweige denn 2000 ???

Zugegeben, denormalisierte Daten können verhindern, dass Verbindungen vorhanden sind, um viele Datensäulen abzurufen. Wenn Sie jedoch über 10 Spalten haben, sollten Sie anhalten und darüber nachdenken, was während des Datenabrufs unter der Motorhaube passieren würde.

Wenn eine 2000 -Spalte -Tabelle ausgewählt wird * von ... Woher würden Sie während der Verarbeitung große Tempentabellen erzeugen, Spalten abrufen, die unnötig sind, und viele Szenarien erstellen, in denen Kommunikationspakete (MAX_ALLAWED_PACKET) würde bei jeder Frage an den Rand gedrängt werden.

In meinen früheren Tagen als Entwickler arbeitete ich 1995 in einem Unternehmen, in dem DB2 das Haupt -RDBM war. Das Unternehmen hatte eine einzelne Tabelle mit 270 Spalten, Dutzenden von Indizes und Leistungsproblemen, die Daten abrufen. Sie kontaktierten IBM und ließen Berater die Architektur ihres Systems untersuchen, einschließlich dieser einen monolithischen Tabelle. Dem Unternehmen wurde mitgeteilt: "Wenn Sie diese Tabelle in den nächsten 2 Jahren nicht normalisieren, fehlschlägt DB2 bei Abfragen, die die Verarbeitung der Stufe2 durchführen (alle Abfragen, die nicht idexierte Spalten sortieren müssen)." Dies wurde an ein Unternehmen mit mehreren Billionen Dollar mitgeteilt, um eine Spaltentabelle 270 zu normalisieren. Wie viel mehr eine Spaltentabelle 2000.

In Bezug auf MySQL müssten Sie ein solches schlechtes Design kompensieren, indem Sie Optionen festlegen, die mit der Verarbeitung von DB2 Stage2 vergleichbar sind. In diesem Fall wären diese Optionen

Wenn Sie diese Einstellungen tweeten, um das Vorhandensein von Dutzenden, geschweige denn Hunderten von Säulen auszugleichen, funktioniert gut, wenn Sie TBS RAM haben.

Dieses Problem multipliziert geometrisch, wenn Sie InnoDB verwenden, wie Sie es zu tun haben MVCC (Multiversion Concurrency Control) Versuchen Sie, Tonnen von Spalten mit jedem Auswahl, Aktualisieren und Löschen durch Transaktionisolation zu schützen.

FAZIT

Es gibt keinen Ersatz oder ein Pflaster, das schlechtes Design ausgleichen kann. Bitte normalisieren Sie diesen Tisch noch heute, um Ihre geistige Gesundheit in Zukunft zu gewährleisten !!!

Andere Tipps

Ich habe Probleme, mir etwas vorzustellen, bei dem das Datenmodell zu Recht 2000 Spalten in einer ordnungsgemäß normalisierten Tabelle enthalten könnte.

Ich vermute, dass Sie wahrscheinlich eine Art "Füllen Sie die Leerzeichen aus" -Denormalisiertes Schema aus, bei dem Sie tatsächlich alle Arten von Daten in der einen Tabelle speichern und die Daten in separate Tabellen unterteilen und Beziehungen herstellen Sie haben verschiedene Felder, die aufgezeichnet werden, welche "Art von Daten" in einer bestimmten Reihe gespeichert ist, und 90% Ihrer Felder sind null. Selbst dann, um 2000 Spalten zu erreichen ... Yikes.

Die Lösung für Ihr Problem besteht darin, Ihr Datenmodell zu überdenken. Wenn Sie einen großen Stapel Schlüssel-/Wertdaten speichern, die einem bestimmten Datensatz zugeordnet sind, warum nicht so modellieren? Etwas wie:

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>
);

Dann können Sie gerade SELECT sensor_id,value FROM sensor_readings WHERE master_id=<some master ID>. Wenn Sie die Daten für einen Datensatz in der erhalten müssen master Die Tabelle zusammen mit allen Sensordaten für diesen Datensatz können Sie einen Join verwenden:

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>

Und dann weiter miteinander, wenn Sie Details zu jedem Sensor benötigen.

Es ist ein Messsystem mit 2000 Sensoren

Ignorieren Sie alle Kommentare, die über die Normalisierung rufen - was Sie verlangen, könnte ein vernünftiges Datenbankdesign sein (in einer idealen Welt) und vollkommen gut normalisiert, es ist einfach sehr ungewöhnlich und wie an anderer Stelle hervorgehoben wird .

Obwohl Sie nicht auf die MySQL treffen Festgrenze, einer der anderen in der Verbindung erwähnten Faktoren ist wahrscheinlich, dass Sie Sie daran hindern, höher zu gehen

Wie andere vorschlagen, könnten Sie diese Einschränkung durch einen Kindertisch mit dem Tisch umgehen id, sensor_id, sensor_value, oder einfacher, Sie können eine zweite Tabelle erstellen, die nur die Spalten enthalten, die nicht in die erste passen (und dieselbe PK verwenden).

MySQL 5.0 Säulenzählgrenze (Betonung hinzugefügt):

Es gibt eine harte Grenze von 4096 Spalten pro Tabelle, aber das effektive Maximum kann für eine bestimmte Tabelle geringer sein. Die genaue Grenze hängt von mehreren interagierenden Faktoren ab.

  • Jede Tabelle (unabhängig von der Speichermotor) hat eine maximale Zeilengröße von 65.535 Bytes. Speichermotoren können zusätzliche Einschränkungen für diese Grenze einlegen und die effektive maximale Zeilengröße verringern.

    Die maximale Zeilengröße beschränkt die Zahl (und möglicherweise die Größe) der Spalten, da die Gesamtlänge aller Spalten diese Größe nicht überschreiten darf.

...

Einzelne Speichermotoren können zusätzliche Beschränkungen auferlegen, die die Anzahl der Tabellen begrenzen. Beispiele:

  • InnoDB ermöglicht bis zu 1000 Spalten.

Zuerst noch etwas Flammen, dann eine echte Lösung ...

Ich stimme meistens den Flammen zu, die bereits auf Sie geworfen wurden.

Ich bin mit der Schlüsselwertnormalisierung nicht einverstanden. Abfragen sind schrecklich; Leistung noch schlimmer.

Eine "einfache" Methode, um das unmittelbare Problem (Einschränkung der Anzahl der Spalten) zu vermeiden, besteht darin, die Daten vertikal zu partitionieren. Halten Sie beispielsweise 5 Tabellen mit jeweils 400 Spalten. Sie hätten alle den gleichen Primärschlüssel, außer dass es möglicherweise auto_increment ist.

Vielleicht wäre es vielleicht besser, sich für die Dutzend Felder zu entscheiden, die am wichtigsten sind, sie in den Haupttisch einbringen. Gruppen Sie dann die Sensoren logisch und setzen Sie sie in mehrere parallele Tische. Mit der richtigen Gruppierung müssen Sie möglicherweise nicht die ganze Zeit alle Tische verbinden.

Indizieren Sie einen der Werte? Müssen Sie sie suchen? Wahrscheinlich suchen Sie nach DateTime?

Wenn Sie viele Spalten indexieren müssen - Punt.

Wenn Sie einige indexieren müssen - stecken Sie sie in die Haupttabelle.

Hier ist die wahre Lösung (falls sie gilt) ...

Wenn Sie nicht die große Auswahl an indizierten Sensoren benötigen, dann machen Sie keine Spalten! Ja, du hast mich gehört. Sammeln Sie sie stattdessen in JSON, komprimieren Sie den JSON und speichern Sie ihn in ein Blob -Feld. Sie werden eine Menge Platz sparen; Sie haben nur eine Tabelle mit nicht Spaltengrenzproblemen. usw. Ihre Bewerbung wird sich unkontrollieren und dann den JSON als Struktur verwenden. Erraten Sie, was? Sie können Struktur haben - Sie können die Sensoren in Arrays, mehrstufige Sachen usw. gruppieren, genau wie Ihre App möchte. Ein weiteres 'Feature'-es ist offen. Wenn Sie mehr Sensoren hinzufügen, müssen Sie die Tabelle nicht ändern. JSON, wenn flexibel auf diese Weise.

(Komprimierung ist optional; Wenn Ihr Datensatz riesig ist, hilft dies beim Speicherplatz und daher die Gesamtleistung.)

Ich sehe dies als ein mögliches Szenario in der Welt der Big Data, in dem Sie möglicherweise nicht die traditionellen Auswahltypen ausführen. Wir beschäftigen uns in der Predictive Modeling World auf Kundenebene, in der wir einen Kunden über Tausende von Dimensionen modellieren (alle mit Werten von 0 oder 1). Diese Speicherung erleichtert die nachgeschalteten Modellbuilding -Aktivitäten usw., wenn Sie die Risikofaktoren in derselben Reihe und das Ergebnisflag in derselben Zeile haben. Das Vorhersagemodell stromabwärts muss es wieder in flaches Schema umwandeln. Wir verwenden RedShift, das den Spaltenspeicher erstellt, sodass Ihre 1000+ Spalten beim Laden der Daten tatsächlich in einem Spaltenformat gespeichert werden ...

Es gibt eine Zeit und einen Ort für dieses Design. Unbedingt. Normalisierung ist nicht die Lösung für jedes Problem.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit dba.stackexchange
scroll top