Löschen alter Datensätze aus einer MySQL-Tabelle, aber ein Backup beibehalten

Question

Ich habe eine MYSQL-Tabelle, die nur Daten bis zu 30 Tage vor dem heutigen Datum benötigt. Es hat Daten, die bis zu ein paar Jahren nach dem heutigen Datum sein können. Für eine schnellere Abfrage lösche ich normalerweise die alten Datensätze, da ich keinen Sinn darin sehe, die alten Datensätze zu durchsuchen. Ich verwalte jedoch immer noch eine Sicherungskopie der Datensätze, wenn wir sie jemals für Analysen benötigen. Die Original-Tabelle ist dies:

CREATE TABLE featured_deal (
    id INT NOT NULL AUTO_INCREMENT PRIMARY KEY, 
     fsa VARCHAR(10), 
     poster_id int(11), 
     dealid bigint(20), 
     bookedDate date, 
     createDate timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP, 
    UNIQUE KEY `featured_unique`(fsa, bookedDate) 
    ) 

Und ich erstellen Sie eine Tabelle, die eine Nachbildung dieser Tabelle ist Geschichte genannt:

CREATE TABLE featured_deal_history (
      id INT NOT NULL AUTO_INCREMENT PRIMARY KEY, 
       fsa VARCHAR(10), 
       poster_id int(11), 
       dealid bigint(20), 
       bookedDate date, 
       createDate timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP, 
      UNIQUE KEY `featured_unique`(fsa, bookedDate) 
      ) 

Ich habe einen Trigger, um die Geschichte Tabelle zu füllen, wenn ein Einsatz auf das geschieht Original-Tabelle:

CREATE TRIGGER `featured_to_history` 
      AFTER INSERT ON lst_enmasse_featured_deal 
      FOR EACH ROW 
      INSERT INTO lst_enmasse_featured_deal_history (fsa,poster_id,dealid,bookedDate,createDate) 
      VALUES (NEW.fsa,NEW.poster_id,NEW.dealid,NEW.bookedDate,NEW.createDate) 

Schließlich reinige ich die Tabelle einen cron-Job verwenden und den Befehl:

DELETE * FROM featured_deal WHERE bookedDate < DATE_SUB(CURDATE(), INTERVAL 30 DAY) 

Gibt es einen besseren Weg, die obige Aufgabe zu erfüllen? Ich habe über MYSQL Partitions nachgedacht. Ich habe jedoch keine feste Partition. Das Datum ändert sich und daher würde ich jeden Tag zwei neue Partitionen brauchen.

Answer 1

Im Prinzip ist Ihre Vorgehensweise in Ordnung, aber das Konzept basiert auf der Idee, dass eine kleinere Tabelle leistungsfähiger ist. Dies führt dazu, dass in Ihren Abfragen vollständige Tabellendurchsuchungen für die Daten ausgeführt werden, d. H. Sie haben Ihre Indizes nicht korrekt konfiguriert.

Ich schlage vor, dass das erste, was Sie beheben, ist die Leistung Ihrer Abfragen.

Wenn Sie immer noch Sachen aus der Hot-Datentabelle heraushalten müssen, sollten Sie versuchen, irgendwelche Inserts in die History-Tabelle als Bulk-Operation NICHT eine Reihe zu einer Zeit zu tun - dies wird die Tabelle und Indizes in einem gesunden halten Zustand. Dies könnte in einer Batch-Operation erfolgen, wie von Cristian vorgeschlagen, oder Sie könnten eine stochastische Methode verwenden (mit einer Statusvariablen in der Quellentabelle). z.B. etwas wie ...

Eine weitere Überlegung ist, dass Sie eine neue ID generieren, wenn Sie in die Verlaufstabelle schreiben: Warum?

Answer 2

Ich würde es einfacher machen. Erstellen Sie einen täglichen Cron, die diese beiden queryes mit „today_date“ ausführt:

create table if not exists featured_deal_new like featured_deal 
rename table featured_deal to featured_deal_history_TODAY_DATE, featured_deal_new to featured_deal 

Was geschieht: (Umbenennung Tabellen ist sehr schnell). Sie werden eine Geschichtstabelle für jeden Tag haben.

frei Spüren Sie die Geschichte Tabellen danach auf die Einsätze in der Haupttabelle

insert into featured_deal_history... select * from featured_deal_history_TODAY_DATE

Drop table featured_deal_history_TODAY_DATE 

diese Weise können Sie nicht verlieren Leistung zu kombinieren.