Mit Python in einer MySQL Datenbank jeden Datensatz einzeln lesen und auch schreiben

**hyle** · April 18, 2023 at 10:26 AM

Quote from KKoPi

Doch, die Spalte wird dank auto_inc gleich "richtig" ausgefüllt

Nachträglich und gleich beim erstellen der Spalte? Da bin ich etwas skeptisch. Bei neuen Einträgen ist klar, aber so?

Bot · Vor 5 Minuten

Mit Python in einer MySQL Datenbank jeden Datensatz einzeln lesen und auch schreiben? Schau mal ob du hier fündig wirst!

KKoPi · April 18, 2023 at 10:40 AM

Quote from hyle

~~Nachträglich und~~ gleich beim Erstellen der Spalte?

Was meinst Du mit nachträglich?

Das wird der PRIMARY KEY, der muss eindeutig sein.

Guckst Du, wenn Du uns nicht glaubst

SQL

CREATE TABLE `test` (
  `data` int DEFAULT NULL
);

INSERT INTO `test` VALUES (1), (2);

SELECT * FROM `test`;

ALTER TABLE `test` ADD `id` INT unsigned NOT NULL AUTO_INCREMENT PRIMARY KEY FIRST;

SELECT * FROM `test`;

Display More

EDIT: Gültig für MySQL/MariaDB/Percona

Diese Vorgehensweise aber nur, wenn es absolut unwichtig ist, in welcher Reihenfolge die "alten" Daten durchnummeriert werden sollen, da es zwar wahrscheinlich ist, dass in Reihenfolge der Anlage, aber darauf würde ich mich nicht verlassen.Deshalb eher wie in #20

NoPlayBack · April 18, 2023 at 10:47 AM

Doch macht er... habe ein paar Tests mit einer Kopie gemacht und via HeidiSQL eine Spalte ID erzeugt, Primary Key drauf, AutoIncrement gewählt, und beim Speichern ging die SW in eine Denkpause und die Prozessorlast auf dem RaspberryPI etwas hoch. Nach 4 Minuten (für 2,5 Mio Datensätze) meldete sich die SW zurück und die Spalte war durchnummeriert...

Bot · Vor einem Moment

**hyle** · April 18, 2023 at 10:52 AM

Ok, das überzeugt mich!

NoPlayBack · April 21, 2023 at 2:50 PM

Sodele... aktueller Stand der Dinge:

Ich habe einen Testlauf mit einer Kopie der DB gemacht (> 5 Mio records) , und mit Eurer Hilfe und Hinweisen werde ich so wohl mit dem Problemchen fertig werden:

ALTER TABLE `db` ADD `id` INT unsigned NOT NULL AUTO_INCREMENT PRIMARY KEY FIRST;

Dauerte 10 min. Dann war der Index erzeugt und gefüllt.

Dann Reihenfolge checken... da scheine ich Glück zu haben, die ID nummeriert die Datensätze in der Reihenfolge der Entstehung durch.

ALTER TABLE `db` ADD `ts` BIGINT unsigned AFTER ID;

Damit habe ich Platz für den Unix-Timestamp.

Den aber mit Werten zu füllen war tricky, ich habe nix gefunden was das macht. Also habe ich mich einfach für diese Session in die UTC-Zeitzone versetzt:

SELECT @@GLOBAL.time_zone, @@SESSION.time_zone;

SET time_zone = '+00:00';

SELECT @@GLOBAL.time_zone, @@SESSION.time_zone;

Damit sieht man in welcher Zeitzone man ist, dann wird umgestellt, und danach nochmal gecheckt.

(Nach dem Beenden der Session und bei einer neuen Session ist die Original-Einstellung wieder aktiv)

update db set ts = UNIX_TIMESTAMP(UTC) * 1000;

10 min Dauer... dann waren alle Timestamps erzeugt (im Millisekunden-Format).

Dann Index darüber erstellen (hatte ich in HeidiSQL gemacht)

Zum Schluss wollte ich dann noch meinen DATETIME Eintrag von UTC ebenfalls auf Microsekunden umstellen, ich wusste gar nicht dass das möglich ist:

ALTER TABLE db MODIFY ZeitpunktUTC DATETIME(3);

das braucht ca. 6 Minuten. Dann sind die Zeiten im Format "2023-04-21 10:14:42.863"

Lustigerweise brauche ich die Korrektur wegen doppelten Uhrzeiten gar nicht... das war ein Denkfehler, ich hatte die Einträger der lokalen Zeit geprüft. Die UTC-Zeiten waren alle ein-eindeutig.

An dieser Stelle noch einmal Danke für alle Tips !!!

noisefloor · April 21, 2023 at 3:24 PM

Hallo,

Danke für's Feedback und schön, dass das alles gut funktioniert hat.

Gruß, noisefloor

Bot · Vor einem Moment

Participate now!