MYSQL InnoDB-Engine-Indizierung (B-Tree), und One-to-One-Beziehung

Question

Kurz gesagt, Indizes sind am besten für Spalten, die häufig in Where-Klauseln verwendet werden, und in jeder Art von Sortierung, wie "Reihenfolge durch ", und auch mit hohen Kardinalitäts-Spalten. Auf der anderen Seite verlangsamen Indizes, wenn sie übertrieben sind, Schreibvorgänge und belegen außerdem viel Speicherplatz auf der Festplatte.

Ich habe einen Benutzer-Registrierungstabelle mit den folgenden Feldern:

  ID INT(11) UNSIGNED NOT NULL AUTO_INCREMENT, 
      User_name VARCHAR(35) NOT NULL, 
      BirthDay DATE NOT NULL, 
      password CHAR(70) NOT NULL, 
      Security_hint VARCHAR(27) NOT NULL, 
      Email VARCHAR(225) NOT NULL, 
      userType ENUM ('a','b','c','d') NOT NULL DEFAULT 'a', 
      Signup_Date TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP, 
      activation TINYINT(1) UNSIGNED NOT NULL, 
      Ip BINARY(16) NOT NULL, 
      PRIMARY KEY (ID), 
      UNIQUE KEY User_name (User_name,Email) 

1. Ich bin sehr davon überzeugt, mit den Datentypen I für alle Felder ausgewählt haben.
2. die Felder Signup_Date und Security_hint werden selten gegen abgefragt werden, so entschied ich mich, sie in einer separaten Tabelle zu isolieren und verwenden 1-1 Beziehung mit Fremdschlüsseln. Ist diese Strategie effizient? Gibt es einen Leistungseinbruch, der aus dieser Strategie resultieren könnte?
3. WICHTIG: Muss ich auch das PASSWORD-Feld indizieren, um den Anmeldevorgang sehr schnell zu machen?

Vielen Dank Jungs im Voraus.

EDIT: meine Login-Abfrage ist SELECT columns FROM users WHERE username = "x" AND password = "stuff". Ich verwende Index für E-Mail nur die Überprüfung einer bestehenden E-Mail schnell zu machen, wie E-Mails und Benutzernamen für jeden Benutzer eindeutig sein muss

Answer 1

AD 1: E-Mail ist normalerweise definiert als VARCHAR (255), nicht 225. Sie speichern Passwort als CHAR (70) - Ich nehme an, Sie verwenden einige Hash, die genau 70 Bytes zurückgibt, sonst sollten Sie VARCHAR verwenden.

AD 2: 1-zu-1-Beziehungen funktionieren im Allgemeinen schlecht, da Sie JOINs ausführen müssen.Die einzige Situation, die ich in Betracht ziehen würde, Daten mit einer 1-zu-1-Beziehung zu trennen, ist, wenn ein Teil der ursprünglichen Tabelle SCHWER geschrieben wird. In diesem Fall trennen Sie diesen Teil, sodass Sie die Indizes für andere Spalten nicht ständig neu erstellen müssen.

AD 3: Ich nehme an, Sie so etwas wie folgt verwenden:

SELECT * 
FROM users 
WHERE username = "myname" AND password = sha256("mypass") AND activation = 1 

alle in diesem Fall durchsucht Spalten indiziert werden müssen: username, password, activation.

AD eindeutiger Schlüssel: UNIQUE KEY User_name (User_name,Email) bedeutet, dass Sie mehr Benutzer mit demselben Benutzernamen und verschiedenen E-Mails haben können und umgekehrt. Sie sollten 2 separate eindeutige Schlüssel verwenden, um alle Benutzernamen und E-Mails eindeutig zu machen.

Answer 2

die Felder Signup_Date und Security_hint selten gegen abgefragt werden, so entschied ich mich zu isolieren sie in einer separaten Tabelle und verwenden 1-1 Beziehung mit Fremdschlüsseln. Ist diese Strategie effizient? Gibt es einen Leistungseinbruch, der aus dieser Strategie resultieren könnte?

Ich sehe keinen Wert im Umgang damit auf diese Weise. Wenn es die Größe Ihrer Tabelle nicht kritisch beeinflusst, fügen Sie nur unnötige Joins hinzu.

WICHTIG: Muss ich auch das PASSWORD-Feld indexieren, um den Anmeldevorgang sehr schnell zu machen?

Hängt von Ihrem Login ab.

Wenn Sie mit so etwas wie:

SELECT columns FROM users WHERE username = "x" AND email ="y" AND password = "stuff" 

Sie in Ordnung sein wird, wie die index und unique-constraint von username + email kümmern sie den Benutzer durch index Verwendung finden.

Wenn Sie nur für Benutzername und Passwort in Ihrem Login einchecken, könnte ein Index auf (Benutzername, Passwort) Sinn machen IF Sie denken, es VIEL der Nutzer mit dem gleichen Benutzernamen sein. Andernfalls wird der Index für den Benutzernamen verwendet und ist normalerweise auch schnell.