AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Datenbanken Geschwindigkeit diverser SQL-Statments

Geschwindigkeit diverser SQL-Statments

Ein Thema von khh · begonnen am 17. Jan 2009 · letzter Beitrag vom 18. Jan 2009
Antwort Antwort
Seite 1 von 2  1 2   
khh

Registriert seit: 18. Apr 2008
Ort: Südbaden
1.903 Beiträge
 
FreePascal / Lazarus
 
#1

Geschwindigkeit diverser SQL-Statments

  Alt 17. Jan 2009, 17:08
Datenbank: firebird • Version: 2.1 • Zugriff über: zeos
hallo zusammen,
man liest ja immer wieder mal, dass sql-statments ala "select * from..." vermieden werden sollen.
Gibt es einen erkennbaren bzw. messbaren Unterschied in der Zugriffsgeschwindigkeit zwischen einem statement das alle Datenfelder holt, oder einem welches nur 2 felder abfragt?

also beipielsweise zwischen "select * from kunden" oder
*select id, name from kunden"
wobei die Kundentabelle ,sagen wir mal insgesamt 20 felder hat.


Danke Gruss KH
Karl-Heinz
  Mit Zitat antworten Zitat
mkinzler
(Moderator)

Registriert seit: 9. Dez 2005
Ort: Heilbronn
39.851 Beiträge
 
Delphi 11 Alexandria
 
#2

Re: Geschwindigkeit diverser SQL-Statments

  Alt 17. Jan 2009, 17:28
Es kommt natürlich auch darauf an, was für Felder es sind. Bei 20 großen Varchar-Feldern wirst du es mehr merken als bei Numeric.
Noch wichtiger ist es aber die Anzahl der zurückgegebenen Datensätze zu beschränken.
Markus Kinzler
  Mit Zitat antworten Zitat
Benutzerbild von DeddyH
DeddyH

Registriert seit: 17. Sep 2006
Ort: Barchfeld
27.534 Beiträge
 
Delphi 11 Alexandria
 
#3

Re: Geschwindigkeit diverser SQL-Statments

  Alt 17. Jan 2009, 17:30
Bei einem langsamen Netzwerk und nicht benötigten BLOB-Feldern dürfte der Unterschied auch subjektiv zu spüren sein, denke ich mal.
Detlef
"Ich habe Angst vor dem Tag, an dem die Technologie unsere menschlichen Interaktionen übertrumpft. Die Welt wird eine Generation von Idioten bekommen." (Albert Einstein)
Dieser Tag ist längst gekommen
  Mit Zitat antworten Zitat
Benutzerbild von richard_boderich
richard_boderich

Registriert seit: 21. Jun 2004
Ort: Berlin
1.067 Beiträge
 
Delphi 7 Architect
 
#4

Re: Geschwindigkeit diverser SQL-Statments

  Alt 17. Jan 2009, 18:30
Zitat von mkinzler:
Noch wichtiger ist es aber die Anzahl der zurückgegebenen Datensätze zu beschränken.
Und wie kann ich dies bsp. Realisieren?
mfG Richard

Cimmams schrieb "das einzige was an ArmA gut ist, ist die Grafik bis 100m und der Rest ist so unreal wie unsere Demokratie."
  Mit Zitat antworten Zitat
Dax
(Gast)

n/a Beiträge
 
#5

Re: Geschwindigkeit diverser SQL-Statments

  Alt 17. Jan 2009, 18:33
LIMIT x, y; TOP x; ...
  Mit Zitat antworten Zitat
omata

Registriert seit: 26. Aug 2004
Ort: Nebel auf Amrum
3.154 Beiträge
 
Delphi 7 Enterprise
 
#6

Re: Geschwindigkeit diverser SQL-Statments

  Alt 17. Jan 2009, 18:39
Code:
Firebird:     FIRST
Firebird >= 2: ROWS n TO m
MySQL:        LIMIT
MSSQL:        TOP
Oracle:       ROWNUM
PostgreSQL:   LIMIT + OFFSET
Firebird: klick
  Mit Zitat antworten Zitat
Jürgen Thomas

Registriert seit: 13. Jul 2006
Ort: Berlin
750 Beiträge
 
#7

Re: Geschwindigkeit diverser SQL-Statments

  Alt 17. Jan 2009, 18:54
... und natürlich immer mit einer sinnvollen WHERE-Klausel. Jürgen
#D mit C# für NET, dazu Firebird
früher: Delphi 5 Pro, Delphi 2005 Pro mit C# (also NET 1.1)
Bitte nicht sauer sein, wenn ich mich bei Delphi-Schreibweisen verhaue; ich bin inzwischen an C# gewöhnt.
  Mit Zitat antworten Zitat
omata

Registriert seit: 26. Aug 2004
Ort: Nebel auf Amrum
3.154 Beiträge
 
Delphi 7 Enterprise
 
#8

Re: Geschwindigkeit diverser SQL-Statments

  Alt 17. Jan 2009, 19:18
Zitat von Jürgen Thomas:
... und natürlich immer mit einer sinnvollen WHERE-Klausel.
... und/oder HAVING-Klausel
  Mit Zitat antworten Zitat
NormanNG

Registriert seit: 1. Feb 2006
294 Beiträge
 
Delphi 2007 Professional
 
#9

Re: Geschwindigkeit diverser SQL-Statments

  Alt 17. Jan 2009, 20:38
Hi

Zitat:
... und natürlich immer mit einer sinnvollen WHERE-Klausel.
... und/oder HAVING-Klausel
zusammengefasst kann man sagen:
die zurückgegebene Datenmenge bezüglich Spalten und Zeilen nur so groß wie nötig
und so klein wie möglich halten.
Gruß
Norman
  Mit Zitat antworten Zitat
Benutzerbild von alcaeus
alcaeus

Registriert seit: 11. Aug 2003
Ort: München
6.537 Beiträge
 
#10

Re: Geschwindigkeit diverser SQL-Statments

  Alt 18. Jan 2009, 10:16
Moin,

was auch noch einen grossen Unterschied macht ist die Reihenfolge der WHERE-Bedingungen und/oder JOINs. Der Query-Optimizer kommt da nicht immer ganz gut mit (hab ich z.B. bei MySQL gemerkt).

Nehmen wir dieses Query:
SELECT * FROM a, b WHERE a.id = b.id AND a.user = 5 Das ist nicht dasselbe wie das hier:
SELECT * FROM a, b WHERE a.user = 5 AND a.id = b.id Der Unterschied liegt darin, dass beim ersten Query zuerst ein Kreuzprodukt erstellt wird. Vor allem in m:n-Beziehungen koennen da viele Datensaetze zusammenkommen. Anschliessend wird die Datenmenge eingeschraenkt. Beim zweiten Query wird zuerst eingeschraenkt und anschliessend erst das Kreuzprodukt erstellt, das heisst die aufkommende Datenmenge wird kleiner sein. Wenn nun auch b eine user-ID haette (die natuerlich dieselbe ist wie bei a, kann ja sein) dann koennte man auch das noch machen:
SELECT * FROM a, b WHERE a.user = 5 AND b.user = 5 AND a.id = b.id So werden in beiden Tabellen erstmal die Datensaetze eingeschraenkt, bevor das Kreuzprodukt daherkommt.

Was den * betrifft: Wenn du alle Felder brauchst, dann schreib auch den * rein. Der Query-Optimizer muss eh jedes Feld durch seinen vollen Namen ersetzen (<datenbank>.<tabelle>.<feld>), da macht das mitm * auch keinen Unterschied. Die meisten Server vertragen den * mittlerweile auch sehr gut. V.a. bei Count-Statements (SELECT COUNT(*) FROM xyz) gehts mitm * immer noch am schnellsten.
Was teilweise einen grossen Unterschied macht ist die Verwendung von DISTINCT oder GROUP BY. Da kann man teilweise auch einiges rausholen.

Im Grunde genommen kann man keine allgemeingueltigen Regeln aufstellen. Manchmal muss man einfach damit leben, dass ein Query langsam laeuft (z.B. wenn ich Daten aus drei Tabellen hole, in denen jeweils mehr als 1 Million Datensaetze drin sind). Die Optimierung geschieht dabei meistens auf Query-Basis, d.h. guck dir das Query mit EXPLAIN an, versuch rauszufinden was du dran aendern kannst, usw. Teilweise reicht es ja auch, das Schema geringfuegig zu aendern. Um kurz ein Beispiel zu nennen:
Wir haben eine Seite in der Artikel stehn. Diese Artikel stehen in verschiedenen Kategorien. Auf der Uebersichtsseite will ich natuerlich die Kategorien zusammen mit Infos zum letzten Artikel anzeigen. Wie wuerde man das machen, wenns streng nach Protokoll geht (MySQL):
SELECT * FROM categories ORDER BY category_order Und zum Rausholen der Artikel in der Anzeigeschleife:
SELECT * FROM articles WHERE category_id = <id> ORDER BY article_time DESC LIMIT 1 Das ist schon nicht schlecht. Wenn ich nun aber die ID des letzten Beitrags der Kategorie im Datensatz der Kategorie hinterlege, hab ich zwar eine Redundanz in der DB und Normalform-Fetischisten wuerden gleich wieder Zeter und Mordio bruellen, aber dafuer geht sowas:
SELECT c.*, a.id, a.time FROM categories c LEFT JOIN articles a ON c.last_article = a.id ORDER BY category_order Und schon wars das. Dann noch ein Index auf c.last_article und c.category_order, a.id als Primary und der Datenbankserver wird dir zum Dank ein Kuesschen mit jedem Query-Ergebnis mitschicken *g*

Mein Tipp: teste verschiedene Varianten eines Queries rum und guck dir an, was der Optimizer daraus macht. In MySQL kannst du das sehn in dem du zuerst das Query mit EXPLAIN ausfuehrst:
EXPLAIN EXTENDED SELECT ..... und dir anschliessend die Warnungen anzeigen laesst:
SHOW WARNINGS; Dann zeigt dir MySQL das Query an, wie es dann tatsaechlich ausgefuehrt wurde. Da kann man auch schon Engpaesse sehn. In den meisten Faellen reicht es jedoch, folgendes zu machen:
EXPLAIN SELECT ..... Das gibt dir Informationen ueber das Query und die Abarbeitungsreihenfolge. Da lassen sich die Engpaesse mit etwas Erfahrung auch gut sehen

Greetz
alcaeus
Andreas B.
Die Mutter der Dummen ist immer schwanger.
Ein Portal für Informatik-Studenten: www.infler.de
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 1 von 2  1 2   

Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 14:07 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz