Der Unterschied zwischen SQL aus mehreren Tabellen und Inner Join

So schreibt man Inner Join

<code>SELECT
    B.dict_data_name,
    SUM(A.pv) AS pv
FROM
    shw_mo_health_news A
INNER JOIN bas_dict_data B ON A.third_name_dictid = B.item_id
WHERE
    A.class_level = 3
AND B.class_id = 1012
AND A.collect_date >= '2016-04-01'
AND A.collect_date <= '2016-05-31'
GROUP BY
    A.third_name_dictid
ORDER BY
    pv DESC;</code>

Die tatsächliche Abfragezeit für Benutzer beträgt etwa 0,6 Sekunden

Ansicht mit Erklärung:

---

So schreiben Sie aus mehreren Tabellen

<code>SELECT
    B.dict_data_name,
    A.PV
FROM
    (
        SELECT
            hn.third_name_dictid,
            SUM(hn.pv) AS PV
        FROM
            shw_mo_health_news hn
        WHERE
            hn.class_level = 3
        AND hn.collect_date >= '2016-04-01'
        AND hn.collect_date <= '2016-05-31'
        GROUP BY
            hn.third_name_dictid
    ) A,
    (
        SELECT
            dd.item_id,
            dd.dict_data_name
        FROM
            bas_dict_data dd
        WHERE
            dd.class_id = 1012
    ) B
WHERE
    A.third_name_dictid = B.item_id
ORDER BY
    PV DESC</code>

Die tatsächliche Zeit beträgt etwa 0,03 Sekunden

Ansicht erklären

---

Warum gibt es einen so großen Unterschied in der Effizienz dieser beiden Abfragemethoden?
Viele Leute im Internet sagen, dass die Effizienz dieser beiden Schreibmethoden fast gleich ist, aber meine eine ist 0,6 und die andere 0,03, der Unterschied zwischen den beiden ist immer noch ziemlich groß. Liegt es daran, dass mit der SQL-Anweisung, die ich geschrieben habe, etwas nicht stimmt, oder liegt es an etwas anderem?

Antwortinhalt:

So schreibt man Inner Join

<code>SELECT
    B.dict_data_name,
    SUM(A.pv) AS pv
FROM
    shw_mo_health_news A
INNER JOIN bas_dict_data B ON A.third_name_dictid = B.item_id
WHERE
    A.class_level = 3
AND B.class_id = 1012
AND A.collect_date >= '2016-04-01'
AND A.collect_date <= '2016-05-31'
GROUP BY
    A.third_name_dictid
ORDER BY
    pv DESC;</code>

Die tatsächliche Abfragezeit für Benutzer beträgt etwa 0,6 Sekunden

Ansicht mit Erklärung:

---

So schreiben Sie aus mehreren Tabellen

<code>SELECT
    B.dict_data_name,
    A.PV
FROM
    (
        SELECT
            hn.third_name_dictid,
            SUM(hn.pv) AS PV
        FROM
            shw_mo_health_news hn
        WHERE
            hn.class_level = 3
        AND hn.collect_date >= '2016-04-01'
        AND hn.collect_date <= '2016-05-31'
        GROUP BY
            hn.third_name_dictid
    ) A,
    (
        SELECT
            dd.item_id,
            dd.dict_data_name
        FROM
            bas_dict_data dd
        WHERE
            dd.class_id = 1012
    ) B
WHERE
    A.third_name_dictid = B.item_id
ORDER BY
    PV DESC</code>

Die tatsächliche Zeit beträgt etwa 0,03 Sekunden

Ansicht erklären

---

Warum gibt es einen so großen Unterschied in der Effizienz dieser beiden Abfragemethoden?

Viele Leute im Internet sagen, dass die Effizienz dieser beiden Schreibmethoden fast gleich ist, aber meine eine ist 0,6 und die andere 0,03, der Unterschied zwischen den beiden ist immer noch ziemlich groß. Liegt es daran, dass mit der SQL-Anweisung, die ich geschrieben habe, etwas nicht stimmt, oder liegt es an etwas anderem?

Es sollte ein Verbindungsverlust sein, weil die von Ihnen verwendeten Bedingungen keine Indizes haben. Wenn die Felder entsprechend indiziert sind, ist die sogenannte Optimierung zu diesem Zeitpunkt nicht vorhanden, da MySQL die SQL-Anweisung automatisch optimiert Die endgültige Abfrageanweisung entspricht im Wesentlichen der von Ihnen übermittelten SQL-Anweisung.

Sie können es versuchen

Ich denke, die Leistung wird merklich anders sein.

<code>SELECT
    B.dict_data_name,
    SUM(A.pv) AS pv
FROM
    shw_mo_health_news A
INNER JOIN bas_dict_data B ON A.class_level = 3 and A.collect_date >= '2016-04-01'
AND A.collect_date <= '2016-05-31' and B.class_id=1012 and  A.third_name_dictid = B.item_id

GROUP BY
    A.third_name_dictid
ORDER BY
    pv DESC;</code>

Das Gleiche gilt, es gehört zu unterschiedlichen Spezifikationen von SQL-89 und SQL-92. Siehe https://en.wikipedia.org/wiki...

Ich habe eine verwandte Frage und Antwort gefunden, und eine der Antworten ist genau Ihre Frage https://community.microstrate...

---

Das zweite SQL hier wird aufgrund der Unterabfrage zusätzlichen Overhead (temporäre Tabelle) haben.

Warum ist das zweite SQL besser als das erste SQL? Es fühlt sich an, als wäre es nur eine Ausnahme und bedeutet nichts

Theoretisch gibt es keinen wesentlichen Unterschied zwischen Unterabfragen und

und sie sollten nach angemessener Optimierung durch den Abfrageanalysator gleichwertig sein. Es liegt jedoch gerade an verschiedenen Fehlern im Abfrageanalysator, dass einige Versionen der Datenbank Unterabfragen manchmal besser und andere

besser unterstützen. Bei MySQL entsprechen die meisten Versionen von Unterabfragen, die ich gesehen habe, JOIN. Seien Sie jedoch vorsichtig, wenn sich die Unterabfrage in JOIN befindet, z. B.: JOIN WHERE

Dies ist ein typisches Fehlerszenario des MySQL-Abfrageanalysators. Theoretisch sollten Abfrage 1 und Abfrage 2 gleichwertig sein, wenn das Feld

<code>-- 查询1
SELECT * FROM table_a
WHERE A IN (
    SELECT A FROM table_b
    WHERE B = 'x'
)
-- 查询2
SELECT table_a.* FROM table_a A
    INNER JOIN table_b B ON a.A = b.A
WHERE B.B = 'x'</code>

von

einen Index hat. Tatsächlich ist die Leistung von Abfrage 2 in der MySQL 5.x-Version jedoch deutlich besser als die von Abfrage 1. Dies wurde auf Stackoverflow diskutiert und ist ein bekanntes Problem, das seit fast 10 Jahren besteht. Sie müssen auf 6.0.x aktualisieren, um den Fix zu erhalten. Für die Frage, welches besser ist, ist es daher am zuverlässigsten, sich die Ergebnisse selbst anzusehen, bevor man eine Schlussfolgerung zieht. table_aFür Ihre beiden Abfragen sind die Ausführungspläne tatsächlich unterschiedlich. Es ist offensichtlich, dass die zweite Abfrage mehr Geld verbraucht und die Zeit fast gleich ist, da die durch die beiden zusätzlichen Schritte erhaltene Datenmenge nicht zu groß ist. Darüber hinaus sind diese beiden Abfragen tatsächlich nicht gleichwertig und können nicht verglichen werden. A