Ich habe eine Spalte gelöscht in meiner Tabelle. Auf jeder SQL-Anweisung überprüfe ich, ob dieses Flag NULL ist. Möchte jemand Einträge löschen, wird das Flag auf den aktuellen Zeitstempel gesetzt.
Wenn Einträge wiederhergestellt werden sollen, wird dieser Zeitstempel verwendet, um sie wiederherzustellen. Dies ist der einzige Anwendungsfall, wenn der Wert dieser Spalte verwendet wird.
In allen anderen Fällen ist es nur wichtig zu wissen, ob es NULL ist oder NICHT NULL.
In der Zukunft kann und wird die Tabelle Millionen von Zeilen enthalten.
Ist es nützlich, einen Index für diese Spalte zu erstellen? Weil 99% der Aussagen & amp; Anwendungsfälle interessieren den Wert nicht. Optimiert MySQL IS NULL-Bedingungen und daher wird kein Index benötigt?
Ein Index für 'deleted' indexiert auch NULL-Werte und ermöglicht so schnellere Lookups von nicht-null / null
Ich denke, das wird in diesem Fall ausreichen und nicht zu viel Overhead verursachen, da der Timestamp beim Löschen gesetzt ist und daher nicht so viel geändert wird. (Das Gegenteil: Die Verwendung eines Bearbeitungszeitstempels, der ständig geändert wird und nur manchmal auf Null gesetzt wird, würde dazu führen, dass der Index bei jeder Änderung eines Datensatzes angepasst wird. Das ist möglicherweise nicht optimal. Das ist hier nicht der Fall.)
(Auch wenn ich nicht weiß, ob der Indexer schlau genug ist, davon zu profitieren, gehen die erwarteten Änderungen immer an die Enden des Index, entweder am Null-Ende oder am "jüngsten" Ende .)
Natürlich, Profil (sowohl Abfrage Ausführungszeiten und Speicherplatz wenn wichtig) um herauszufinden, ob es tatsächliche Probleme daraus entstehen.
Sie können keine "Archiv" -Tabelle erstellen und gelöschte Zeilen mit ihrem Zeitstempel speichern. Wenn der Benutzer eine Zeile wiederherstellen möchte, müssen Sie diese aus dem Archiv in Ihre Haupttabelle übertragen.
Und Sie müssen nicht "Flag IS NOT NULL" in jeder Abfrage überprüfen