Ist MySQL-Abfragen mit mehreren Tabellen effizienter oder mehrere Abfragen mit einzelnen Tabellen?
Wenn die Datenmenge nicht groß genug ist, ist die Verwendung von Join kein Problem, sie erfolgt jedoch normalerweise auf der Serviceebene.
Erstens: Eigenständige Datenbank-Rechenressourcen sind sehr teuer und die Datenbank muss bereitgestellt werden Gleichzeitiges Schreiben und Lesen erfordert eine höhere CPU-Auslastung. Um den Durchsatz der Datenbank zu erhöhen, kümmert sich das Unternehmen nicht um die Verzögerungslücke von Hunderten von Mikrosekunden bis hin zu Millisekunden Schließlich können Computerressourcen leicht horizontal erweitert werden, und die Datenbank ist schwierig zu verwalten. Daher werden die meisten Unternehmen reine Computeroperationen auf der Serviceebene platzieren und die Datenbank als KV-System mit Transaktionsfunktionen verwenden Idee, die das Geschäft und die leichte Datenbank in den Vordergrund stellt. Zweitens: Viele komplexe Unternehmen verwenden aus historischen Entwicklungsgründen möglicherweise nicht nur eine Ebene von Middleware , das Unternehmen abstrahiert eine Die Serviceschicht reduziert die Kopplung zur Datenbank.
Drittens: Für einige große Unternehmen müssen aufgrund des großen Datenumfangs Unterdatenbanken und Untertabellen verwendet werden. Für die Verwendung von Unterdatenbanken und Untertabellen unterliegt die Verwendung von Join ebenfalls vielen Einschränkungen , es sei denn, das Unternehmen kann die Anforderungen anhand des Sharding-Schlüssels klar definieren. Die beiden verbundenen Tabellen befinden sich in derselben physischen Datenbank. Middleware unterstützt im Allgemeinen datenbankübergreifende Verknüpfungen nicht gut.
Um ein sehr häufiges Geschäftsbeispiel zu nennen: In einer Unterdatenbank und einer Untertabelle müssen zwei Tabellen synchron aktualisiert werden. Um die Datenkonsistenz sicherzustellen, besteht ein Ansatz darin Eine verteilte Transaktionszwischenstufe Die Software fügt zwei Aktualisierungsvorgänge in eine Transaktion ein. Für solche Vorgänge ist jedoch im Allgemeinen eine sehr langsame Leistung erforderlich. Einige Unternehmen können jedoch kurzfristige Dateninkonsistenzen tolerieren. Lassen Sie sie separat aktualisieren, es tritt jedoch das Problem auf, dass das Schreiben von Daten fehlschlägt. Starten Sie dann eine geplante Aufgabe, scannen Sie die A-Tabelle nach fehlerhaften Zeilen, prüfen Sie, ob die B-Tabelle ebenfalls erfolgreich geschrieben wurde, und koppeln Sie dann die beiden Zuordnungen. Eine Datensatzkorrektur kann derzeit nicht mit Join erreicht werden. Die Daten können nur auf die Serviceschicht übertragen und von der Anwendung selbst zusammengeführt werden. . .
Tatsächlich hat die Rekonstruktion der Abfrage durch Zerlegen der relationalen Abfrage die folgenden Vorteile:Machen Sie das Caching effizienter.
Viele Anwendungen können die Ergebnisobjekte, die Einzeltabellenabfragen entsprechen, problemlos zwischenspeichern. Wenn sich eine Tabelle in der Zuordnung ändert, kann der Abfragecache außerdem nicht verwendet werden. Wenn sich eine Tabelle selten ändert, können Abfragen basierend auf den Ergebnissen der Tabelle wiederholt werden.
Nach der Aufschlüsselung der Abfrage kann die Ausführung einer einzelnen Abfrage den Sperrenkonflikt reduzieren.
Durch die Verknüpfung auf der Anwendungsebene lässt sich die Datenbank einfacher aufteilen und eine hohe Leistung und Skalierbarkeit erzielen.
Die Effizienz der Abfrage selbst kann ebenfalls verbessert werden
Die Abfrage redundanter Datensätze kann reduziert werden.
Weiterhin ist dies gleichbedeutend mit der Implementierung einer Hash-Assoziation in der Anwendung, anstatt die verschachtelte Ring-Assoziation von MySQL zu verwenden. In einigen Szenarien ist die Hash-Assoziation viel effizienter.
Ausführungsreihenfolge von Abfrageanweisungen join, on, where
1. Vollständige Ausführungsreihenfolge typischer SELECT-Anweisungen
2) Verwenden Sie on zur Ausführung Datenfilterung für Join-Verbindungen
3) Die Where-Klausel filtert Datensatzzeilen basierend auf angegebenen Bedingungen.
4) Die Group-by-Klausel unterteilt Daten in mehrere Gruppen.
5) Cube, Rollup.
6) Die Aggregationsfunktion wird zur Berechnung verwendet ;
7) Verwenden Sie die Have-Klausel, um die Gruppierung zu filtern.
9) Berechnen Sie ausgewählte Felder.
12) Wählen Sie TOPN-Daten aus
2. aus
Wenn die Zuordnung von TabelleA, TabelleB verwendet wird, werden diese beiden Tabellen zuerst für das kartesische Produkt organisiert und dann werden die folgenden Operationen durchgeführt, z. B. wo und gruppieren nach.
3. on
Wenn Sie Left Join, Inner Join oder Outer Full Join verwenden, verwenden Sie On, um Bedingungen zu filtern und dann zu verbinden.
Verwenden Sie zuerst „Join“, um eine Verbindung herzustellen, und verwenden Sie dann „On“, um zu filtern, wodurch ein kartesisches Produkt entsteht. Es gibt keinen Unterschied zwischen einem solchen Left-Join und einem Direct-Join. Sie müssen also zunächst nach Bedingungen filtern und dann beitreten.
SELECT DISTINCT a.domain , b.domain FROM mal_nxdomains_raw a LEFT JOIN mal_nxdomains_detail b ON a.domain = b.domain AND b.date = ‘20160403' WHERE a.date = ‘20160403'
SELECT DISTINCT a.domain , b.domain FROM mal_nxdomains_raw a LEFT JOIN mal_nxdomains_detail b ON a.domain = b.domain #and b.date = ‘20160403' WHERE a.date = ‘20160403' AND b.date = ‘20160403'
1、使用位置
on 条件位置在join后面
where 条件在join 与on完成的后面
2、使用对象
on 的使用对象是被关联表
where的使用对象可以是主表,也可以是关联表
3、选择与使用
主表条件筛选:只能在where后面使用。
被关联表,如果是想缩小join范围,可以放置到on后面。如果是关联后再查询,可以放置到where 后面。
如果left join 中,where条件有对被关联表的 关联字段的 非空查询,与使用inner join的效果后,在进行where 筛选的效果是一样的。不能起到left join的作用。
在表A和表B的联接中,从A表中选出一条记录,并将其传递到B表进行扫描和匹配。所以A的行数决定查询次数,B表的行数决定扫描范围。需要运行100次从A表中取出一条数据,然后进行200次比对,将结果存储到B表中。
相对来说从A表取数据消耗的资源比较多。所以尽量tableA选择比较小的表。同时缩小B表的查询范围。
但是实际应用中,因为二者返回的数据结果不同,使用的索引也不同,导致条件放置在on 和 where 效率是不一定谁更好。要根据需求来确定。
Das obige ist der detaillierte Inhalt vonWas sind die Join-Abfrage- und Mehrfachabfragemethoden von MySQL?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!