MySQL5.6 vs Percona 5.7 implizite Konvertierung Problem

Question

Wir haben vor kurzem ein Upgrade von mySQL5.6 zu Percona-Server 5.7 und die Verwendung von tokuDB-Tabellen getestet. Die Datenbank dient unserer PHP 5.5-Anwendung, die die PDO-Bibliothek für parametrisierte Abfragen verwendet.

Nachdem wir Percona mit identischen Daten in eine Tokudb-Tabelle geladen und die Leistung mit der bestehenden Produktion verglichen hatten, bemerkten wir sofort einen enormen Leistungsabfall (10x langsamer). Für die Abfragen unter nehmen die Tabelle 12 Millionen Zeilen hat

Ich habe in der Lage, dieses Problem zu verengen in der 5.7 Datenbank der Tatsache, dass bei der Ausführung einer Abfrage wie:

SELECT * FROM TABLE WHERE id='12345'; -- exec time 10.5sec 
vs. 
SELECT * FROM TABLE WHERE id=12345; -- exec time 1.3sec 

wobei id der Spaltenart Integer. Es war mein Eindruck und meine Forschung scheint zu bestätigen, dass mySQL implizite Konvertierung von '12345' zu 12345 durchführen sollte, wenn die verglichene Spalte ein numerischer Typ ist, dies scheint jedoch nicht in mySQL5.7/Percona zu geschehen. Es geschah in mySQL5.6x

Das Problem hier ist, dass Sie mit diesem Verhalten explizit den Typ mit PDOStatement :: bindParam (ref http://php.net/manual/en/pdostatement.bindparam.php) für jede Variable festlegen müssen! Dies würde zu einem fast globalen Neuschreiben aller vorbereiteten Anweisungen führen, die derzeit Parameterarrays an PDOStatement übergeben: execute(), das keine explizite Typeinstellung unterstützt!

Also - meine Frage ist das - hat sich etwas in mySQL geändert so implizite Konvertierung ist nicht in 5.7 getan oder ist es Percona oder ist es tokuDB Tabelle? Gibt es einen Konfigurationsparameter, den ich einstellen kann, um diesen wieder einzuschalten?

Answer 1

Es ist nicht klar, wenn Sie versuchen, 5.6 TokuDB Leistung zu 5.7 TokuDB Leistung oder 5.6 InnoDB zu 5.7 TokuDB zu verbessern und zu vergleichen, können Sie bitte die spezifischen 5.6 und 5.7 Varianten und Versionen klären und identifizieren?

Wenn TokuDB rundherum, eine Möglichkeit ist falsche Indexauswahl aufgrund von schlechten/alten/NULL-Index-Statistiken. Es gibt auch viele SQL_MODE-Standardänderungen in 5.7, von denen einige auch das Verhalten beeinflussen könnten.

Es kann auch nützlich sein, die Ergebnisse von 'SHOW CREATE TABLE' und 'SHOW INDEXES FROM' sowohl in den Instanzen 5.6 und 5.7 zu sehen.