MYSQL Begrenzung Preistabelle (IDs)

Shopware 5
1

Hallo,

wir haben gerade ein Problem bei einem Kundenshop mit der Anzahl der Artikelpreise. Aufgrund der sehr differenziert kalkulierten Rabattstruktur in der Warenwirtschaft des Kunden werden per Schnittstelle über die Shopware-API sehr viele Preise übertragen. Aktuell sind etwa 100 Millionen Preise in der Shopdatenbank. Da immer wieder neue Preise hinzukommen und alte verfallen, zählen die IDs in der Preistabelle mittlerweile bis etwa 4.3 Milliarden. Das Feld ist mit INT(11) typisiert und macht folglich bei dieser Anzahl dicht und lässt keine weiteren Einträge zu.

Die Schnittstelle gibt folgenden Fehler zurück:

SQLSTATE[22003]: Numeric value out of range: 167 Out of range value for column ‚id‘ at row 1

2021-03-01 10:28:16 Artikel „659568“ konnte nicht hinzugefügt/aktualisiert werden: An exception occurred while executing ‚INSERT INTO s_articles_prices (articleID, articledetailsID, pricegroup, from, to, price, pseudoprice, percent) VALUES (?, ?, ?, ?, ?, ?, ?, ?)‘ with params [420950, 442249, „EK“, 1, „beliebig“, 2514, 0, 0]:

Bisherige Analysen / Geprüfte Punkte:

In der Shop-Datenbank-Tabelle: s_articles_prices liegt der ID-Zähler bereits bei 4.294.966.866 , es lassen sich per Api und auch per mysql-admin keine weiteren Datensätze hinzufügen.

Ist es möglich den Fehler durch Erhöhung des Datenfeld-Types INT von 11 auf 12 oder noch weiter die Grenze zu erhöhen? Spielt der Shop hier uneingeschrängt mit - Spielt diese Grenze auch in den Core-Funktionen von Shopware ein Rolle oder kann die DB hier modifizert werden?

2

Da das wahrscheinlich diesen Fall noch niemand hatte bleibt dir nichts anderes übrig als es zu testen.

ALTER Table/Column auf BIGINT da INT nur bis 4294967295 geht
siehe MySQL :: MySQL 8.0 Reference Manual :: 11.1.2 Integer Types (Exact Value) - INTEGER, INT, SMALLINT, TINYINT, MEDIUMINT, BIGINT

3

Generell solltest du dir die Frage stellen wieso der ID Zähler so hoch ist. Am Besten kannst du die Preistabelle einmal leeren, das Auto Increment auf 1 setzen und dann die Preise erneut importieren. 4 Milliarden Preise sollten dann ja nicht importiert werden :wink: Ebenfalls sollte das ERP in Zukunft dann die alten Preise beim Update löschen.

4

EDIT: Revidierte Antwort meinerseits

5

Ja, der ID-Zähler ist so hoch, weil in der Wawi die Kunden Rabattgruppen mit Formeln zur Berechnung der Preise bekommen, die wiederum für verschiedene Artikelgruppen Rabatte auf Artikel und Varianten vergeben. Somit führt das Verhältnis Artikel (500.000) : Kunden (1500) zu sehr vielen Einzelpreisen (100 Mio.), die bei Änderung von Konditionen sich wiederum en mass ändern.

Scheinbar führt hier eine Änderung des Preises zu einem neuen Datensatz in der Datenbank, der alte wird dafür gelöscht. Die Datenbank zählt dann aber die Preis-ID fein aufwärts bis zum Ende der Fahnenstange. Daher haben wir zwar keine steigende Anzahl („nur“ 100 Mio) an Preisen in der DB, die ID steigt aber durch die stetigen Aktualisierungen (Löschen + hinzufügen).

Wir haben jetz die Daten nochmal gelöscht (ID-Zähler ist zurückgesetzt).

BIGINT statt INT wäre vielleicht eine Option. Cool wäre natürlich, wenn es hier jamanden gäbe, der weiß, ob Shopware da mitspielt. Wenn nicht, bleibt sicher nur ausprobieren.

Oder gibt es eine Option, dass der Autoincrement des DB-Feldes die IDs der gelöschten Preisdatensätze wieder verfügbar macht für neue? Ich mutmaße, dass das Preis-IDs möglicherweise in anderen Tabellen referenziert sind und es dadurch zu Fehlern an anderen Stellen kommen könnte … oder obwohl ja beim Löschen eines Preises aus der Tabelle alle Referenzen gelöscht werden müssten, aber ich würde nicht drauf wetten. Hier wäre ich für einen weiteren Hinweis dankbar.

6

Oh - was meinst du mit ‚revidiert‘? Hast Du schnell geprüft ob es funktioniert oder hast du neue andere Erkenntnisse? :smiley:

7

Ich hatte geschrieben dass du ja nur reindexen müsstest wenn es gar nicht so viele einträge sind, aber dann würde ja die zuordnung der Artikel nicht mehr stimmen :wink:
EDIT: ähh warte mal, bin gerade durcheinander, ggf würde ein reindex doch möglich sein.

8

BIGINT statt INT in der DB-Tabelle funktioniert.