Wie falsch ist es einen einzigartigen und normalen Index auf der gleiche Spalte zu haben?

Question

Ich habe die folgende Tabellenstruktur

CREATE TABLE `table` (
  `id` int(11) NOT NULL auto_increment,
  `date_expired` datetime NOT NULL,
  `user_id` int(11) NOT NULL,
  `foreign_id` int(11) NOT NULL,
  PRIMARY KEY  (`id`),
  UNIQUE KEY `date_expired` (`date_expired`,`user_id`,`foreign_id`),
  KEY `user_id` (`user_id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

Wie Sie bemerken, ich habe doppelten Indizes auf user_id: date_expired & user_id. Ich möchte natürlich den eindeutigen Index, weil ich die Daten eindeutig sicherstellen wollen.

Der Grund für die doppelte Indizes ist, weil ohne den user_id Index, meine Haupt-Suchabfrage 4 Sekunden dauert. Mit dem zusätzlichen Index dauert es 1 Sekunde. Die Abfrage schließt sich in der Tabelle auf user_id und Überprüfung date_expired.

Die Tabelle hat nur 275 Datensätze.

• Wie schlimm es ist ein einzigartiges und normalen Index auf dem gleichen Feld zu haben?
• Wie schlimm ist es zu haben größere Indizes als Daten, wenn die Tabelle rein ids ist?

Answer 1

Ich glaube, wenn Sie Ihren eindeutigen Index als (user_id, date_expired, foreign_id) erstellt, können Sie den gleichen Nutzen einen normalen Index auf user_id des Habens nur mit dem eindeutigen Index erhalten werden. MySQL kann die ersten Spalten von jedem Index verwenden, um die Anzahl der Zeilen in der Verknüpfung in der gleichen Weise wie ein Index auf user_id pare unten.

Siehe MySQL-Index Dokumentation mehr Informationen.

Beziehen Sie sich auf die id auto_increment Spalte an anderer Stelle in Ihrem Schema Platz zu sparen? Da Ihr eindeutigen Index alle anderen Spalten in der Tabelle verdeckt, ist im Wesentlichen ein Primärschlüssel selbst und fallen gelassen werden könnte, wenn Sie nicht.

Sie können überprüfen, welche Tasten Sie Ihre Abfrage durch das Vorsetzen verwendet sie mit EXPLAIN.

Answer 2

Ich verstehe nicht, was Sie durch doppelten Indizes bedeuten können. Sie haben drei Indizes in der Tabelle:

1. Ein für den Primärschlüssel 'id'
(die einzigartig impliziert)
2. Ein weiteres einzigartiges eine für die Kombination von 'date_expired', 'user_id' und 'foreign_id'
3. Und ein dritter über 'user_id' nur

, so gibt es keine Überschneidungen, haben Sie drei verschiedenes Indizes, die verschiedene Dinge tun werden. Sie müssen Nummer 3 zu beschleunigen Suchen user_id das ist, was Sie sehen. Also es ist nichts falsch mit diesem Tisch, Sie sind nicht etwas zu duplizieren. In Bezug auf die zweite Frage hängt es von Ihren Bedürfnissen, aber es ist sicherlich nicht schlecht , um mehr Platz in Indizes verbraucht haben als in den Daten.

Was wäre schlecht, zum Beispiel, ist ein einzigartigen haben ( ‚user_id‘) und später einen Schlüssel ( ‚user_id‘) (Ich bin nicht einmal sicher, ob MySQL, dass erlauben), weil ein Index, der die andere enthalten würde und es gibt nichts zu gewinnen.

Answer 3

Nachdem mehrere Indizes einschließlich einem Feld gar nicht so schlecht ist (im Wesentlichen, sie tun Index verschiedene Dinge). Es hat einen geringen Einfluss auf Schreib perfomance, aber das ist der typische Kompromiss Sie mit jedem Index in erster Linie haben. Indizes essen mehr Speicherplatz als die Daten, die an sich ist nicht schlecht, wenn Platz ist billig. In Ihrem Fall, sollte es billig sein angesichts der Tatsache, dass Sie eine wirklich kleine Menge von Einträgen haben.

Die Frage, die ich in Ihrer Position fragen würde, ist: Wie funktioniert die Indizierung eines solchen kleinen Tisch so meine Query-Laufzeit severly beeinflussen? Vielleicht machst du etwas falsch (Ich denke über viele möglicherweise überflüssig querys dieser Tabelle), als einziger mit dieser geringen Anzahl von Einträgen bei weitem nicht diesem Zeitbereich sein sollte).