MySQL Query gibt ungültige Zeilen zurück und sehr langsam

Question

Ich schreibe eine Abfrage, um Spielerverbote aus einer anderen Tabelle auszuwählen, aber erstens dauert es sehr langsam 7-14 Sekunden und zweitens gibt es ungültige Zeilen zurück.

Die erste Abfrage lautet wie folgt:

SELECT * 
FROM sourcebans.sb_bans 
WHERE removetype IS NULL 
     AND removedon IS NULL 
     AND reason NOT LIKE '%[FragSleuth] Duplicate account%' 
     AND ip IN(SELECT DISTINCT ip 
       FROM fragsleuth.history 
       WHERE trackingid = "ad000c3803b48190aabf382e01b957c9") 
     OR authid IN(SELECT DISTINCT steamid 
        FROM fragsleuth.history 
        WHERE trackingid = "ad000c3803b48190aabf382e01b957c9") 

Die zweite Abfrage ist als

folgt

SELECT * FROM `history` WHERE trackingid = "ad000c3803b48190aabf382e01b957c9" 

Und ein paar Screenshots zu zeigen, was ich meine: First QuerySecond Query

In screenshot 1 Sie können sehen, dass es eine Zeile zurückgibt, wo der removedon und removeType nicht null ist, wenn ich gefragt habe Abfrage, um nur Zeilen mit NULL zurückzugeben.

Ich habe auch Angst, dass in der History-Tabelle doppelte Einträge für die Spalten steamid und ip, die die Abfrage verlangsamen könnte, gibt es eine Möglichkeit, die Abfrage nur Zeilen mit einer eindeutigen IP oder Steamid basieren auf die Tracking-ID?

Jede Hilfe würde sehr geschätzt werden.

Dank

Edit: Ich mit Hilfe überwältigt bin, Dank @maraca, @Skorpioh und @ Adam Silenko, ist die Abfragezeit jetzt weniger als eine Sekunde!

Answer 1

Die Abfrage gibt Zeilen, die nicht NULL sind, weil es als
(... AND ... AND ...) OR ... statt
... AND ... AND (... OR ...)

Sie eine Zahnspange So interpretiert hinzufügen müssen, auch die DISTINCT ist nicht erforderlich:

SELECT * 
FROM sourcebans.sb_bans 
WHERE removetype IS NULL 
     AND removedon IS NULL 
     AND reason NOT LIKE '%[FragSleuth] Duplicate account%' 
     AND (ip IN(SELECT ip 
       FROM fragsleuth.history 
       WHERE trackingid = "ad000c3803b48190aabf382e01b957c9") 
     OR authid IN(SELECT steamid 
        FROM fragsleuth.history 
        WHERE trackingid = "ad000c3803b48190aabf382e01b957c9")) 

Answer 2

die und haben dann eine höhere Priorität oder ... Sie müssen auf Ihre Tabellen indexieren np. add index zum trackingid-Feld in fragsleuth.history, wenn Sie nicht haben

Sie können wahrscheinlich schneller mit einer Unterabfrage tun, aber ich bin mir nicht sicher.

SELECT * 
FROM sourcebans.sb_bans 
WHERE removetype IS NULL 
AND removedon IS NULL 
AND reason NOT LIKE '%[FragSleuth] Duplicate account%' 
AND exists (
    SELECT 1 from fragsleuth.history 
    WHERE trackingid = "ad000c3803b48190aabf382e01b957c9" 
    and (ip = sourcebans.ip or steamid = sourcebans.authid)) 

Answer 3

Sie haben eine operatior precendence Problem hier und das ist, warum es endet Ergebnisse mit denen removetype/removedon nicht null ist.

Wenn Sie http://dev.mysql.com/doc/refman/5.7/en/operator-precedence.html überprüfen, sehen Sie, dass AND eine höhere Priorität als OR hat, was bedeutet, dass Ihre Abfrage alle Prädikate zusammen mit dem Operator "AND" ausführt und erst danach OR ein Spiel und der Rest spielt keine Rolle mehr.

Wenn ich nicht falsch liege die unten sollte korrekt funktionieren:

SELECT * 
FROM sourcebans.sb_bans 
WHERE removetype IS NULL 
     AND removedon IS NULL 
     AND reason NOT LIKE '%[FragSleuth] Duplicate account%' 
     AND 
      (
       ip IN (SELECT DISTINCT ip 
         FROM fragsleuth.history 
         WHERE trackingid = "ad000c3803b48190aabf382e01b957c9") 
       OR 
       authid IN(SELECT DISTINCT steamid 
          FROM fragsleuth.history 
          WHERE trackingid = "ad000c3803b48190aabf382e01b957c9") 
      ) 

Im Hinblick auf Verbesserungen in der Geschwindigkeit, sollten Sie zunächst einen abdeckenden Index für die removetype, removedon, ip und authid Spalten erstellen. Dies wird helfen, aber wahrscheinlich nicht genug, da die LIKE-Operation sehr teuer ist.

Das letzte, was Sie tun sollten, ist zu überprüfen, ob Sie

Grund NOT LIKE ändern kann '% [FragSleuth] Konto% Duplizieren'

in noch etwas anderes. Kannst du zum Beispiel das führende% eliminieren, damit es zumindest eine viel schnellere Übereinstimmung bringt? Hängt natürlich davon ab, was genau diese Spalten speichern.