Warum MySQL die Verwendung von Unterabfragen und Verknüpfungen nicht empfiehlt

So führen Sie eine paginierte Abfrage durch:

1. Für MySQL wird die Verwendung von Unterabfragen und Verknüpfungen nicht empfohlen, da die Effizienz von Verknüpfungen ein Nachteil ist. Sobald die Datenmenge groß ist, ist die Effizienz schwer zu gewährleisten. Es wird dringend empfohlen, Daten basierend auf dem Index aus einer einzelnen Tabelle abzurufen und die Daten dann im Programm zu verknüpfen und zusammenzuführen.
2. Verwenden Sie keine Unterabfragen, die Effizienz ist zu gering. Beim Ausführen von Unterabfragen muss MySQL temporäre Tabellen erstellen und diese temporären Tabellen nach Abschluss der Abfrage löschen. Daher wird die Geschwindigkeit der Unterabfragen bis zu einem gewissen Grad beeinträchtigt. Es gibt einen zusätzlichen Prozess zum Erstellen und Löschen temporärer Tabellen.
3. Wenn es sich um JOIN handelt, wird eine verschachtelte Abfrage verwendet. Die kleine Tabelle steuert die große Tabelle und ist über Indexfelder verknüpft. Wenn die Tabelle weniger Datensätze hat, ist das in Ordnung. Wenn es groß ist, kann es in der Geschäftslogik gesteuert und verarbeitet werden.
4. Die Datenbank befindet sich auf der untersten Ebene und stellt häufig den Engpass dar. Es wird empfohlen, die Datenbank nur als Datenspeichertool zu verwenden, ohne ihr geschäftliche Daten hinzuzufügen.

1. Vorteile der Application Layer Association

Machen Sie den Cache effizienter. Viele Anwendungen können die Ergebnisobjekte, die Einzeltabellenabfragen entsprechen, problemlos zwischenspeichern. Wenn sich eine Tabelle in der Zuordnung ändert, kann der Abfragecache nicht verwendet werden. Wenn sich eine Tabelle nach der Aufteilung selten ändert, kann die auf der Tabelle basierende Abfrage die Ergebnisse des Abfragecaches wiederverwenden.

Durch Aufteilen der Abfrage in einzelne Teile können Sperrkonflikte reduziert werden.

Durch die Erstellung von Verknüpfungen auf der Anwendungsebene lässt sich die Datenbank leichter aufteilen und eine hohe Leistung und Skalierbarkeit erreichen.

Auch die Effizienz der Abfrage selbst kann verbessert werden. Wenn Sie einen ID-Satz abfragen, kann MySQL durch die Verwendung von IN() anstelle einer Join-Abfrage die Abfrage in der Reihenfolge der IDs durchführen, was effizienter sein kann als ein zufälliger Join.

Dadurch kann die Anzahl redundanter Datensatzabfragen reduziert werden. Bei einer assoziativen Abfrage auf Anwendungsebene muss die Anwendung einen bestimmten Datensatz nur einmal abfragen, während eine assoziative Abfrage in der Datenbank Folgendes erfordern kann:

Um wiederholt auf einen Datenteil zuzugreifen. Aus dieser Sicht kann eine solche Rekonstruktion auch den Netzwerk- und Speicherverbrauch reduzieren.

Darüber hinaus entspricht dies der Implementierung eines Hash-Joins in der Anwendung, anstatt den Nested Loop Join von MySQL zu verwenden. In einigen Szenarien ist die Hash-Assoziation viel effizienter.

2. Anwendungsschichtzuordnungs-Nutzungsszenarien

Wenn die Anwendung die Ergebnisse einer einzelnen Abfrage bequem zwischenspeichern kann

Wenn Sie Daten auf verschiedene MySQL-Server verteilen können

Wann IN() anstelle einer Join-Abfrage verwendet werden kann

Es gibt viele gleichzeitige Szenarien und häufige DB-Abfragen, daher ist Sharding erforderlich

3. Gründe, warum ein Beitritt nicht empfohlen wird

1. Die DB steht unter großem wirtschaftlichen Druck und möchte diese Belastungen möglichst reduzieren. Wenn die Tabelle mehr als eine Million Seiten umfasst, führen Verknüpfungen zu einer Verschlechterung der Leistung.
2. Verteilte Unterbibliotheken und Untertabellen. Ein datenbankübergreifender Join wird derzeit nicht empfohlen. Derzeit weist die verteilte Middleware von MySQL eine schlechte Leistung beim Verbinden datenbankübergreifender Datenbanken auf.
3. Ändern Sie das Tabellenschema. Es ist einfacher, eine einzelne Tabellenabfrage zu ändern, aber sie ist nicht leicht zu finden und der Aufwand ist relativ hoch, wenn die für den Join geschriebene SQL-Anweisung geändert werden muss. Bei großen Systemen ist dies schwierig zu warten.

4. Lösung ohne Join

Auf der Geschäftsebene werden Daten, nachdem eine einzelne Tabelle abgefragt wurde, als Bedingung für die nächste Einzeltabellenabfrage verwendet. Das heißt, eine Unterabfrage. Ich befürchte, dass die Unterabfrage zu viele Ergebnismengen liefert. MySQL hat keine Begrenzung für die Anzahl der INs, aber MySQL begrenzt die Größe der gesamten SQL-Anweisung. Durch Anpassen des Parameters max_allowed_packet können Sie den Maximalwert einer SQL-Anweisung ändern. Es wird empfohlen, das Geschäft ordnungsgemäß abzuwickeln und den Ergebnissatz einer einzelnen Abfrage auf ein akzeptables Maß zu begrenzen.

5. Vorteile der Join-Abfrage

Der Vorteil einer verknüpften Abfrage besteht darin, dass sie paginiert werden kann und die Felder der sekundären Tabelle als Abfragebedingungen verwendet werden können. Bei der Abfrage werden die von der sekundären Tabelle übereinstimmenden Felder als Ergebnismenge verwendet und die primäre Tabelle wird darin verwendet. Das Problem besteht jedoch darin, dass es nicht funktioniert, wenn die Menge der übereinstimmenden Daten zu groß ist, und die zurückgegebenen Paging-Datensätze von den tatsächlichen abweichen. Die Lösung kann an das Front-End übergeben werden, eine einmalige Abfrage, und das Front-End kann sie stapelweise anzeigen. Die Voraussetzung dieser Lösung ist, dass die Datenmenge nicht zu groß ist, da die Länge von SQL selbst begrenzt ist.

Damit ist dieser Artikel darüber, warum MySQL die Verwendung von Unterabfragen und Verknüpfungen nicht empfiehlt, abgeschlossen. Weitere relevante MySQL-Unterabfragen und -Verknüpfungen finden Sie in früheren Artikeln auf 123WORDPRESS.COM oder in den folgenden verwandten Artikeln. Ich hoffe, dass jeder 123WORDPRESS.COM in Zukunft unterstützen wird!