Detaillierte Einführung in den Austausch von MySQL-Optimierungskenntnissen

Dieser Artikel stellt hauptsächlich das Teilen von MySql SQL-Optimierungsfähigkeiten vor. Es ist sehr gut und hat Referenzwert.

Eines Tages habe ich ein SQL gefunden Inner Join ist zwar nicht sehr langsam (0,1-0,2), erreicht aber nicht die ideale Geschwindigkeit. Die beiden Tabellen stehen in Beziehung, die zugehörigen Felder sind Primärschlüssel und die abgefragten Felder sind eindeutige Indizes.

Die SQL lautet wie folgt:

SELECT
p_item_token.*,
p_item.product_type
FROM
p_item_token
INNER JOIN p_item ON p_item.itemid = p_item_token.itemid
WHERE
p_item_token.token ='db87a780427d4d02ba2bd49fac8xxx';

Wobei in der Tabelle p_item_token itemid der Primärschlüssel und token der eindeutige Index ist. itemid in p_item ist der Primärschlüssel

Entsprechend der idealen Geschwindigkeit sollte sie etwa 0,03 s betragen. Der tatsächliche Wert liegt jedoch bei etwa 0,2, was viel langsamer ist.

Erklären Sie direkt, um den Plan zu sehen

EXPLAIN
SELECT
  p_item_token.*,
  p_item.product_type
FROM
  p_item_token
INNER JOIN p_item ON p_item.itemid = p_item_token.itemid
WHERE
  p_item_token.token = 'db87a780427d4d02ba2bd49fac8xxx';

Ergebnis:

Achten Sie auf das große rote Kästchen oben. Die p_item-Tabelle enthält 2w Datenelemente, es handelt sich also um einen vollständigen Tabellenscan.

Das ist nicht normal.

Showwarnungen hinzufügen und einen Blick darauf werfen. Hinweis: In einigen Fällen führt SHOW WARNINGS zu keinen Ergebnissen. Den Grund kenne ich noch nicht. Es wird empfohlen, mit einer lokalen Testdatenbank zu arbeiten.

EXPLAIN
SELECT
  p_item_token.*,
  p_item.product_type
FROM
  p_item_token
INNER JOIN p_item ON p_item.itemid = p_item_token.itemid
WHERE
  p_item_token.token = 'db87a780427d4d02ba2bd49fac8xxx';
SHOW WARNINGS;

Ergebnis 2 zeigt code=1003 Dahinter steckt eine SQL-Anweisung. Diese Anweisung ist die letzte Anweisung, die von MySQL ausgeführt wird, nachdem die von uns eingegebene SQL-Anweisung gemäß den Regeln neu geschrieben wurde.

/* select#1 */
SELECT
  '0000eb612d78407a91a9b3854ffffffff' AS `itemid`,    /*注:直接按主键把值查出来了*/
  'db87a780427d4d02ba2bd49fac8cf98b' AS `token`,    
  '2016-12-16 10:46:53' AS `create_time`,        
  '' AS `ftoken`,                    
  `p_db`.`p_item`.`product_type` AS `product_type`  
FROM
  `p_db`.`p_item_token`
JOIN `p_db`.`p_item`
WHERE
  (
    (
      CONVERT (
        `p_db`.`p_item`.`itemid` USING utf8mb4
      ) = '0000eb612d78407a91a9b3854fffffff'
    )
  )

Das ist seltsam. Warum gibt es CONVERT in Wo? Wir wissen, dass eine -Funktion auf der linken Seite der Gleichung in der Where-Bedingung, also dem abzufragenden Feld, zu einer Verlangsamung führt. (Mein Verständnis: Es ist langsam, weil der Index nicht auf verweisen kann. Der Wert des Index ist der ursprüngliche Wert, aber in diesem Zustand wird der verarbeitete Wert verwendet.)

Beachten Sie dies Funktion, Es bedeutet, die Kodierung der Spalte „itemid“ in utf8mb4 zu konvertieren. Mit anderen Worten, die Kodierung dieser Spalte ist nicht utf8mb4!

Öffnen Sie die Tabelle und ändern Sie die Kodierung der Spalte „itemid“. beide Tabellen auf utf8. Führen Sie „explain“ erneut aus.

Den Interpretationsergebnissen nach zu urteilen, gibt es kein Problem.

Sehen Sie sich die Anweisung in Ergebnis 2 an:

/* select#1 */
SELECT
  '0000eb612d78407a91a9b3854fffffff' AS `itemid`,
  'db87a780427d4d02ba2bd49fac8cf98b' AS `token`,
  '2016-12-16 10:46:53' AS `create_time`,
  '' AS `ftoken`,
  'cxx' AS `product_type`
FROM
  `toy_item_plat`.`p_item_token`
JOIN `toy_item_plat`.`p_item`
WHERE
  1

Diese Auswahl besteht ausschließlich aus Konstanten. Kann es schneller sein?

Das Ausführungsergebnis beträgt 0,036 Sekunden. Entspricht den Erwartungen

Erfahrungszusammenfassung:

Erklären Sie, ob der Ausführungsplan den Erwartungen entspricht. Wenn große Zeilen vorhanden sind, bedeutet dies, dass ein vollständiger Tabellenscan stattgefunden hat wird in Zukunft zu einem Leistungsengpass führen

Warnungsergebnisse anzeigen, Sie können die vom Optimierer verarbeitete Anweisung sehen. Sollte es Abweichungen von der ursprünglichen Aussage geben, kann ein sorgfältiger Vergleich und eine sorgfältige Untersuchung das tatsächliche Problem aufdecken.

Das obige ist der detaillierte Inhalt vonDetaillierte Einführung in den Austausch von MySQL-Optimierungskenntnissen. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!