Die MRG-Tabelle enthält 1B + Zeilen, die auf mehrere kleinere Tabellen verteilt sind. Zusätzliche Beobachtungen werden der MRG-Tabelle hinzugefügt, die sie der letzten zugrunde liegenden Tabelle hinzufügt.MyIsam MRG - Best Practices zum Verwalten der Eindeutigkeit
Aus irgendeinem Grund scheint es ein paar doppelte Zeilen zu geben, die denselben Primärschlüssel teilen. Ich weiß, dass dies eine Einschränkung der MRG-Tabellen ist und in unserem Fall nicht wirklich problematisch ist (es bedeutet einfach nutzlose Redundanz). Wir glauben, dass die Duplikate nach einem Systemabsturz eingefügt wurden, sodass die erneute Verarbeitung nicht ordnungsgemäß vom Code der Anwendung gehandhabt wurde, der Duplikate vor dem Einfügen in das Archiv aus einer temporären Tabelle löscht.
Gibt es eine Reihe von Best Practices zur Erhaltung der Eindeutigkeit, die nicht zu viel Verarbeitungszeit erfordern?
Ich bezweifle, wenn Ihre Frage viel Traktion bekommen wird. Ich habe MRG vor 15 Jahren zum letzten Mal benutzt und seitdem nichts davon gehört. MyISAM geht weg und MRG damit. 'PARTITIONing' ist meistens ein Ersatz dafür; aber selbst es hat wenig Nutzen. Warum verwenden Sie MRG anstelle eines riesigen Tisches? –
Einmal am Tag werden mehrere Millionen Zeilen aktualisiert. Die Verwendung einer Sammlung kleinerer Tabellen ermöglicht die Parallelisierung. Ich halte mich an myIsam, weil es viel schnellere und kompaktere Backups erlaubt. Aber ja, höchstwahrscheinlich wechseln zu partitionierten Innodb in nicht allzu ferner Zukunft. In der Zwischenzeit wird eine einheitliche Tabelle mit dem Primärschlüssel verwendet, um die Eindeutigkeit zu erzwingen. Nicht ideal, aber macht den Job – user3127882
MyISAM behandelt PARTITIONing, daher Eindeutigkeitsprüfung. –