mySQL: Ist die Anzahl der Spalten immer relevant?

klaraSand

Hallo,

da mir in diesem Forum immer geholfen wurde, bin ich auch diesmal wieder mit einer eher komischen Frage hier. Für die meisten sicher einfach und Basics aber für mich mal wieder ein Rätsel ...

Wir gehen mal davon aus ich habe eine Abfrage in etwa wie:

SELECT id,name,status FROM table ...

Macht es bei dieser Abfrage einen Unterschied ob meine Tabelle aus den 3 Spalten besteht oder mal übertrieben gesagt 100 Spalten.

Das ist für mich von Bedeutung da ich für die Ausgabe an sich immer nur recht wenige Spalten abfragen muss. Aber für die Sortierung oder auch eine Auswertung im Admin.Panel doch noch etliche Spalten brauche. Also ist es ratsam diesbezüglich sparsam mit Spalten umzugehen oder habe ich da freie hat ohne Performanceverlust?

RK423

Generell wird die Performance bei MySQL ja erst ab einer bestimmten Größe kritisch. Und wenn Sie kritisch ist, ist natürlich jede überflüssige Spalte zuviel. In meinem Erfahrungsbereich spielen 10 oder 20 zusätzliche Spalten eher keine Rolle.
VG

Melegrian

Ich würde meinen, es kommt darauf an, wie viele Datensätze Du abrufst. Für einen einzelne Artikelseite oder so, da nicht, doch um zum Beispiel eine Statistik aus 30.000 Datensätze zu generieren, da würde ich alles Unnötige weglassen.

Du könntest unterhalb der Abfrage für Tests memory_get_usage verwenden, um Dir den Unterschied anzeigen zu lassen.

hanneswobus

klara.
es kommt auf den server / webspace u. auf die groesse der db (tabellen, eintraege) etc. an u. generell empfinde ich ressourcensparende entwicklungen als "ideal".
lg

/Affilitiv/

hanneswobus hat geschrieben: generell empfinde ich ressourcensparende entwicklungen als "ideal".
lg

jo; find ich auch; nur mach ich dann doch aus bequemlichkeit immer "SELECT * FROM"

Die Tage hatte ich mal nur wirklich "1" Spalte gebraucht und die dann extra angegeben . ....
.... später wollte ich dann doch mehr; unten ausgeben; schreib die Ausge dazu ..... wunder mich warum nichts kommt ....**grübel**

Wenn man z.B. ein Blog abfragt; um einen RSS zu schreiben
dann gibt man nur $line['teas'] aus und nicht $line['beitrag']
da kann viel "Datenverkehr" eingespart werden .....
.... ein Kellner bringt ja auch nur das Besteck zum Tisch das gebraucht wird
eine Pizza braucht keinen Löffel(Suppe)Löffel(puding)Gabel(Kuchen)Gabel(ähm, Gabel bringt er)

zu ner Flasche Wasser gibts ein Wasserglass; kein Bierglas+Weinglass+WiskeyGlas..........

klaraSand

Also in meinem Beispiel ist es so:
Tabelle mit 70 Spalten ...

Auf der Übersichtsseite werden "nur" 20 Spalten benötigt und 5 Datensätze...
Auf der Detail.Seite werden aber alle 70 Spalten benötigt und 1 Datensatz ...

Einträge werden es wenn alles fertig ist so um die 200.000 sein ...

Also mit den "Kennzahlen" und einem kleinen Server kann da alles so bleiben?

RK423

Hört sich jetzt nicht soo schlimm an...

klaraSand

RK423 hat geschrieben:Hört sich jetzt nicht soo schlimm an...

Dann treiben wir es mal auf die Spitze:
(auch wenn ich diese Zahlen sicher nicht erreiche)

Tabelle mit 150 Spalten ...

Auf der Übersichtsseite werden "nur" 50 Spalten benötigt und 5 Datensätze...
Auf der Detail.Seite werden aber alle 150 Spalten benötigt und 1 Datensatz ...

Einträge werden es wenn alles fertig ist so um die 750.000 sein ...

Weil wenn das eher als "Kleinkram" läuft muss ich mir gar keine Gedanken machen ...

afb

Um eine wirklich fundierte Antwort geben zu können, müsste man mehr Informationen über die Tabellenstruktur, die Abfragen, die Speichervorgängen etc. haben.
Grundsätzlich wirken sich weniger Spalten natürlich positiv auf die Geschwindigkeit aus. Ob viele Spalten nun ungünstig sind oder nicht, dafür müsste man wissen, um was für Spalten es sich handelt (Text, Zahl, Datum,...) und wieviele Daten dort gespeichert werden. Und ob bei jedem Datensatz immer (fast) alle Spalten gefüllt sind oder bei vielen Datensätze auch viele Spalten leer bleiben.
Pauschal würde ich sagen: Wenn jemand in eine einzelne Tabelle 150 Spalten packt, dann hätte ich erstmal die Vermutung, dass die Tabellen-/Datenbankstuktur schlecht gewählt ist. Selbst 70 Spalten halte ich schon für viel. Aber das ist eben nur eine pauschale Aussage. Um sagen zu können, ob man es besser anders machen sollte, müsste man die konkreten Anforderungen kennen.

Bezogen auf die Geschwindigkeit der Abfrage von Daten sind m.E. aber passende (und die richtigen!) Indizes viel wichtiger. Das gilt insbesondere, wenn aus vielen Datensätzen mit einer Abfrage nur wenige Datensätze ermittelt werden sollen.

HTH
Alex

/Affilitiv/

afb hat geschrieben:Selbst 70 Spalten halte ich schon für viel.

Wieviele HTMLdinger gibt es die man zählen kann?
H1h2h3h4h5h6
b br hr ...... img a style font center ....

Code: Alles auswählen

CREATE TABLE `7eoWEBSchnorrer` &#40;
`id` int&#40;11&#41; NOT NULL AUTO_INCREMENT,
`ts` int&#40;11&#41; NOT NULL DEFAULT '0',
`ts2` int&#40;11&#41; NOT NULL DEFAULT '0',
`job` int&#40;11&#41; NOT NULL DEFAULT '0',
`flags` int&#40;11&#41; NOT NULL DEFAULT '0',
`deep` int&#40;8&#41; NOT NULL DEFAULT '0',
`len` int&#40;8&#41; DEFAULT NULL,
`sub` int&#40;11&#41; NOT NULL DEFAULT '0',
`TLD` varchar&#40;8&#41; COLLATE latin1_german2_ci DEFAULT NULL,
`URL` varchar&#40;255&#41; COLLATE latin1_german2_ci DEFAULT NULL,
`FURL` varchar&#40;255&#41; COLLATE latin1_german2_ci DEFAULT NULL,
`user` varchar&#40;42&#41; COLLATE latin1_german2_ci DEFAULT NULL,
`info` varchar&#40;255&#41; COLLATE latin1_german2_ci DEFAULT NULL,
`desc` varchar&#40;255&#41; COLLATE latin1_german2_ci DEFAULT NULL,
`keys` varchar&#40;255&#41; COLLATE latin1_german2_ci DEFAULT NULL,
`WWWdom` varchar&#40;255&#41; COLLATE latin1_german2_ci DEFAULT NULL,
`WWWurl` varchar&#40;255&#41; COLLATE latin1_german2_ci DEFAULT NULL,
`HTTPpro` varchar&#40;42&#41; COLLATE latin1_german2_ci DEFAULT NULL,
`HTTPstat` varchar&#40;42&#41; COLLATE latin1_german2_ci DEFAULT NULL,
`HTTPtext` text COLLATE latin1_german2_ci,
`HTMLtext` text COLLATE latin1_german2_ci,
PRIMARY KEY &#40;`id`&#41;,
KEY `ts` &#40;`ts`&#41;,
KEY `job` &#40;`job`&#41;,
KEY `sub` &#40;`sub`&#41;,
KEY `TLD` &#40;`TLD`&#41;,
KEY `FURL` &#40;`FURL`&#41;,
KEY `WWWdom` &#40;`WWWdom`&#41;
&#41;

`HTTPtext` = HTTP-Header
`HTMLtext` = die Seite; das soll später noch zerlegt werden und .... naja, alles was so drin sein könnte zählen ..... siehe oben, wieviele h1 wieviele h2 usw

A; da könnte ich auf vielel Spalten kommen
B; ich mach eine 2. Tabelle

Code: Alles auswählen

CREATE TABLE `7eoWEBSchnorrerElementcounter` &#40;
`id` int&#40;11&#41; NOT NULL  DEFAULT '0',
`c` int&#40;8&#41; DEFAULT NULL,
`TAG` varchar&#40;42&#41; COLLATE latin1_german2_ci DEFAULT NULL,

Also; 1. Table findet "Die Site die angezeigt werden soll"
und 2. Tabelle liefert dann die "Elemente"

B; ist glaub besser

Nokes

klaraSand hat geschrieben:Hallo,

da mir in diesem Forum immer geholfen wurde, bin ich auch diesmal wieder mit einer eher komischen Frage hier. Für die meisten sicher einfach und Basics aber für mich mal wieder ein Rätsel ...

Wir gehen mal davon aus ich habe eine Abfrage in etwa wie:

SELECT id,name,status FROM table ...

Macht es bei dieser Abfrage einen Unterschied ob meine Tabelle aus den 3 Spalten besteht oder mal übertrieben gesagt 100 Spalten.

Das ist für mich von Bedeutung da ich für die Ausgabe an sich immer nur recht wenige Spalten abfragen muss. Aber für die Sortierung oder auch eine Auswertung im Admin.Panel doch noch etliche Spalten brauche. Also ist es ratsam diesbezüglich sparsam mit Spalten umzugehen oder habe ich da freie hat ohne Performanceverlust?

Das habe ich schon mal genau so getestet. Mein Ergebnis lautet wie folgt:

Hat die MySQL Tabelle unter 60 Spalte, dann lohnt es sich die genauen Spalte im SELECT direkt abzufragen.
Sobald die MySQL Tabelle über 60 Spalten hat, arbeitet die Abfrage mit einem Sternchen (SELECT * FROM) schneller.

Getestet habe ich das unter Linux Debian, Format: InnoDB.

Melegrian

Nokes hat geschrieben:Hat die MySQL Tabelle unter 60 Spalte, dann lohnt es sich die genauen Spalte im SELECT direkt abzufragen.
Sobald die MySQL Tabelle über 60 Spalten hat, arbeitet die Abfrage mit einem Sternchen (SELECT * FROM) schneller.

Es kommt doch aber auch auf die Anzahl an Datensätzen an und auf die enthaltenen Daten. Ich könnte jetzt ein Beispiel bringen, doch auch ohne Beispiel, das ging doch teilweise soweit, dass das Memory Limit gesprengt wurde. Und bei letzteren bleibst Du, denke ich, eher im grünen Bereich, wenn nur die Daten aus den benötigten Spalten abgerufen werden.

Hatte nur einmal einen Test mit einer CSV gemacht, da war etwa beim Einlesen von etwa 200.000 Datensätze das Ende der Fahnenstange erreicht, einzeln durchgehen war hingegen kein Problem. Und ja, abgerufene Daten, sind abgerufene Daten, würde ich meinen, auch wenn es sich nur um eine CSV und nicht um MySQL handelte, so müssen doch beide in einem Objekt zwischengespeichert werden.

Hier hatte ich mal einen anderen Test gemacht, welche Grenzwerte ein System PHP zubilligt (Out of memory) und was es dann mit den Einstellungen in der php.ini zu tun hat (Allowed memory size of), also was das System PHP zubilligt und was PHP einem Script zubilligt und ausreizen würde ich es halt nur im Test:

https://forum.wpde.org/installation/128 ... ory-2.html

Und dass Du hier mit Systemen wie WP schnell in Bereiche vorstoßen kannst, wo ein Limit erreicht wird, ist bekannt. Somit darf man nicht nur die Laufzeit sehen, sondern sollte beide Werte, also die Laufzeit wie das Memory Limit so gering wie möglich halten.