out of memory

Hallo,
jetzt bin ich erst mal ganz schön fertig. Ich habe eine Anwendung
geschrieben in php mit mysql. Bis jetzt nutzte ich mysql 4.0.21. Jetzt hab
ich das Update durchgeführt auf mysql 5.xxxx. Nun kommt bei meiner Abfrage
plötzlich die Fehlermeldung "#1037 - Out of memory; restart server and try
again (needed 65528 bytes) ".
Was soll das blos? Bis jetzt ging es doch auch. Wieso soll ich auf einmal
zu wenig Speicher haben. Das ist doch Blödsinn. Es geht hier um 600
Datensätze. Das ist doch nicht viel. Nun hab ich im Manual gelesen, man
kann mysql mit der Option --quick aufrufen. Alles gut und schön. Aber wie
mache ich das unter php? Ich nutze mysql_query($mysql). $mysql enthält die
Select Abfrage. Wie soll ich da mit --quick arbeiten?
Hat jemand eine Idee wie ich diesen memory Fehler in den Griff kriege?

mfg

Mathias

Re: out of memory

Mathias Fiedler schrieb:

[Out of memory nach Update]

> Was soll das blos? Bis jetzt ging es doch auch. Wieso soll ich auf einmal
> zu wenig Speicher haben. Das ist doch Blödsinn. Es geht hier um 600
> Datensätze. Das ist doch nicht viel.

Viel ist relativ.

> Hat jemand eine Idee wie ich diesen memory Fehler in den Griff kriege?

Finde erstmal heraus, was den ganzen Speicher frisst.

Re: out of memory

Am Fri, 29 Sep 2006 18:49:28 +0200 schrieb Thomas 'DaFox' Hamacher:

> Mathias Fiedler schrieb:
>
> [Out of memory nach Update]
>
>> Was soll das blos? Bis jetzt ging es doch auch. Wieso soll ich auf einmal
>> zu wenig Speicher haben. Das ist doch Blödsinn. Es geht hier um 600
>> Datensätze. Das ist doch nicht viel.
>
> Viel ist relativ.
>
>> Hat jemand eine Idee wie ich diesen memory Fehler in den Griff kriege?
>
> Finde erstmal heraus, was den ganzen Speicher frisst.

Ja, was wohl. Mysql natürlich. Wenn mit mysql 4.0 alles ok. und mit mysql
5.0 der Speicherfehler, was soll ich da noch groß suchen? Weiter wurde ja
nichts geändert !

mfg

Mathias

P.S. Es werden aj nur 600 Datensätze abgefragt, Selectiert werden müssen so
ca. 100. Wenn ich die Abfrage in der WHERE Klauses einschränke,
funktioniert es ja.

Re: out of memory

Übrigens ist das der mysql String:

SELECT bi.ID_basic, la.land, i.cover_bild1_thumb, bi.releaseDate,
bi.dateOriginal, bi.name, re.ref1, re.ref2,re.ref3, re.ref4, bi.charge,
bi.name_alternative, bi.show_alternative, inc.inches, bi.prefix,
bi.alternative_date, bi.no_detail FROM basic_informations AS bi INNER JOIN
images AS i ON bi.ID_images = i.ID_image INNER JOIN land AS la ON
bi.ID_land = la.ID_land INNER JOIN reference_nb AS re ON bi.ID_reference =
re.ID_reference INNER JOIN inches As inc ON bi.ID_inch = inc.ID_inch WHERE
(bi.id_hg = 1 AND bi.presskit = 0) ORDER BY bi.dateOriginal, bi.charge,
bi.name, re.ref1, re.ref2, re.ref3, re.ref4, inc.inches, la.land

So viel Speicher kann der ja nun auch nicht verbrauchen. Die ganze Tabelle
hat ja nicht mal 200Kb.

Mathias

Re: out of memory

Hi Mathias

Mathias Fiedler wrote:
> Übrigens ist das der mysql String:
> SELECT bi.ID_basic, la.land, i.cover_bild1_thumb, bi.releaseDate,
> bi.dateOriginal, bi.name, re.ref1, re.ref2,re.ref3, re.ref4, bi.charge,
> bi.name_alternative, bi.show_alternative, inc.inches, bi.prefix,
> bi.alternative_date, bi.no_detail FROM basic_informations AS bi INNER JOIN
> images AS i ON bi.ID_images = i.ID_image INNER JOIN land AS la ON
> bi.ID_land = la.ID_land INNER JOIN reference_nb AS re ON bi.ID_reference =
> re.ID_reference INNER JOIN inches As inc ON bi.ID_inch = inc.ID_inch WHERE
> (bi.id_hg = 1 AND bi.presskit = 0) ORDER BY bi.dateOriginal, bi.charge,
> bi.name, re.ref1, re.ref2, re.ref3, re.ref4, inc.inches, la.land
> So viel Speicher kann der ja nun auch nicht verbrauchen. Die ganze Tabelle
> hat ja nicht mal 200Kb.

Setz mal ein explain davor und schau, was rauskommt.

HTH, Johannes

Re: out of memory

Mathias Fiedler wrote:

Dein Name kam mir gleich so bekannt vor. Und tatsächlich, Google
bescheinigt dir eine nicht vernachlässigbare Historie an - sagen
wir mal unkooperativen - Postings in dieser Gruppe. Deine Beiträge
in diesem Thread lassen irgendwie auch keine Besserung erkennen.

> Übrigens ist das der mysql String:
>
> SELECT bi.ID_basic, la.land, i.cover_bild1_thumb, bi.releaseDate,
> bi.dateOriginal, bi.name, re.ref1, re.ref2,re.ref3, re.ref4, bi.charge,
> bi.name_alternative, bi.show_alternative, inc.inches, bi.prefix,
> bi.alternative_date, bi.no_detail FROM basic_informations AS bi INNER JOIN
> images AS i ON bi.ID_images = i.ID_image INNER JOIN land AS la ON
> bi.ID_land = la.ID_land INNER JOIN reference_nb AS re ON bi.ID_reference =
> re.ID_reference INNER JOIN inches As inc ON bi.ID_inch = inc.ID_inch WHERE
> (bi.id_hg = 1 AND bi.presskit = 0) ORDER BY bi.dateOriginal, bi.charge,
> bi.name, re.ref1, re.ref2, re.ref3, re.ref4, inc.inches, la.land

Das ist ein JOIN über 5 Tabellen. Ohne passende Indexe (ich erinnere an
den Thread "zwei Tabellen") kann da ein durchaus fettes Zwischenergebnis
entstehen, das in Folge den Server an Out-of-memory sterben läßt.

> So viel Speicher kann der ja nun auch nicht verbrauchen.

Weil nicht sein kann, was nicht sein darf? Nach all den Hinweisen, die
du in der Vergangenheit hier schon bekommen hast, hätte ich angenommen,
daß du zumindest mal EXPLAIN selber bemühst und notwendige Indexe
nachrüstest. Habe ich dich wohl überschätzt.

> Die ganze Tabelle hat ja nicht mal 200Kb.

Ein durchaus merkwürdiges Statement bei einem JOIN über 5 verschiedene
Tabellen.


XL

Re: out of memory

Am Fri, 29 Sep 2006 23:24:09 +0200 schrieb Axel Schwenke:

> Mathias Fiedler wrote:
>
> Dein Name kam mir gleich so bekannt vor. Und tatsächlich, Google
> bescheinigt dir eine nicht vernachlässigbare Historie an - sagen
> wir mal unkooperativen - Postings in dieser Gruppe. Deine Beiträge
> in diesem Thread lassen irgendwie auch keine Besserung erkennen.
>
>> Übrigens ist das der mysql String:
>>
>> SELECT bi.ID_basic, la.land, i.cover_bild1_thumb, bi.releaseDate,
>> bi.dateOriginal, bi.name, re.ref1, re.ref2,re.ref3, re.ref4, bi.charge,
>> bi.name_alternative, bi.show_alternative, inc.inches, bi.prefix,
>> bi.alternative_date, bi.no_detail FROM basic_informations AS bi INNER JOIN
>> images AS i ON bi.ID_images = i.ID_image INNER JOIN land AS la ON
>> bi.ID_land = la.ID_land INNER JOIN reference_nb AS re ON bi.ID_reference =
>> re.ID_reference INNER JOIN inches As inc ON bi.ID_inch = inc.ID_inch WHERE
>> (bi.id_hg = 1 AND bi.presskit = 0) ORDER BY bi.dateOriginal, bi.charge,
>> bi.name, re.ref1, re.ref2, re.ref3, re.ref4, inc.inches, la.land
>
> Das ist ein JOIN über 5 Tabellen. Ohne passende Indexe (ich erinnere an
> den Thread "zwei Tabellen") kann da ein durchaus fettes Zwischenergebnis
> entstehen, das in Folge den Server an Out-of-memory sterben läßt.
>
>> So viel Speicher kann der ja nun auch nicht verbrauchen.
>
> Weil nicht sein kann, was nicht sein darf? Nach all den Hinweisen, die
> du in der Vergangenheit hier schon bekommen hast, hätte ich angenommen,
> daß du zumindest mal EXPLAIN selber bemühst und notwendige Indexe
> nachrüstest. Habe ich dich wohl überschätzt.
>
>> Die ganze Tabelle hat ja nicht mal 200Kb.
>
> Ein durchaus merkwürdiges Statement bei einem JOIN über 5 verschiedene
> Tabellen.
>
Nun ja, wie ich auch damals schon gesagt habe, so groß sind die Datenmengen
nicht. Die ganze DB hat nur 700Kb. Die Daten, die hier abgefragt werden
sind etwa 200kb groß. Der Fehler sagt etwas von 65000 byte. Die Frage ist
doch wieso? Ich habe hier 1024 MB RAM und Festplatenkapazität von mehreren
100GB. Woher kommt also dieser Fehler? Kann man vieleicht bin mysql5
irgendeine Speichergröße einstellen? Unter mysql4 lief die DB-Abfrage
problemlos. Unter mysql5 nicht mehr. Selbst bei der DB aus dem Thread den
Du ansprichst, kam dieser Fehler nicht. Die Abfrage dauerte nur lange,
wurde aber ausgeführt. Diese DB war um das 100 fache Größer als die
jetzige. Das macht mich stutzig. Natürlich werde ich einen Index verwenden,
aber warum dieser Unterschied zwischen mysql4 und 5?

mfg

Mathias

Re: out of memory

Mathias Fiedler schrub am Freitag, 29. September 2006
17:48 folgendes:

> Hallo,
> jetzt bin ich erst mal ganz schön fertig. Ich habe
> eine Anwendung geschrieben in php mit mysql.
Nur mal so als Anmerkung... PHP kann den Speicherbedarf
(und die Ausführungszeit) eines Skripts begrenzen.
Der erlaubte Speicherbedarf eines Skripts per Default
64KB soweit ich weiss.

Check mal deine php.ini, bevor du den Fehler auf mysql
schiebst.

--
greetz Karlheinz Klingbeil (lunqual)
http://www.lunqual.de http://www.42pixels.de
http://www.rezeptbuch-pro.de

Re: out of memory

Am Sat, 30 Sep 2006 13:40:25 +0200 schrieb karlheinz klingbeil:

> Mathias Fiedler schrub am Freitag, 29. September 2006
> 17:48 folgendes:
>
>> Hallo,
>> jetzt bin ich erst mal ganz schön fertig. Ich habe
>> eine Anwendung geschrieben in php mit mysql.
> Nur mal so als Anmerkung... PHP kann den Speicherbedarf
> (und die Ausführungszeit) eines Skripts begrenzen.
> Der erlaubte Speicherbedarf eines Skripts per Default
> 64KB soweit ich weiss.
>
> Check mal deine php.ini, bevor du den Fehler auf mysql
> schiebst.

Der Fehler erscheint ja schon bei der Eingabe des Strings in phpMyAdmin.
Die Ausführungszeit beträgt nur Millisekunden. Wenn ich aus der Order By
Klausel nur einen bestimmten Wert (re.ref1) entferne klappt es ja. Es isnd
aber 4 Spalten von gleichen Type, nach denen sortiert werden soll. Nur bei
einer kommt die Fehlermeldung. Erst bei einem einem einzigen DS in der
betreffenden Tabelle wird die Abfrage ausgeführt. Bei zwei Datensätzen
kommt bereits der Speicherfehler. In den beiden Datensätzen steht nur bei
ref1 jeweils eine Ziffer ( 1 und 2), bei ref2, ref3 und ref4 eine 0. Das
kann doch nicht zu Speicherproblemem führen !?

mfg

Mathias

Re: out of memory

Mathias Fiedler wrote:


> Das Ergebnis von EXPLAIN ist im Anhang.

Warum, um alles in der Welt, als .doc-Datei im Anhang (was in NGs ohnehin
verpönt ist)? Warum nicht einfach als Klartext in den Mailbody?


Thomas
--
Wir nehmen Hauptkreditkarten an: Der ausdrückliche Amerikaner, entdecken,
MasterCard oder Visum. Wir Dose E-mail es in Ihrem gewählten Format.
CI-Corporation, Washington, Gleichstrom USA.
(Aus einer www-Seite eines Übersetzungsbüros)

Re: out of memory

karlheinz klingbeil schrieb:

> Nur mal so als Anmerkung... PHP kann den Speicherbedarf
> (und die Ausführungszeit) eines Skripts begrenzen.
> Der erlaubte Speicherbedarf eines Skripts per Default
> 64KB soweit ich weiss.

8 MB.

Gruß. Claus

Re: out of memory

Mathias Fiedler schrieb:

> Ich habe hier 1024 MB RAM und Festplatenkapazität von mehreren 100GB.

Dieses Argument kommt oft, ist aber vollkommen irrelevant. Welchen und
wieviel Speicher Du hast, interessiert erst an zweiter Stelle. An erster
Stelle steht die Frage, wieviel Speicher Du MySQL zur Verfügung stellst.

> Kann man vieleicht bin mysql5 irgendeine Speichergröße einstellen?

Bei MySQL konnte man schon in der Version 4 (ältere kenne ich nicht)
verschiedene Speichergrößen einstellen. Deine Frage lässt darauf
schließen, dass Du Dich darum noch nie gekümmert hast.

Schau mal ins Administratorhandbuch. Dort wird ziemlich ausführlich
erklärt, an welchen "Schrauben" man drehen kann. Diese "Schrauben"
solltest Du dann in my.cnf mal richtig "anziehen".

> Unter mysql4 lief die DB-Abfrage problemlos. Unter mysql5 nicht mehr.

Zufall? Glück? Nenne es, wie Du willst.

Gruß. Claus

Re: out of memory

Thomas Rachel schrieb:

> Mathias Fiedler wrote:
>
>> Das Ergebnis von EXPLAIN ist im Anhang.

In welchem Posting denn? Offensichtlich ist das hier nicht angekommen.
Vielleicht wegen des Anhangs? Früher kam nur der Anhang nicht an.
Möglicherweise wurde das inzwischen verschärft.

> Warum, um alles in der Welt, als .doc-Datei im Anhang

Auch noch als .doc? Damit können einige sowieso nichts anfangen.

Gruß. Claus

Re: out of memory

Mathias Fiedler schrieb:
> Hallo
>
> um das nochmal zu klären. Diese Anfrage hat nichts mit dem Thread "zwei
> Tabellen" zu tun, wo es um die Indexerstellung ging.
> In diesem Fall werden Indexe benutzt, obwohl die Datenmenge eher gering
> ist. Ebenfalls wichtig erscheint mir die Tatsache, das die ganze Abfrage
> unter mysql4 bereits reibungslos funktioniert hat. Der Fehler:
> #1037 - Out of memory; restart server and try again (needed 65528 bytes)
> tritt erst unter mysql5 auf (Installation XAMPP). Dabei ist es unerheblich,
> ob die Tabellen Indexe haben oder nicht. Es geht immer um die gleichen
> 65528 bytes. Das ist das erste, was mich stutzig macht. Das zweite, wie
> gesagt, das es nur unter mysql5 passiert. Die dritte Sache ist die Ausgabe
> von EXPLAIN.

Also, was ich nicht verstehe (ausser dass Du auf keine der Antworten
wirklich eingegangen bist und alles besser weisst) ist der ständige
Hinweis auf die Größe der DB. Die hat nicht zwingend was mit dem Problem
zu tun.

Stell dir vor, Du hast 3 gleich aufgebaute Tabellenmit jeweils 1000
Zeilen. Dann macht das zusammen 3000 Zeilen. Das ist Kinderfasching.

Wenn Du diese 3 Tabellen jetztetwas ungeschickt und ohne Indexe joinst
bekommst Du eventuell ein Kreuzprodukt. Das wäre dann eine Ergebnismenge
mit 1000^3 Zeilen oder 1000 000 000 und das ist kein Kinderfasching
mehr. Du siehst also, die Gesamtzahl der Zeilen in den betroffenen
Tabellen sagen nicht wirklich was über Größe der Ergebnismenge aus.

Selbst wenn Du als Ergebnis Deines Selects nur eine Zeilen bekommst,
kannst Du ohne lesen des Executionplans nicht sagen, ob Executer
zwischendurch mal das Kreuzprodukt ermitteln musste.

Das zweite Problem ist die von Dir genannte Abhängigkeit der
DBMS-Version. Leider oder zum Glück ist es bei Versionswechseln so,
dass sich der Optimizer unter Umständen in Details ändert. Diese
Kleinigkeitenn können aber dazu führen, dass aus einem performanten
Zugriff ein Global-Killer wird, weil plötzlich als Zwischenergebnis
etwas fies grosses erstellt wird.

Die Aussage, dass der Speicherbedarf einer Abfrage unabhängig davon ist,
ob auf Tabellen Index existieren oder nicht, ist vorsichtig ausgedrückt,
gequirlte Sch...., un dich will dazu nicht mehr sagen.

so far,
Michael

Re: out of memory

Am Sat, 30 Sep 2006 14:44:07 +0200 schrieb Thomas Rachel:

> Mathias Fiedler wrote:
>
>
>> Das Ergebnis von EXPLAIN ist im Anhang.
>
> Warum, um alles in der Welt, als .doc-Datei im Anhang (was in NGs ohnehin
> verpönt ist)? Warum nicht einfach als Klartext in den Mailbody?
>
>
> Thomas

Weil im Klartext die Tabellenstruktur zerrissen wird.

Re: out of memory

Am Sat, 30 Sep 2006 22:20:41 +0200 schrieb Michael König:

> Mathias Fiedler schrieb:
>> Hallo
>>
>> um das nochmal zu klären. Diese Anfrage hat nichts mit dem Thread "zwei
>> Tabellen" zu tun, wo es um die Indexerstellung ging.
>> In diesem Fall werden Indexe benutzt, obwohl die Datenmenge eher gering
>> ist. Ebenfalls wichtig erscheint mir die Tatsache, das die ganze Abfrage
>> unter mysql4 bereits reibungslos funktioniert hat. Der Fehler:
>> #1037 - Out of memory; restart server and try again (needed 65528 bytes)
>> tritt erst unter mysql5 auf (Installation XAMPP). Dabei ist es unerheblich,
>> ob die Tabellen Indexe haben oder nicht. Es geht immer um die gleichen
>> 65528 bytes. Das ist das erste, was mich stutzig macht. Das zweite, wie
>> gesagt, das es nur unter mysql5 passiert. Die dritte Sache ist die Ausgabe
>> von EXPLAIN.
>
> Also, was ich nicht verstehe (ausser dass Du auf keine der Antworten
> wirklich eingegangen bist und alles besser weisst) ist der ständige
> Hinweis auf die Größe der DB. Die hat nicht zwingend was mit dem Problem
> zu tun.
>
Welche Antworten? Die mit den Indexen? Was soll ich auf einen solchen
Blödsinn eingehen. Ich nutze Indexe !
Nur hier scheint niemand auf die Frage eingehen zu wollen. Stattdessen muß
ich mir wieder das gleiche Gesülz anhören.
Habe ich gesagt, ich nutze keinen Index? Nein !
Habe ich gesagt, es geht n u r um die DB-Größe? Nein !
Habe ich von 1000 Zeilen gesprochen? Nein !
Habe ich die Indexerstellung von der Tabellengröße abhängig gemacht? Nein!
Ich ahbe lediglich gesagt, das sich mit oder ohne Indes an dem Fehler
nichts ändert, das ist etwas anderes!

> Stell dir vor, Du hast 3 gleich aufgebaute Tabellenmit jeweils 1000
> Zeilen. Dann macht das zusammen 3000 Zeilen. Das ist Kinderfasching.
>
> Wenn Du diese 3 Tabellen jetztetwas ungeschickt und ohne Indexe joinst
> bekommst Du eventuell ein Kreuzprodukt. Das wäre dann eine Ergebnismenge
> mit 1000^3 Zeilen oder 1000 000 000 und das ist kein Kinderfasching
> mehr. Du siehst also, die Gesamtzahl der Zeilen in den betroffenen
> Tabellen sagen nicht wirklich was über Größe der Ergebnismenge aus.
>
Und nun nochmal, was um alles in der Welt hast Du ständig mit dem Index?
hast Du überhaupt meine Frage gelesen, oder bist Du etwa schon beim lesen
meines Namens darauf aus wieder Dein geballtes Wissen zu nicht gestellten
Fragen und nihct existierenden Voraussetzungen abzulassen?

Ich benutze Indexe ! Kannst Du das lesen ????

Ich habe alle Tabellen auf 2 DS reduziert. Jetzt komme ich nach Deiner und
meiner Rechnung auf max 2^5 Zeilen = 64 Zeilen. Und das ist Kinderfasching.
Der Fehler erscheint immer noch genauso. Nehme ich aus dem Order By
Statement einen bestimmten Wert weg (re.ref1), funktioniert die Abfrage.
Was nun ?


> Selbst wenn Du als Ergebnis Deines Selects nur eine Zeilen bekommst,
> kannst Du ohne lesen des Executionplans nicht sagen, ob Executer
> zwischendurch mal das Kreuzprodukt ermitteln musste.
Natürlich muß er das ermitteln. Das mußte er aber unter mysql4 auch schon.

>
> Das zweite Problem ist die von Dir genannte Abhängigkeit der
> DBMS-Version. Leider oder zum Glück ist es bei Versionswechseln so,
> dass sich der Optimizer unter Umständen in Details ändert. Diese
> Kleinigkeitenn können aber dazu führen, dass aus einem performanten
> Zugriff ein Global-Killer wird, weil plötzlich als Zwischenergebnis
> etwas fies grosses erstellt wird.
>
Dafür hätte ich ja Verständnis, wenn unter mysql4 schon die Zeitgrenze
erreicht würde. Aber die selbe Abfrage ist dort in 0,... sec durch. In
mysql5 gehts auf einmal gar nicht mehr.

> Die Aussage, dass der Speicherbedarf einer Abfrage unabhängig davon ist,
> ob auf Tabellen Index existieren oder nicht, ist vorsichtig ausgedrückt,
> gequirlte Sch...., un dich will dazu nicht mehr sagen.
Das ist keine Aussage von mir sondern eine Feststellung nach dem Ausführen
der sql Abfrage. Die Fehlermdlung lautet "needed 65528 bytes". Und das egal
ob ich nur zwei Tabellen oder 5 Tabellen verwende, ob ich die Tabellen mit
zwei oder 1000 Datensätzen gefüllt habe, ob ich einen Index verwende oder
nicht. Daher meine Aussage zum Speicherbedarf.
> so far,
> Michael

Re: out of memory

Am Sat, 30 Sep 2006 15:28:49 +0200 schrieb Claus Reibenstein:

> Mathias Fiedler schrieb:
>
>> Ich habe hier 1024 MB RAM und Festplatenkapazität von mehreren 100GB.
>
> Dieses Argument kommt oft, ist aber vollkommen irrelevant. Welchen und
> wieviel Speicher Du hast, interessiert erst an zweiter Stelle. An erster
> Stelle steht die Frage, wieviel Speicher Du MySQL zur Verfügung stellst.
>
>> Kann man vieleicht bin mysql5 irgendeine Speichergröße einstellen?
>
> Bei MySQL konnte man schon in der Version 4 (ältere kenne ich nicht)
> verschiedene Speichergrößen einstellen. Deine Frage lässt darauf
> schließen, dass Du Dich darum noch nie gekümmert hast.
>
Warum auch, es war noch nie nötig.

> Schau mal ins Administratorhandbuch. Dort wird ziemlich ausführlich
> erklärt, an welchen "Schrauben" man drehen kann. Diese "Schrauben"
> solltest Du dann in my.cnf mal richtig "anziehen".
>
>> Unter mysql4 lief die DB-Abfrage problemlos. Unter mysql5 nicht mehr.
>
> Zufall? Glück? Nenne es, wie Du willst.
>
> Gruß. Claus

Re: out of memory

>
> Das ist ein JOIN über 5 Tabellen. Ohne passende Indexe (ich erinnere an
> den Thread "zwei Tabellen") kann da ein durchaus fettes Zwischenergebnis
> entstehen, das in Folge den Server an Out-of-memory sterben läßt.
>
Woher siehst Du, das sa keine Indexe drin sind ?

Re: out of memory

Hallo nochmal,
ich danke für die viele aufschlußreiche Hilfe :)
An alle die mir geschrieben haben, möchte ich sagen:

Der Fehler lag nicht am Index.
Der Fehler lag nicht in zu vielen gejointen Tabellen.
Der Fehler lag nicht an zu wenig Speicher.
Der Fehler lag nicht an falschen Einstellungen in der my.cnf.
Der Fehler lag auch nicht an zu wenig von mir gelesenen Büchern.

Der Fehler wäre mit all den "guten" Ratschlägen aus der NG n i c h t
behoben gewesen.

Ich habe es, zumindest zum Teil, selbst gefunden.

Ich habe in der Tabelle reference_nb nur 5 Spalten. Eine ID als Auto-
increment und Primärschlüssel, eine ID aus einer anderen Tabelle, die bei
dieser Abfrage unrelevant ist und 4 Spalten für Referenzenummern (ref1,
ref2, ref3, ref4). Die Tabelle enthält 430 Einträge. Wie aus meinem syql
Statemant unschwer zu erkennen ist, wird diese Tabelle mit gejoint. Im
Order By Statemant wird nun nach den 4 Referenznummern sortiert. Und genau
dort steigt der mysql-Server aus. Alle 4 Spalten für die Referenzenummern
sind indexiert.
Ich habe immer nur mit ref1 experimentiert. Es ist aber definitiv so, das
nur eine Sortierung nach 3 Spalten dieser Tabelle durchgeführt werden kann.
Sobald ich eine vierte Spalte in die Sortierung einbeziehe, steigt der
Server aus. Da alle Spalten ähnlich aufgebaute Werte beinhalten, mit einem
Index versehen sind und auch die gleiche Kollation haben, ist mir dieses
Verhalten unverständlich. Ich habe im Manual nichts darüber lesen können,
das eine Sortierung nach Spalten in der Anzahl der Spalten pro Tabelle
begrenzt ist. Da ich in einer weiteren Abfrage aus einer anderen Tabelle
nach 6 Spalten sortieren lasse und diese funktioniert, kann das ja wohl
auch nicht sein.
An den Feldtypen oder an der Kolaltion kanne s auch nicht liegen, da bei
der anderen Tabelle mit 6 Sortierungen auch alle die gleichen Werte
aufweisen.
Was bleibt nun noch übrig? Keine Ahnung. Aber meine gesamte Applikation
läuft wieder. Auf die Sortierung nach der vierten Referenznummer kann ich
problemlos verzichten.

Da auch die ganzen "Experten" hier in der NG keinen blassen Schimmer von
einem solchen Phänomän haben, bin ich beruhigt. So klug, wie Ihr immer tut,
und so blöd, wie Ihr mich immer gern darstellen wollt, sind wir wohl alle
nicht.

Ach ja, und falls doch jemand auf diesen Beitrag antworten möchte, bitte
keine weiteren Hinweise auf Indexe, ich habe nämlich welche verwendet.

mfg

Mathias

Re: out of memory

Mathias Fiedler schrieb:

> Da auch die ganzen "Experten" hier in der NG keinen blassen Schimmer von
> einem solchen Phänomän haben, bin ich beruhigt. So klug, wie Ihr immer tut,
> und so blöd, wie Ihr mich immer gern darstellen wollt, sind wir wohl alle
> nicht.
>

Du machst reichlich viele Worte, nur um "Ich will ins Killfile" zu sagen.

Re: out of memory

Mathias Fiedler schrieb:
> Hallo nochmal,
> ich danke für die viele aufschlußreiche Hilfe :)
> An alle die mir geschrieben haben, möchte ich sagen:
>
> Der Fehler lag nicht am Index.

sicher? siehe unten

> Ich habe es, zumindest zum Teil, selbst gefunden.
>
> Ich habe in der Tabelle reference_nb nur 5 Spalten. Eine ID als Auto-
> increment und Primärschlüssel, eine ID aus einer anderen Tabelle, die bei
> dieser Abfrage unrelevant ist und 4 Spalten für Referenzenummern (ref1,
> ref2, ref3, ref4). Die Tabelle enthält 430 Einträge. Wie aus meinem syql
> Statemant unschwer zu erkennen ist, wird diese Tabelle mit gejoint. Im
> Order By Statemant wird nun nach den 4 Referenznummern sortiert. Und genau
> dort steigt der mysql-Server aus. Alle 4 Spalten für die Referenzenummern
> sind indexiert.

Könntest Du auch sagen, wie?
Ich meine, jede Zeile für sich oder gibt es auch einen Index, in dem
alle 4 Spalten in der Reihenfolge auftreten, in der sie auch in der
Order-Clause stehe?

Zur Erläuterung: Der Executer verwendet natürlich auch für das Order
eventuell vorhandene Indexe. Allerdings, wie immer nur von vorne her und
nur einen. Hast Du also die 4 Spalten einzeln indexiert, kann für das
Order nur der Index der ersten Spalte verwendet werden. Hast Du hingegen
einen Index, in dem mehrere der Spalten (in der richtigen) auftauchen,
kann der verwendet werden.

Beispiel: Du sortierst immer nach s1, s2, s3, s4

Indexe gibt es nur für jede Spalte einzeln (oder nicht in der richtigen
Reihenfolge): dann wird nur Index s1 verwendet.

Es gibt einen Index über die Spalten s1, .., s4 (in dieser Reihenfolge),
dann wir dieser Index für die ganze Sortierung verwendet.

Damit ist die Sortierung in Situation 2 deutlich billiger.


Und wie früher bereits erwähnt, hat sich der Optimizer von Version 4 auf
5 eventuell so verändert, dass für die Erstellung Deines Resultset
deutlich mehr Speicher verbraucht wurde. Beim Sortieren wird weiter
Speicher gebraucht. Wenn jetzt nicht die richtigen Index zur Verfügung
stehen, wird die Grenze überschritten. Bei idealen Indexen bleibt er
drunter. Und da zählt halt jede einzelne Spalte, die in der Order-Clause
steht.


> Ach ja, und falls doch jemand auf diesen Beitrag antworten möchte, bitte
> keine weiteren Hinweise auf Indexe, ich habe nämlich welche verwendet.

Nur reicht es eben nicht immer aus, Index zu verwenden, häufig ist es
wichtig, die richtigen Index zu haben und vorallem nicht zu viele. ;-)

> mfg
>
> Mathias

Gruß,
Michael

Re: out of memory

Mathias Fiedler schrieb:

> Am Sat, 30 Sep 2006 15:28:49 +0200 schrieb Claus Reibenstein:
>
>> [Fullquote mit einer eingeschobenen Kommentarzeile entsorgt]

Bitte lies und beherzige, was dort steht. Deine
ständigen Fullquotes nerven allmählich.

Gruß. Claus

Re: out of memory

Mathias Fiedler schrieb:

> Der Fehler lag nicht an falschen Einstellungen in der my.cnf.

So? Was hast Du denn probiert? Wie sah Deine my.cnf ursprünglich aus,
und was hast Du wie geändert?

> Der Fehler wäre mit all den "guten" Ratschlägen aus der NG n i c h t
> behoben gewesen.

Du hast also tatsächlich alle Ratschläge geprüft und probiert?

> Ich habe es, zumindest zum Teil, selbst gefunden.

Nein, hast Du nicht.

> Ich habe immer nur mit ref1 experimentiert. Es ist aber definitiv so, das
> nur eine Sortierung nach 3 Spalten dieser Tabelle durchgeführt werden kann.
> Sobald ich eine vierte Spalte in die Sortierung einbeziehe, steigt der
> Server aus. [...]
> Was bleibt nun noch übrig? Keine Ahnung. Aber meine gesamte Applikation
> läuft wieder. Auf die Sortierung nach der vierten Referenznummer kann ich
> problemlos verzichten.

Du hast das Problem also _nicht_ gelöst, sondern nur umgangen. Du hast
das Symptom behandelt, aber nicht die Ursache.

> Da auch die ganzen "Experten" hier in der NG keinen blassen Schimmer von
> einem solchen Phänomän haben, bin ich beruhigt. So klug, wie Ihr immer tut,
> und so blöd, wie Ihr mich immer gern darstellen wollt, sind wir wohl alle
> nicht.

Warum hast Du nicht gleich gesagt, dass Du keine Hilfe erhalten
möchtest? Das hätte uns allen viel Zeit erspart, die wir für Dich von
unserer Freizeit geopfert haben. Aber wenn das der Dank dafür ist, dann
wird das wohl das letzte Mal gewesen sein.

Du willst dumm sterben? Du wirst dumm sterben.

Gruß. Claus

Re: out of memory

Mathias Fiedler wrote:
> Am Sat, 30 Sep 2006 22:20:41 +0200 schrieb Michael König:
>>
>> Also, was ich nicht verstehe (ausser dass Du auf keine der Antworten
>> wirklich eingegangen bist und alles besser weisst) ist der ständige
>> Hinweis auf die Größe der DB. Die hat nicht zwingend was mit dem Problem
>> zu tun.
>>
> Welche Antworten? Die mit den Indexen? Was soll ich auf einen solchen
> Blödsinn eingehen.
____ _ _ _
| _ \ __ _| |_ ___ ___| |__ | |
| |_) / _` | __/ __|/ __| '_ \| |
| __/ (_| | |_\__ \ (__| | | |_|
|_| \__,_|\__|___/\___|_| |_(_)

(das war das Geräusch der Ohrfeige, die du dir gerade eingefangen hast)

> Ich nutze Indexe !

Bis vor kurzem wußtest du (nach eigener Aussage) noch nicht mal, was
das ist. Ich erlaube mir also Zweifel an deiner Aussage.

> Nur hier scheint niemand auf die Frage eingehen zu wollen. Stattdessen muß
> ich mir wieder das gleiche Gesülz anhören.
____ _ _ _
| _ \ __ _| |_ ___ ___| |__ | |
| |_) / _` | __/ __|/ __| '_ \| |
| __/ (_| | |_\__ \ (__| | | |_|
|_| \__,_|\__|___/\___|_| |_(_)

(auf die andere Wange)

> Habe ich gesagt, ich nutze keinen Index? Nein !
> Habe ich gesagt, es geht n u r um die DB-Größe? Nein !
> Habe ich von 1000 Zeilen gesprochen? Nein !
> Habe ich die Indexerstellung von der Tabellengröße abhängig gemacht? Nein!
> Ich ahbe lediglich gesagt, das sich mit oder ohne Indes an dem Fehler
> nichts ändert, das ist etwas anderes!

Wir kommen der Sache näher. Du hast bis jetzt noch nichts zur Lösung
deines Problem beigetragen. Das betreffende SQL-Statement hast du im
3. Posting genannt. Über die Tabellendefinitionen und die ungefähre
Verteilung der Daten wissen wir nach wie vor *nichts*. Noch nicht mal
die Ausgabe von EXPLAIN konntest du auf lesbare Weise rüberbringen.

Und NEIN - ich werde keinen Word-Anhang dechiffrieren (stell dir vor,
ich habe kein Word). DU willst etwas, da solltest DU es uns auch leicht
machen dir zu helfen. Wenn du dazu nicht bereit bist - geh weg!

>> Stell dir vor, Du hast 3 gleich aufgebaute Tabellenmit jeweils 1000
>> Zeilen. Dann macht das zusammen 3000 Zeilen. Das ist Kinderfasching.
>>
>> Wenn Du diese 3 Tabellen jetztetwas ungeschickt und ohne Indexe joinst
>> bekommst Du eventuell ein Kreuzprodukt. Das wäre dann eine Ergebnismenge
>> mit 1000^3 Zeilen oder 1000 000 000 und das ist kein Kinderfasching
>> mehr. Du siehst also, die Gesamtzahl der Zeilen in den betroffenen
>> Tabellen sagen nicht wirklich was über Größe der Ergebnismenge aus.

Das ist eine sehr schöne Erklärung. Hast du die verstanden?

> Ich benutze Indexe !

Das glaubst du. Es geht aber darum, ob die Datenbank Indexe benutzt.
Genau das teilt dir EXPLAIN mit. Wenn ich das lesen könnte...

> Kannst Du das lesen ????

Kannst du denken?

>> Selbst wenn Du als Ergebnis Deines Selects nur eine Zeile bekommst,
>> kannst Du ohne lesen des Executionplans nicht sagen, ob Executer
>> zwischendurch mal das Kreuzprodukt ermitteln musste.

> Natürlich muß er das ermitteln. Das mußte er aber unter mysql4 auch schon.

Siehste, du hast keine Ahnung. Jede Datenbank versucht, große Zwischen-
ergebnisse zu vermeiden. Dazu hat sie zwei Komponenten, eine die einen
Execution-Plan aufstellt und eine die diesen optimiert. Der Optimizer
orientiert sich dazu an den vorhandenen Indexen. Und wenn die Indexe
nicht für die Query passen, dann wird halt nicht der beste Plan
genommen, sondern ein anderer. Und weil Sortieren teuer ist, wird auch
ein ORDER BY berücksichtigt. Der Optimizer wählt also verschiedene
Wege, je nachdem wonach du sortierst. Und - oh Wunder - auch *das* kann
dir EXPLAIN anzeigen.

Und - tärä - in MySQL 5 sind Planner und Optimizer fast komplett neu
geschrieben - im Vergleich mit 4.x. Es ist also *überhaupt* nicht
verwunderlich, daß sich MySQL 5 hier anders verhält.


XL

Re: out of memory

Am Sun, 01 Oct 2006 11:36:38 +0200 schrieb Christian Kirsch:

> Mathias Fiedler schrieb:
>
>> Da auch die ganzen "Experten" hier in der NG keinen blassen Schimmer von
>> einem solchen Phänomän haben, bin ich beruhigt. So klug, wie Ihr immer tut,
>> und so blöd, wie Ihr mich immer gern darstellen wollt, sind wir wohl alle
>> nicht.
>>
>
> Du machst reichlich viele Worte, nur um "Ich will ins Killfile" zu sagen.

Dann tu es, das erspart uns beiden beim mnächsten Mal viel Zeit und Nerven-

Re: out of memory

Am Sun, 01 Oct 2006 11:57:02 +0200 schrieb Michael König:

> Mathias Fiedler schrieb:
>> Hallo nochmal,
>> ich danke für die viele aufschlußreiche Hilfe :)
>> An alle die mir geschrieben haben, möchte ich sagen:
>>
>> Der Fehler lag nicht am Index.
>
> sicher? siehe unten
>
>> Ich habe es, zumindest zum Teil, selbst gefunden.
>>
>> Ich habe in der Tabelle reference_nb nur 5 Spalten. Eine ID als Auto-
>> increment und Primärschlüssel, eine ID aus einer anderen Tabelle, die bei
>> dieser Abfrage unrelevant ist und 4 Spalten für Referenzenummern (ref1,
>> ref2, ref3, ref4). Die Tabelle enthält 430 Einträge. Wie aus meinem syql
>> Statemant unschwer zu erkennen ist, wird diese Tabelle mit gejoint. Im
>> Order By Statemant wird nun nach den 4 Referenznummern sortiert. Und genau
>> dort steigt der mysql-Server aus. Alle 4 Spalten für die Referenzenummern
>> sind indexiert.
>
> Könntest Du auch sagen, wie?
> Ich meine, jede Zeile für sich oder gibt es auch einen Index, in dem
> alle 4 Spalten in der Reihenfolge auftreten, in der sie auch in der
> Order-Clause stehe?
>
> Zur Erläuterung: Der Executer verwendet natürlich auch für das Order
> eventuell vorhandene Indexe. Allerdings, wie immer nur von vorne her und
> nur einen. Hast Du also die 4 Spalten einzeln indexiert, kann für das
> Order nur der Index der ersten Spalte verwendet werden. Hast Du hingegen
> einen Index, in dem mehrere der Spalten (in der richtigen) auftauchen,
> kann der verwendet werden.
>
> Beispiel: Du sortierst immer nach s1, s2, s3, s4
>
> Indexe gibt es nur für jede Spalte einzeln (oder nicht in der richtigen
> Reihenfolge): dann wird nur Index s1 verwendet.
>
> Es gibt einen Index über die Spalten s1, .., s4 (in dieser Reihenfolge),
> dann wir dieser Index für die ganze Sortierung verwendet.
>
> Damit ist die Sortierung in Situation 2 deutlich billiger.
>
>
> Und wie früher bereits erwähnt, hat sich der Optimizer von Version 4 auf
> 5 eventuell so verändert, dass für die Erstellung Deines Resultset
> deutlich mehr Speicher verbraucht wurde. Beim Sortieren wird weiter
> Speicher gebraucht. Wenn jetzt nicht die richtigen Index zur Verfügung
> stehen, wird die Grenze überschritten. Bei idealen Indexen bleibt er
> drunter. Und da zählt halt jede einzelne Spalte, die in der Order-Clause
> steht.
>
>
>> Ach ja, und falls doch jemand auf diesen Beitrag antworten möchte, bitte
>> keine weiteren Hinweise auf Indexe, ich habe nämlich welche verwendet.
>
> Nur reicht es eben nicht immer aus, Index zu verwenden, häufig ist es
> wichtig, die richtigen Index zu haben und vorallem nicht zu viele. ;-)
>
>> mfg
>>
>> Mathias
>
> Gruß,
> Michael

Nun, erst mal Danke für die Ausführungen. Ich habe nie behauptet der mysql
Experte zu sein. Jetzt bin ich wieder etwas schlauer. Die Sache mit den
Indexen über mehrere Spalten war mir so nicht bewußt. Ich meine, nicht das
ich es nie gehört hätte, sondern das mir die Vorgehensweise des Optimizers
so nicht bekannt war. Aber genau deshalb habe ich mich an die NG gewandt.
Auf jeden Fall danke ich Dir Für den konstruktiven Beitrag, mit dem ich
mehr anfangen konnte, als mit allem anderen vorher.

mfg

Mathias

Re: out of memory

Am Sun, 01 Oct 2006 13:45:44 +0200 schrieb Claus Reibenstein:

> Mathias Fiedler schrieb:
>
>> Der Fehler lag nicht an falschen Einstellungen in der my.cnf.
>
> So? Was hast Du denn probiert? Wie sah Deine my.cnf ursprünglich aus,
> und was hast Du wie geändert?
Unverändert, also ewie nach der Installation.
>
>> Der Fehler wäre mit all den "guten" Ratschlägen aus der NG n i c h t
>> behoben gewesen.
>
> Du hast also tatsächlich alle Ratschläge geprüft und probiert?
>
Nein, es gab ja keine. Ausser EXPLAIN, aber das willst Du ja nicht ansehen.

>> Ich habe es, zumindest zum Teil, selbst gefunden.
>
> Nein, hast Du nicht.
>
Doch !
>> Ich habe immer nur mit ref1 experimentiert. Es ist aber definitiv so, das
>> nur eine Sortierung nach 3 Spalten dieser Tabelle durchgeführt werden kann.
>> Sobald ich eine vierte Spalte in die Sortierung einbeziehe, steigt der
>> Server aus. [...]
>> Was bleibt nun noch übrig? Keine Ahnung. Aber meine gesamte Applikation
>> läuft wieder. Auf die Sortierung nach der vierten Referenznummer kann ich
>> problemlos verzichten.
>
> Du hast das Problem also _nicht_ gelöst, sondern nur umgangen. Du hast
> das Symptom behandelt, aber nicht die Ursache.
>
Die Ursache habe ich nicht gefunden. Nach dem Beitrag von Michael kommen wir der
Ursache näher. Von Dir kam nur heisse Luft, also blas Dich nicht so auf.

>> Da auch die ganzen "Experten" hier in der NG keinen blassen Schimmer von
>> einem solchen Phänomän haben, bin ich beruhigt. So klug, wie Ihr immer tut,
>> und so blöd, wie Ihr mich immer gern darstellen wollt, sind wir wohl alle
>> nicht.
>
> Warum hast Du nicht gleich gesagt, dass Du keine Hilfe erhalten
> möchtest? Das hätte uns allen viel Zeit erspart, die wir für Dich von
> unserer Freizeit geopfert haben. Aber wenn das der Dank dafür ist, dann
> wird das wohl das letzte Mal gewesen sein.
>
Warum opferst Du Deine Freizeit dafür, mich als blöd hinzustellen, weil ich
mal nach Indexen gefragt habe? Hättest Du eine Antwort auf meine Frage gehabt,
wäre der Thread schon längst beendet. Du weist sicherlich mehr als ich über
mysql, das ist aber noch lange Grund für Selbstüberschätzung und Arroganz.

Hoffentlich war es das Letzte Mal, das Du auf einen meiner Beiträge geantwortet
hast. Auf Links von Googel zu meinen alten Threads und Vorführungen Deiner
Genialtität lege ich keinen Wert.

Mathias

Re: out of memory

Am Sun, 1 Oct 2006 13:46:21 +0200 schrieb Axel Schwenke:

> Mathias Fiedler wrote:
>> Am Sat, 30 Sep 2006 22:20:41 +0200 schrieb Michael König:
>>>
>>> Also, was ich nicht verstehe (ausser dass Du auf keine der Antworten
>>> wirklich eingegangen bist und alles besser weisst) ist der ständige
>>> Hinweis auf die Größe der DB. Die hat nicht zwingend was mit dem Problem
>>> zu tun.
>>>
>> Welche Antworten? Die mit den Indexen? Was soll ich auf einen solchen
>> Blödsinn eingehen.
> ____ _ _ _
>| _ \ __ _| |_ ___ ___| |__ | |
>||_) / _` | __/ __|/ __| '_ \| |
>| __/ (_| | |_\__ \ (__| | | |_|
>|_| \__,_|\__|___/\___|_| |_(_)
>
> (das war das Geräusch der Ohrfeige, die du dir gerade eingefangen hast)
>
>> Ich nutze Indexe !
>
> Bis vor kurzem wußtest du (nach eigener Aussage) noch nicht mal, was
> das ist. Ich erlaube mir also Zweifel an deiner Aussage.

Bist du bereits als Genie auf die Welt gekommen, oder mußtest Du Dir DEin
Wissen erarbeiten? Lannst Du Dir vorstellen das es Menschen gibt, die
lernen und das gelernte dann anwenden?
>
>> Nur hier scheint niemand auf die Frage eingehen zu wollen. Stattdessen muß
>> ich mir wieder das gleiche Gesülz anhören.
> ____ _ _ _
>| _ \ __ _| |_ ___ ___| |__ | |
>||_) / _` | __/ __|/ __| '_ \| |
>| __/ (_| | |_\__ \ (__| | | |_|
>|_| \__,_|\__|___/\___|_| |_(_)
>
> (auf die andere Wange)

Du mich auch !!

>
>> Habe ich gesagt, ich nutze keinen Index? Nein !
>> Habe ich gesagt, es geht n u r um die DB-Größe? Nein !
>> Habe ich von 1000 Zeilen gesprochen? Nein !
>> Habe ich die Indexerstellung von der Tabellengröße abhängig gemacht? Nein!
>> Ich ahbe lediglich gesagt, das sich mit oder ohne Indes an dem Fehler
>> nichts ändert, das ist etwas anderes!
>
> Wir kommen der Sache näher. Du hast bis jetzt noch nichts zur Lösung
> deines Problem beigetragen. Das betreffende SQL-Statement hast du im
> 3. Posting genannt. Über die Tabellendefinitionen und die ungefähre
> Verteilung der Daten wissen wir nach wie vor *nichts*. Noch nicht mal
> die Ausgabe von EXPLAIN konntest du auf lesbare Weise rüberbringen.
>
Wer lesen kann ist klar im Vorteil. Im ersten Posting ging es um die Frage,
ob ich --quick verwenden kann, weil im Manual darauf hingewiesen wurde.

> Und NEIN - ich werde keinen Word-Anhang dechiffrieren (stell dir vor,
> ich habe kein Word). DU willst etwas, da solltest DU es uns auch leicht
> machen dir zu helfen. Wenn du dazu nicht bereit bist - geh weg!
>
Du armer.Kann ich ewtas für Deinen Feldzug gegen Microsoft? Ich habe Word
und ich nutze Word und ich habe kein Problem damit. Sogar unter LINUX und
mit einem alten StarOffice wäre das Dokument zu öffnen gewesen. Du
Garnichterstversucher.

>>> Stell dir vor, Du hast 3 gleich aufgebaute Tabellenmit jeweils 1000
>>> Zeilen. Dann macht das zusammen 3000 Zeilen. Das ist Kinderfasching.
>>>
>>> Wenn Du diese 3 Tabellen jetztetwas ungeschickt und ohne Indexe joinst
>>> bekommst Du eventuell ein Kreuzprodukt. Das wäre dann eine Ergebnismenge
>>> mit 1000^3 Zeilen oder 1000 000 000 und das ist kein Kinderfasching
>>> mehr. Du siehst also, die Gesamtzahl der Zeilen in den betroffenen
>>> Tabellen sagen nicht wirklich was über Größe der Ergebnismenge aus.
>
> Das ist eine sehr schöne Erklärung. Hast du die verstanden?
>
Hast Du meine Postings dazu gelesen? Nein! Sonst wüßtest Du die Antwort
bereits. Ich habe es verstanden und darauf geantwortet.

>> Ich benutze Indexe !
>
> Das glaubst du. Es geht aber darum, ob die Datenbank Indexe benutzt.
> Genau das teilt dir EXPLAIN mit. Wenn ich das lesen könnte...
>
Lern es!

>> Kannst Du das lesen ????
>
> Kannst du denken?

Ich glaube schon :)
>
>>> Selbst wenn Du als Ergebnis Deines Selects nur eine Zeile bekommst,
>>> kannst Du ohne lesen des Executionplans nicht sagen, ob Executer
>>> zwischendurch mal das Kreuzprodukt ermitteln musste.
>
>> Natürlich muß er das ermitteln. Das mußte er aber unter mysql4 auch schon.
>
> Siehste, du hast keine Ahnung. Jede Datenbank versucht, große Zwischen-
> ergebnisse zu vermeiden. Dazu hat sie zwei Komponenten, eine die einen
> Execution-Plan aufstellt und eine die diesen optimiert. Der Optimizer
> orientiert sich dazu an den vorhandenen Indexen. Und wenn die Indexe
> nicht für die Query passen, dann wird halt nicht der beste Plan
> genommen, sondern ein anderer. Und weil Sortieren teuer ist, wird auch
> ein ORDER BY berücksichtigt. Der Optimizer wählt also verschiedene
> Wege, je nachdem wonach du sortierst. Und - oh Wunder - auch *das* kann
> dir EXPLAIN anzeigen.
>
Und oh Wunder, das lernt man in der ersten Klasse? Nein, Du Genie. Das muß
man sich erarbeiten. Das hast Du zweifelsohne getan, das finde ich toll.
Wie ich aber auch schon desöfteren sagte, mein Tagesgeschäft sind nicht
mysqlDatenbanken. Deshalb ahbe ich das auch nicht studiert oder so. Ich
weis, das Datenbankdesign ein eigenes Studienfach ist und das es da
massenhaft Dinge gibt, die ich nicht weis. Aber genau deshalb habe ich hier
nachgefragt. Allerdings hatte ich auf eine Antwort gehofft und nicht auf
den Hinweis, das ich etwas nicht weis. Das war ja gerade der Grund meiner
Frage. Was sagst Du Deinem Kind in der ersten Klasse, wenn es Dich fragt,
wieviel ist 2 + 3? Du bist blöd, oder hilfst Du Ihm das Ergebnis zu finden?
Denk ,al dartüber nach, falls Du das kannst.


> Und - tärä - in MySQL 5 sind Planner und Optimizer fast komplett neu
> geschrieben - im Vergleich mit 4.x. Es ist also *überhaupt* nicht
> verwunderlich, daß sich MySQL 5 hier anders verhält.
Doch, das ist es schon. Denn das bedeutet, das jede Website die mysql4
benutzt bei der Umstellung auf mysql5 unter Umständen komplett überarbeitet
werden muß. Und da schimpfst Du über Microsoft. :)

Mathias

Re: out of memory

Mathias Fiedler schrieb:

> Am Sun, 01 Oct 2006 13:45:44 +0200 schrieb Claus Reibenstein:
>
>> Mathias Fiedler schrieb:
>>
>>> Der Fehler lag nicht an falschen Einstellungen in der my.cnf.
>>
>> So? Was hast Du denn probiert? Wie sah Deine my.cnf ursprünglich aus,
>> und was hast Du wie geändert?
>
> Unverändert, also ewie nach der Installation.

Also hast Du _nicht_ alle Hinweise verfolgt. Zumindest meinem bist Du
nicht weiter nachgegangen.

>>> Der Fehler wäre mit all den "guten" Ratschlägen aus der NG n i c h t
>>> behoben gewesen.
>>
>> Du hast also tatsächlich alle Ratschläge geprüft und probiert?
>>
> Nein, es gab ja keine.

WIE BITTE?!?

Sag mal, merkst Du eigentlich noch was? Es hat hier JEDE MENGE Hinweise
gegeben! Wie wäre es mal mit LESEN?

Sorry, aber was Du hier gerade abziehst, ist eine Frechheit! Ein Schlag
ins Gesicht all derer, die sich hier redlich bemühen, Dir zu helfen!

Mach nur weiter so. Du wirst schon sehen, was Du davon hast.

>>> Ich habe es, zumindest zum Teil, selbst gefunden.
>>
>> Nein, hast Du nicht.
>>
> Doch !

Nein!

>> Du hast das Problem also _nicht_ gelöst, sondern nur umgangen. Du hast
>> das Symptom behandelt, aber nicht die Ursache.
>
> Die Ursache habe ich nicht gefunden.

Weil Du nicht danach gesucht hast. Wir haben Dir genug Hinweise gegeben.
Aber Du bist ja offensichtlich nicht in der Lage, diesen Hinweisen mal
nachzugehen. Statt dessen versteckst Du Dich hinter der stereotypen
Behauptung, es hätte keine Hinweise gegeben.

> Von Dir kam nur heisse Luft, also blas Dich nicht so auf.

Noch 'ne Frechheit. Mal schauen, was noch so alles kommt.

> Warum opferst Du Deine Freizeit dafür, mich als blöd hinzustellen, weil ich
> mal nach Indexen gefragt habe?

Ich habe nichts von Indexen geschrieben. Mein Hinweis ging in eine ganz
andere Richtung. Im Übrigen brauche ich Dich nicht als blöd
hinzustellen. Das tust Du ja selber schon zur Genüge. Dieses Posting
hier ist das beste Beispiel dafür.

> Hättest Du eine Antwort auf meine Frage gehabt,
> wäre der Thread schon längst beendet.

Ich hatte Dir einen Hinweis gegeben. Du bist diesem aber nicht
nachgegangen, wie Du oben auch bestätigt hast. Und dann besitzt Du auch
noch die Stirn, mir vorzuwerfen, ich hätte nur heiße Luft produziert.

> Du weist sicherlich mehr als ich über
> mysql, das ist aber noch lange Grund für Selbstüberschätzung und Arroganz.

Welche Selbstüberschätzung? Welche Arroganz? Der einzige, der sich in
diesem Thread arrogant verhält, bist Du. _Du_ behauptest, es hätte keine
Hinweise gegeben. _Du_ hältst es für unnötig, den Hinweisen nachzugehen.
_Du_ ignorierst hier jeglichen Hilfeversuch. Und dann beschimpfst _Du_
auch noch alle, die versucht haben, Dir zu helfen. Toll. Echt toll.

> Hoffentlich war es das Letzte Mal, das Du auf einen meiner Beiträge geantwortet
> hast. Auf Links von Googel zu meinen alten Threads und Vorführungen Deiner
> Genialtität lege ich keinen Wert.

Wo habe ich einen Link zu Deinen alten Threads gepostet? Bitte beweisen!

Das nächste Mal bist Du hoffentlich etwas vorsichtiger mit dem, was Du
hier von Dir gibst. Sonst wirst Du bald nicht mehr nur von mir keine
Antworten mehr bekommen, sondern gar keine.

Gruß. Claus

Re: out of memory

Mathias Fiedler wrote:

[belangloses]

Du willst also gar keine Hilfe.
Statt Hinweise zur Lösung *deines* Problems zu geben, jaulst du
nur rum, weil du dich so schlecht behandelt fühlst. Also:

[X] Geh weg!
[ ] Komm nochmal wieder


EOD. Killfile.

Re: out of memory

Mathias Fiedler schrieb:

> Bist du bereits als Genie auf die Welt gekommen, oder mußtest Du Dir DEin
> Wissen erarbeiten? Lannst Du Dir vorstellen das es Menschen gibt, die
> lernen und das gelernte dann anwenden?

Genau hier beginnt Dein Problem.

> Du armer.Kann ich ewtas für Deinen Feldzug gegen Microsoft? Ich habe Word
> und ich nutze Word und ich habe kein Problem damit. Sogar unter LINUX und
> mit einem alten StarOffice wäre das Dokument zu öffnen gewesen.

Welches Dokument? Hier ist keins angekommen. Auch das wurde Dir schon
mitgeteilt.

> Du Garnichterstversucher.

Wie soll man etwas versuchen, was man gar nicht versuchen _kann_? Im
Übrigen solltest Du vorsichtig mit solchen Begriffen sein. Vor allem
dann, wenn sie Dich noch besser beschreiben ...

> Doch, das ist es schon. Denn das bedeutet, das jede Website die mysql4
> benutzt bei der Umstellung auf mysql5 unter Umständen komplett überarbeitet
> werden muß.

So ein Blödsinn!

Wenn man MySQL 5 richtig konfiguriert, sollten auch die alten Skripte
laufen. Es mag die eine oder andere Ausnahme geben, besonders wenn sie
sich auf proprietäre Features verlassen, die in der neuen Version nicht
mehr - oder zumindest nicht mehr in der Form - funktionieren. In Deinem
Fall sehe ich das aber nicht.

> Und da schimpfst Du über Microsoft. :)

Oh ja! Immer wieder! Mit stetig wachsender Begeisterung! Aus gutem Grund!

Gruß. Claus

Re: out of memory

Mathias Fiedler wrote:

>
>>
>> Das ist ein JOIN über 5 Tabellen. Ohne passende Indexe (ich erinnere
>> an den Thread "zwei Tabellen") kann da ein durchaus fettes
>> Zwischenergebnis entstehen, das in Folge den Server an Out-of-memory
>> sterben läßt.
>>
> Woher siehst Du, das sa keine Indexe drin sind ?

AFAICS war das keine Behauptung, sondern ein Hinweis, woran es liegen
könnte.


Thomas
--
Und wir singen: Bye bye Miss American Pie
Ich hab's länger schon befürchtet, und jetzt ist es soweit
Madonna quietscht, und das Publikum schreit:
'This will be the day that I die'
(http://www.schlabonski.de/americanpie.html)

Re: out of memory

Mathias Fiedler wrote:

> Weil im Klartext die Tabellenstruktur zerrissen wird.

Stimmt. Aber wenn Du im MySQL-Client den Befehl mit \G abschließt statt
mit ";", kommt eine andere, für Postings geeignete Struktur heraus.

Vergleiche beispielsweise:


mysql:glglgl@localhost [verbrauch]> show columns from zaehler;
+-----------+------------------------------+------+-----+--- ----------------+-------+
| Field | Type | Null | Key | Default
| Extra |
+-----------+------------------------------+------+-----+--- ----------------+-------+
| timestamp | timestamp | YES | PRI |
CURRENT_TIMESTAMP | |
| typ | enum('Strom','Gas','Wasser') | | PRI | Strom
| |
| wert | double(10,4) | | | 0.0000
| |
+-----------+------------------------------+------+-----+--- ----------------+-------+
3 rows in set (0,00 sec)

-> Scheiße, zerrissen.



mysql:glglgl@localhost [verbrauch]> show columns from zaehler\G
*************************** 1. row ***************************
Field: timestamp
Type: timestamp
Null: YES
Key: PRI
Default: CURRENT_TIMESTAMP
Extra:
*************************** 2. row ***************************
Field: typ
Type: enum('Strom','Gas','Wasser')
Null:
Key: PRI
Default: Strom
Extra:
*************************** 3. row ***************************
Field: wert
Type: double(10,4)
Null:
Key:
Default: 0.0000
Extra:
3 rows in set (0,01 sec)

-> gut.


HTH,


Thomas
--
Roses are red. Violets are blue. Some poems rhyme. But this one doesn't.

Re: out of memory

karlheinz klingbeil wrote:

> Nur mal so als Anmerkung... PHP kann den Speicherbedarf
> (und die Ausführungszeit) eines Skripts begrenzen.
> Der erlaubte Speicherbedarf eines Skripts per Default
> 64KB soweit ich weiss.
>
> Check mal deine php.ini, bevor du den Fehler auf mysql
> schiebst.

Generell eine gute Idee, alle verwendeten Komponenten zu überprüfenm, ob
sie nicht schuld sein können. Aber "#1037 - Out of memory; restart
server and try again (needed 65528 bytes) " dürfte wohl vom MySQL-Server
kommen. Und daß der Speicherprobleme bei PHP erkennen kann, bezweifele
ich...


Thomas
--
Die .sig wurde fristlos entlassen.

Re: out of memory

Thomas Rachel wrote:
> Generell eine gute Idee, alle verwendeten Komponenten zu überprüfenm, ob
> sie nicht schuld sein können. Aber "#1037 - Out of memory; restart
> server and try again (needed 65528 bytes) " dürfte wohl vom MySQL-Server
> kommen. Und daß der Speicherprobleme bei PHP erkennen kann, bezweifele
> ich...

less sql/share/errmsg.txt
/needed

ER_OUTOFMEMORY HY001 S1001
....
eng "Out of memory; restart server and try again (needed %d bytes)"
....

Die Meldung kommt im Source an mehreren Stellen vor, insbesondere in
sql_select.cc und in filesort.cc.

In sql_select.cc kann die Meldung nur nach einem Aufruf von copy_blobs()
auftreten.

In filesort.cc tritt die Meldung auf, wenn min_sort_memory erschöpft ist:

min_sort_memory= max(MIN_SORT_MEMORY, param.sort_length*MERGEBUFF2);
while (memavl >= min_sort_memory)
{
ulong old_memavl;
ulong keys= memavl/(param.rec_length+sizeof(char*));
param.keys=(uint) min(records+1, keys);
if ((sort_keys= (uchar **) make_char_array(param.keys, param.rec_length,
MYF(0))))
break;
old_memavl=memavl;
if ((memavl=memavl/4*3) < min_sort_memory && old_memavl >
min_sort_memory)
memavl= min_sort_memory;
}
if (memavl < min_sort_memory)
{
my_error(ER_OUTOFMEMORY,MYF(ME_ERROR+ME_WAITTANG),
thd->variables.sortbuff_size);
goto err;
}
....

Re: out of memory

>
> Also hast Du _nicht_ alle Hinweise verfolgt. Zumindest meinem bist Du
> nicht weiter nachgegangen.
>
Schau mal ins Administratorhandbuch. Dort wird ziemlich ausführlich
erklärt, an welchen "Schrauben" man drehen kann. Diese "Schrauben"
solltest Du dann in my.cnf mal richtig "anziehen".

Das nennst Du einen Hinweis? Auch ohne Schrauben drehen und der Hilfe von
Michael, habe ich den fehler gefunden. Es liegt an der Art Indexierung. Es
muß ein Index über mehrere Spalten sein und nicht ein Index für jede
Spalte. Noch etwas hinterher. Nicht jedem ist es (serverbedingt) möglich,
an der my.cnf zu schrauben. aber auch diese Scripte müssen funktionieren.


>>>> Der Fehler wäre mit all den "guten" Ratschlägen aus der NG n i c h t
>>>> behoben gewesen.
>>>
>>> Du hast also tatsächlich alle Ratschläge geprüft und probiert?
>>>
>> Nein, es gab ja keine.
>
> WIE BITTE?!?
>
Genau. Nutze EXPLAIN, habe ich gemacht, keiner will das File lesen. Lies
das Administratorhandbuch, toller Hinweis. Schraub an der my.cnf, ein noch
tollerer Hinweis. Bei mir kommt deranhang auch an.

> Sag mal, merkst Du eigentlich noch was? Es hat hier JEDE MENGE Hinweise
> gegeben! Wie wäre es mal mit LESEN?
>
> Sorry, aber was Du hier gerade abziehst, ist eine Frechheit! Ein Schlag
> ins Gesicht all derer, die sich hier redlich bemühen, Dir zu helfen!
>
Nenn mir Namen mit den Konkreten Vorschlägen in den Beiträgen !

> Mach nur weiter so. Du wirst schon sehen, was Du davon hast.
>
>>>> Ich habe es, zumindest zum Teil, selbst gefunden.
>>>
>>> Nein, hast Du nicht.
>>>
>> Doch !
>
> Nein!
>
>>> Du hast das Problem also _nicht_ gelöst, sondern nur umgangen. Du hast
>>> das Symptom behandelt, aber nicht die Ursache.
>>
>> Die Ursache habe ich nicht gefunden.
>
> Weil Du nicht danach gesucht hast. Wir haben Dir genug Hinweise gegeben.
> Aber Du bist ja offensichtlich nicht in der Lage, diesen Hinweisen mal
> nachzugehen. Statt dessen versteckst Du Dich hinter der stereotypen
> Behauptung, es hätte keine Hinweise gegeben.
>
Der einzige mit einem Hinweis auf Indexe über mehrere Spalten war Michael.
Du hast Dazu nichts beigetragen.

>> Von Dir kam nur heisse Luft, also blas Dich nicht so auf.
>
> Noch 'ne Frechheit. Mal schauen, was noch so alles kommt.
>
>> Warum opferst Du Deine Freizeit dafür, mich als blöd hinzustellen, weil ich
>> mal nach Indexen gefragt habe?
>
> Ich habe nichts von Indexen geschrieben. Mein Hinweis ging in eine ganz
> andere Richtung. Im Übrigen brauche ich Dich nicht als blöd
> hinzustellen. Das tust Du ja selber schon zur Genüge. Dieses Posting
> hier ist das beste Beispiel dafür.
>
Ich habe alles durchsucht, außer dem berühmten Satz mit dem Schrauben war
da nichts.

>> Hättest Du eine Antwort auf meine Frage gehabt,
>> wäre der Thread schon längst beendet.
>
> Ich hatte Dir einen Hinweis gegeben. Du bist diesem aber nicht
> nachgegangen, wie Du oben auch bestätigt hast. Und dann besitzt Du auch
> noch die Stirn, mir vorzuwerfen, ich hätte nur heiße Luft produziert.
>
Wieder die Frage, welcher Hinweis? Das Administrator Handbuch lesen? Mal so
eben schnell in zwei, drei Tagen? Danke !

>> Du weist sicherlich mehr als ich über
>> mysql, das ist aber noch lange Grund für Selbstüberschätzung und Arroganz.
>
> Welche Selbstüberschätzung? Welche Arroganz? Der einzige, der sich in
> diesem Thread arrogant verhält, bist Du. _Du_ behauptest, es hätte keine
> Hinweise gegeben. _Du_ hältst es für unnötig, den Hinweisen nachzugehen.
> _Du_ ignorierst hier jeglichen Hilfeversuch. Und dann beschimpfst _Du_
> auch noch alle, die versucht haben, Dir zu helfen. Toll. Echt toll.
>
Ja toll.

>> Hoffentlich war es das Letzte Mal, das Du auf einen meiner Beiträge geantwortet
>> hast. Auf Links von Googel zu meinen alten Threads und Vorführungen Deiner
>> Genialtität lege ich keinen Wert.
>
> Wo habe ich einen Link zu Deinen alten Threads gepostet? Bitte beweisen!
>
> Das nächste Mal bist Du hoffentlich etwas vorsichtiger mit dem, was Du
> hier von Dir gibst. Sonst wirst Du bald nicht mehr nur von mir keine
> Antworten mehr bekommen, sondern gar keine.
>
> Gruß. Claus

Dann hör doch auf zu antworten ! Wo liegt denn das Problem? Aber
anscheinend kannst Du es einfach nicht lassen.

Mathias

Re: out of memory

Mathias Fiedler wrote:

> Schau mal ins Administratorhandbuch. Dort wird ziemlich ausführlich
> erklärt, an welchen "Schrauben" man drehen kann. Diese "Schrauben"
> solltest Du dann in my.cnf mal richtig "anziehen".
>
> Das nennst Du einen Hinweis?

Was Claus tut, weiß ich nicht, aber für mich ist es ein Hinweis. Ein
Hinweis, mal zu überprüfen, ob es vielleicht an sowas liegen könnte.
Wenn ich mich richtig erinnere, kam dieser Hinweis relativ früh. Daß er
nicht das gewünschte Ergebnis brachte, brauchst Du niemandem
vorzuwerfen, weil es eben nur ein Hinweis war, woran es gelegen haben
könnte.


> Auch ohne Schrauben drehen und der Hilfe
> von Michael, habe ich den fehler gefunden. Es liegt an der Art
> Indexierung. Es muß ein Index über mehrere Spalten sein und nicht ein
> Index für jede Spalte.

Na dann ist ja gut.


> Noch etwas hinterher. Nicht jedem ist es
> (serverbedingt) möglich, an der my.cnf zu schrauben. aber auch diese
> Scripte müssen funktionieren.

Ja, aber in diesem Fall sollte man entweder davon ausgehen können, daß
der Server richtig konfiguriert wurde - oder daß er kaputt ist und sein
Admin getreten werden müßte.


> [Es gab keine Hinweise]
>
> Genau. Nutze EXPLAIN, habe ich gemacht, keiner will das File lesen.

Ist normal. Der Hinweis, es als plaintext hier reinzuschreiben, mit \G,
war da (wenn auch spät); da gibt es keinen Grund, daß Du das jetzt
nochmal anführst.


Daß der Dialog, der verkürzt so ablief:

"Ich kann und will das File nicht öffnen. Bitte stell es in plaintext
rein". - "Ich kann die Datei lesen, also bist Du zu doof dafür, ich hab
die Info bereitgestellt, also habt ihr mir gefälligst zu helfen"

nicht gerade die Hilfsbereitschaft erhöht, sollte Dir hoffentlich klar
sein.

Kleiner Tip: Besser wäre gewesen:

"Ich kann und will das File nicht öffnen. Bitte stell es in plaintext
rein". - "Wie kann ich das tun, ohne da mir die Tabellenstruktur
zerfleddert wird?" - "Mit \G statt ; am Schluß." -> Explain-Ausgabe
posten, Hilfe möglich.


> Lies das Administratorhandbuch, toller Hinweis.

Natürlich. Zumindest die relevanten Stellen.

> Schraub an der my.cnf, ein noch tollerer Hinweis.

Es ist der naheliegendste neben Indexoptimierung, aber davon wolltest DU
ja erst auch nix hören.

> Bei mir kommt deranhang auch an.

Schön für Dich. Du solltest aber nicht immer von Dir auf andere
schließen.

Es gibt Newsserver, die grundsätzlich alle Binaries herausfiltern.


> Der einzige mit einem Hinweis auf Indexe über mehrere Spalten war
> Michael.

Auf Indexproblematik (daß Du vielleicht nicht die richtigen Indizes
hast), wurdest Du *sehr* frühzeitig hingewiesen, Deine Reaktion war
sinngemäß: "Seid ihr denn alle doof? Natürlich habe ich Indizes, ich bin
ja nicht bekloppt."

Du solltest vielleicht mal versuchen, Ratschläge als solche aufzufassen
und nicht als Beleidigung.


> Wieder die Frage, welcher Hinweis? Das Administrator Handbuch lesen?
> Mal so eben schnell in zwei, drei Tagen? Danke !

In der Zeit kann man sich durchaus einen Überblick verschaffen, was da so
steht. Passagen, die man für das gegebene Problem als irrelevant
erkennen kann, kann man dabei ja überlesen...


> Dann hör doch auf zu antworten ! Wo liegt denn das Problem? Aber
> anscheinend kannst Du es einfach nicht lassen.

Warum fragst Du, wenn Du keine Antworten willst?


Thomas
--
Du verwexelst da was: Chinin ist das, was den Lemon bitter macht. Das,
was die BigMäcs und den Chefsalate so schön knackig macht, heißt Chitin.
Hartmut Lehmann in de.alt.folklore.urban-legends

Re: out of memory

Am Mon, 02 Oct 2006 08:12:14 +0200 schrieb Kristian Köhntopp:

> Thomas Rachel wrote:
>> Generell eine gute Idee, alle verwendeten Komponenten zu überprüfenm, ob
>> sie nicht schuld sein können. Aber "#1037 - Out of memory; restart
>> server and try again (needed 65528 bytes) " dürfte wohl vom MySQL-Server
>> kommen. Und daß der Speicherprobleme bei PHP erkennen kann, bezweifele
>> ich...
>
> less sql/share/errmsg.txt
> /needed
>
> ER_OUTOFMEMORY HY001 S1001
> ...
> eng "Out of memory; restart server and try again (needed %d bytes)"
> ...
>
> Die Meldung kommt im Source an mehreren Stellen vor, insbesondere in
> sql_select.cc und in filesort.cc.
>
> In sql_select.cc kann die Meldung nur nach einem Aufruf von copy_blobs()
> auftreten.
>
> In filesort.cc tritt die Meldung auf, wenn min_sort_memory erschöpft ist:
>
> min_sort_memory= max(MIN_SORT_MEMORY, param.sort_length*MERGEBUFF2);
> while (memavl >= min_sort_memory)
> {
> ulong old_memavl;
> ulong keys= memavl/(param.rec_length+sizeof(char*));
> param.keys=(uint) min(records+1, keys);
> if ((sort_keys= (uchar **) make_char_array(param.keys, param.rec_length,
> MYF(0))))
> break;
> old_memavl=memavl;
> if ((memavl=memavl/4*3) < min_sort_memory && old_memavl >
> min_sort_memory)
> memavl= min_sort_memory;
> }
> if (memavl < min_sort_memory)
> {
> my_error(ER_OUTOFMEMORY,MYF(ME_ERROR+ME_WAITTANG),
> thd->variables.sortbuff_size);
> goto err;
> }
> ...

Und was genau bedeutet das nun für mich? Ich habe den out of memory Fehler
bis auf eine einzige Tabelle eingegrenzt. Für mich erstaunlich, das es
einer der kleinsten mit dem geringsten Datenaufkommen ist. Ich habe dort 4
Felder, denen ich einzeln einen Index gegeben habe. Es sind alles
varchar(255) Felder Kollation utf8_bin. Sobald ich in der Order By Klausel
alle 4 unterbringe, Reihenfolge ist dabei egeal, steigt der mysql Server
aus. Ein Index über alle 4 Felder erschien mir nach den Hinweisen aus der
NG dann als die Lösung. Aber da hatte ich mich wohl zu früh gefreut. Bei
dieser Tabelle ist es nicht möglich 4 Felder zu indexieren. Denn da erhalte
ich die Meldung:
#1071 - Specified key was too long; max key length is 1000 bytes

Der Fehler kommt auch schon bei dem Versuch, den Index nur über 2 Spalten
zu legen. Bei einer Teststabelle hatte ich den Index auch über 6 Felder
legen können. Woran das nun liegen kann, wird mir einfach nicht klar. Auch
die Angabe der Indexgröße in phpMyAdmin bringt keine Änderung. Wie kann es
sein, das eine Tabelle bei der Abfrage den Fehler verursacht eine andere,
wesentlich umfangreichere, aber nicht?

mfg

Mathias

Re: out of memory

Mathias Fiedler wrote:
> Ich habe dort 4
> Felder, denen ich einzeln einen Index gegeben habe. Es sind alles
> varchar(255) Felder Kollation utf8_bin.

Nur ein Index pro Table wird verwendet. Wenn außerdem noch eine Bedingung
existiert, wird der Index bevorzug für die Bedingung und nicht für die
Sortierung verwendet.

> Sobald ich in der Order By Klausel
> alle 4 unterbringe, Reihenfolge ist dabei egeal, steigt der mysql Server
> aus.

Dein Problem ist unmöglich zu analysieren, solange Du uns nicht die
folgenden Dinge hier lieferst:

1. SHOW CREATE TABLE ...\G

für alle beteiligten Tabellen.

2. SHOW TABLE STATUS LIKE "..."\G

für alle beteiligten Tabellen.

3. Den genauen Wortlaut der Query.

4. EXPLAIN ...\G für den genauen Wortlaut der Query.

> Ein Index über alle 4 Felder erschien mir nach den Hinweisen aus der
> NG dann als die Lösung. Aber da hatte ich mich wohl zu früh gefreut. Bei
> dieser Tabelle ist es nicht möglich 4 Felder zu indexieren. Denn da
> erhalte ich die Meldung:
> #1071 - Specified key was too long; max key length is 1000 bytes

Deine Tabelle verwendet offenbar utf8 auf den zu indizierenden Spalten.
Siehe dazu auch
http://blog.koehntopp.de/archives/1424-MySQL-Zeichensatz-Gru ndlagen.html in
meinem Blog: Ein Index auf eine utf8-Spalte verbraucht 3 Byte pro zu
indizierendes Zeichen. Du erschöpfst also mit 343 Zeichen insgesamt den
Speicher für einen Index: 255 utf8-Zeichen verbrauchen 765 Byte (von 1024
möglichen Byte im Index).

> Der Fehler kommt auch schon bei dem Versuch, den Index nur über 2 Spalten
> zu legen. Bei einer Teststabelle hatte ich den Index auch über 6 Felder
> legen können.

Das waren kleinere Felder oder Du hast dort nicht utf8 verwendet.


Du kannst übrigens versuchen, vor der Query sort_buffer_size zu erhöhen und
nach der Query wieder auf den Originalwert zurück zu setzen. Unter
Umständen funktioniert die Query dann (sie wird aber immer noch keinen
Index verwenden).

root@localhost [kris]> set @a=@@session.sort_buffer_size;
Query OK, 0 rows affected (0.00 sec)

root@localhost [kris]> set @@session.sort_buffer_size=256*1024;
Query OK, 0 rows affected (0.00 sec)

root@localhost [kris]> -- select ... Deine Query ...

root@localhost [kris]> set @@session.sort_buffer_size = @a;
Query OK, 0 rows affected (0.00 sec)

Kris

Re: out of memory

Mathias Fiedler wrote:
> Am Mon, 02 Oct 2006 08:12:14 +0200 schrieb Kristian Köhntopp:
>
>> ER_OUTOFMEMORY HY001 S1001
>> ...
>> eng "Out of memory; restart server and try again (needed %d bytes)"
>> ...
>> In filesort.cc tritt die Meldung auf, wenn min_sort_memory erschöpft ist:

> Und was genau bedeutet das nun für mich? Ich habe den out of memory Fehler
> bis auf eine einzige Tabelle eingegrenzt. Für mich erstaunlich, das es

Daran ist nichts erstaunlich.

> einer der kleinsten mit dem geringsten Datenaufkommen ist. Ich habe dort 4
> Felder, denen ich einzeln einen Index gegeben habe. Es sind alles
> varchar(255) Felder Kollation utf8_bin. Sobald ich in der Order By Klausel
> alle 4 unterbringe, Reihenfolge ist dabei egeal, steigt der mysql Server
> aus.

Jede dieser Spalten benötigt 255*3+1 Bytes. Mit den 4 Spalten also ca.
3KB *pro* *Zeile* im JOIN-Zwischenergebnis. Wenn dein JOIN zwischen-
zeitlich mal 1000 Zeilen generiert, sind das 3MB, bei 1Mio Zeilen 3GB.

Ein schlechter Query-Plan, z.B. wegen unzureichender/unpassender Indexe
kann also leicht zum GAU führen.


XL

Re: out of memory

Mathias Fiedler schrieb:
> [...]
>
> Ich habe dort 4
> Felder, denen ich einzeln einen Index gegeben habe. Es sind alles
> varchar(255) Felder Kollation utf8_bin. Sobald ich in der Order By Klausel
> alle 4 unterbringe, Reihenfolge ist dabei egeal, steigt der mysql Server
> aus. Ein Index über alle 4 Felder erschien mir nach den Hinweisen aus der
> NG dann als die Lösung. Aber da hatte ich mich wohl zu früh gefreut. Bei
> dieser Tabelle ist es nicht möglich 4 Felder zu indexieren. Denn da erhalte
> ich die Meldung:
> #1071 - Specified key was too long; max key length is 1000 bytes

Hoppla,
der Tipp kam von mir. Normalerweise arbeite ich mit Oracle und das
hat (nicht nur) an der Stelle deutlich mehr Pulver auf der Pfanne.
Um die Breiet eine Index muss man sich da erst deutlich später Gedanken
machen. Jetzt müsstest Du prüfen, ob man diese 1000 irgendwie vergrößern
kann, wobei ich aber fast befürchte, dass das nicht geht.

Oder Du reduzierst die Breite des Index: Ist es wirklich nötig, die
Spalten alle varchar225 zu machen? Das ist für Referenzen in meinen
Augen reichlich breit. Dazu müsste man aber wissen, was da wirlich so
drin steht. Spasseshalber könntest Du ja mal ein
select max(length()) from für diese 4 Spalten laufen
lassen. Oder Du kannst aufgrund des fachlichen Indhalts eine Aussage machen.

Das zweite, was Du Dir überlegen solltest ist, ob die Spalten wirklich
utf8_bin codiert sein müssen. Besonders, wenn dasdurch der Platzbedarf
im Index gegenüber einer "Standardcodierung" vergrößert wird.

Für mich sieht die ganze Spaltendefinition sehr nach Default aus, oder
hast Du Dir wirklich überlegt, was Du an der Stelle (oder vielmehr an
der Stelle, auf die der Foreign-Key zeigt, wirklich brauchst. Nach
meinen bisherigen Erfahrungen mit Dir liegt der Verdacht nah, dass es da
noch etwas Optimierungspotential geben könnte. ;-)

Und bitte jetzt nicht - "Mein Auftraggeber hat das so vorgegeben, daran
ist nichts zu drehen."

Tatsache ist nämlich, das in den meisten Fällen, mit denen ich so zu tun
habe, einfach Indexe nichts bringen. Ich brauche sehr oft
zusammengesetzte, besonders, wenn die Abfrage etwas komplexer werden.

Denk nochmal drüber nach....

Michael

Re: out of memory

Hallo,
hier die gewünschten daten.

soviel zur Tabellenstruktur:

-- --------------------------------------------------------

--
-- Tabellenstruktur für Tabelle `basic_informations`
--

CREATE TABLE IF NOT EXISTS `basic_informations` (
`ID_basic` int(4) NOT NULL auto_increment,
`ID_hg` int(4) NOT NULL default '0',
`ID_land` int(4) NOT NULL default '0',
`ID_label` int(4) NOT NULL default '0',
`ID_info` int(4) NOT NULL default '0',
`ID_images` int(4) NOT NULL default '0',
`ID_desc` int(4) NOT NULL default '5',
`ID_inch` int(4) NOT NULL default '4',
`ID_speed` int(4) NOT NULL default '3',
`releaseDate` mediumtext collate utf8_bin NOT NULL,
`name` varchar(255) collate utf8_bin NOT NULL default '',
`picture_disc` tinyint(1) NOT NULL default '0',
`presskit` tinyint(1) NOT NULL default '0',
`ID_press` int(4) NOT NULL default '0',
`promo` tinyint(1) NOT NULL default '0',
`ID_reference` int(4) NOT NULL default '0',
`2_disc` int(2) NOT NULL default '1',
`ID_desc2` int(4) NOT NULL default '5',
`ID_inch2` int(4) NOT NULL default '4',
`ID_speed2` int(4) NOT NULL default '3',
`picture_disc2` tinyint(4) NOT NULL default '0',
`bandname` varchar(255) collate utf8_bin NOT NULL default '',
`ID_desc3` int(4) NOT NULL default '5',
`ID_inch3` int(4) NOT NULL default '4',
`ID_speed3` int(4) NOT NULL default '3',
`ID_desc4` int(4) NOT NULL default '5',
`ID_inch4` int(4) NOT NULL default '4',
`ID_speed4` int(4) NOT NULL default '3',
`picture_disc3` tinyint(1) NOT NULL default '0',
`picture_disc4` tinyint(1) NOT NULL default '0',
`dateOriginal` date NOT NULL default '0000-00-00',
`charge` int(6) NOT NULL default '1000',
`name_alternative` varchar(255) collate utf8_bin NOT NULL default '',
`show_alternative` tinyint(1) NOT NULL default '0',
`prefix` varchar(5) collate utf8_bin NOT NULL default '0##_',
`alternative_date` varchar(4) collate utf8_bin NOT NULL default '0',
`no_detail` tinyint(1) NOT NULL default '0',
PRIMARY KEY (`ID_basic`),
KEY `ID_hg` (`ID_hg`),
KEY `ID_land` (`ID_land`),
KEY `ID_label` (`ID_label`),
KEY `ID_info` (`ID_info`),
KEY `ID_images` (`ID_images`),
KEY `ID_desc` (`ID_desc`),
KEY `ID_inch` (`ID_inch`),
KEY `ID_speed` (`ID_speed`),
KEY `ID_reference` (`ID_reference`),
KEY `bandname` (`bandname`),
KEY `charge` (`charge`),
KEY `dateOriginal` (`dateOriginal`),
KEY `alternative_date` (`alternative_date`)
) ENGINE=MyISAM AUTO_INCREMENT=641 DEFAULT CHARSET=utf8 COLLATE=utf8_bin
COMMENT='Haupttabelle' AUTO_INCREMENT=641 ;

-- --------------------------------------------------------

--
-- Tabellenstruktur für Tabelle `images`
--

CREATE TABLE IF NOT EXISTS `images` (
`ID_image` int(4) NOT NULL auto_increment,
`ID_basic` int(4) NOT NULL default '0',
`cover_bild1` varchar(255) collate utf8_bin NOT NULL default '0',
`cover_bild2` varchar(255) collate utf8_bin NOT NULL default '0',
`cover_bild3` varchar(255) collate utf8_bin NOT NULL default '0',
`cover_bild4` varchar(255) collate utf8_bin NOT NULL default '0',
`cover_bild5` varchar(255) collate utf8_bin NOT NULL default '0',
`cover_bild6` varchar(255) collate utf8_bin NOT NULL default '0',
`cover_bild7` varchar(255) collate utf8_bin NOT NULL default '0',
`cover_bild8` varchar(255) collate utf8_bin NOT NULL default '0',
`innen_cover_bild1` varchar(255) collate utf8_bin NOT NULL default '0',
`innen_cover_bild2` varchar(255) collate utf8_bin NOT NULL default '0',
`innen_cover_bild3` varchar(255) collate utf8_bin NOT NULL default '0',
`innen_cover_bild4` varchar(255) collate utf8_bin NOT NULL default '0',
`innen_cover_bild5` varchar(255) collate utf8_bin NOT NULL default '0',
`innen_cover_bild6` varchar(255) collate utf8_bin NOT NULL default '0',
`innen_cover_bild7` varchar(255) collate utf8_bin NOT NULL default '0',
`innen_cover_bild8` varchar(255) collate utf8_bin NOT NULL default '0',
`innen1` varchar(255) collate utf8_bin NOT NULL default '0',
`innen2` varchar(255) collate utf8_bin NOT NULL default '0',
`innen3` varchar(255) collate utf8_bin NOT NULL default '0',
`innen4` varchar(255) collate utf8_bin NOT NULL default '0',
`innen5` varchar(255) collate utf8_bin NOT NULL default '0',
`innen6` varchar(255) collate utf8_bin NOT NULL default '0',
`innen7` varchar(255) collate utf8_bin NOT NULL default '0',
`innen8` varchar(255) collate utf8_bin NOT NULL default '0',
`cover_bild1_thumb` varchar(255) collate utf8_bin NOT NULL default '0',
`cover_bild2_thumb` varchar(255) collate utf8_bin NOT NULL default '0',
`cover_bild3_thumb` varchar(255) collate utf8_bin NOT NULL default '0',
`cover_bild4_thumb` varchar(255) collate utf8_bin NOT NULL default '0',
`cover_bild5_thumb` varchar(255) collate utf8_bin NOT NULL default '0',
`cover_bild6_thumb` varchar(255) collate utf8_bin NOT NULL default '0',
`cover_bild7_thumb` varchar(255) collate utf8_bin NOT NULL default '0',
`cover_bild8_thumb` varchar(255) collate utf8_bin NOT NULL default '0',
`innen_cover_bild1_thumb` varchar(255) collate utf8_bin NOT NULL default
'0',
`innen_cover_bild2_thumb` varchar(255) collate utf8_bin NOT NULL default
'0',
`innen_cover_bild3_thumb` varchar(255) collate utf8_bin NOT NULL default
'0',
`innen_cover_bild4_thumb` varchar(255) collate utf8_bin NOT NULL default
'0',
`innen_cover_bild5_thumb` varchar(255) collate utf8_bin NOT NULL default
'0',
`innen_cover_bild6_thumb` varchar(255) collate utf8_bin NOT NULL default
'0',
`innen_cover_bild7_thumb` varchar(255) collate utf8_bin NOT NULL default
'0',
`innen_cover_bild8_thumb` varchar(255) collate utf8_bin NOT NULL default
'0',
`innen1_thumb` varchar(255) collate utf8_bin NOT NULL default '0',
`innen2_thumb` varchar(255) collate utf8_bin NOT NULL default '0',
`innen3_thumb` varchar(255) collate utf8_bin NOT NULL default '0',
`innen4_thumb` varchar(255) collate utf8_bin NOT NULL default '0',
`innen5_thumb` varchar(255) collate utf8_bin NOT NULL default '0',
`innen6_thumb` varchar(255) collate utf8_bin NOT NULL default '0',
`innen7_thumb` varchar(255) collate utf8_bin NOT NULL default '0',
`innen8_thumb` varchar(255) collate utf8_bin NOT NULL default '0',
PRIMARY KEY (`ID_image`)
) ENGINE=MyISAM AUTO_INCREMENT=386 DEFAULT CHARSET=utf8 COLLATE=utf8_bin
AUTO_INCREMENT=386 ;

-- --------------------------------------------------------

--
-- Tabellenstruktur für Tabelle `inches`
--

CREATE TABLE IF NOT EXISTS `inches` (
`ID_inch` int(4) NOT NULL auto_increment,
`inches` varchar(5) collate utf8_bin NOT NULL default 'KA',
PRIMARY KEY (`ID_inch`)
) ENGINE=MyISAM AUTO_INCREMENT=5 DEFAULT CHARSET=utf8 COLLATE=utf8_bin
COMMENT='Inches' AUTO_INCREMENT=5 ;

-- --------------------------------------------------------

--
-- Tabellenstruktur für Tabelle `land`
--

CREATE TABLE IF NOT EXISTS `land` (
`ID_land` int(4) NOT NULL auto_increment,
`land` varchar(255) collate utf8_bin NOT NULL default '',
PRIMARY KEY (`ID_land`)
) ENGINE=MyISAM AUTO_INCREMENT=26 DEFAULT CHARSET=utf8 COLLATE=utf8_bin
COMMENT='Länder' AUTO_INCREMENT=26 ;

-- --------------------------------------------------------

--
-- Tabellenstruktur für Tabelle `presskit`
--

CREATE TABLE IF NOT EXISTS `presskit` (
`ID_press` int(4) NOT NULL auto_increment,
`ID_basic` int(4) NOT NULL default '0',
`bild1` varchar(255) collate utf8_bin NOT NULL default '',
`bild2` varchar(255) collate utf8_bin NOT NULL default '',
`bild3` varchar(255) collate utf8_bin NOT NULL default '',
`bild4` varchar(255) collate utf8_bin NOT NULL default '',
`bild5` varchar(255) collate utf8_bin NOT NULL default '',
`bild6` varchar(255) collate utf8_bin NOT NULL default '',
`bild7` varchar(255) collate utf8_bin NOT NULL default '',
`bild8` varchar(255) collate utf8_bin NOT NULL default '',
`bild1_thumb` varchar(255) collate utf8_bin NOT NULL default '0',
`bild2_thumb` varchar(255) collate utf8_bin NOT NULL default '0',
`bild3_thumb` varchar(255) collate utf8_bin NOT NULL default '0',
`bild4_thumb` varchar(255) collate utf8_bin NOT NULL default '0',
`bild5_thumb` varchar(255) collate utf8_bin NOT NULL default '0',
`bild6_thumb` varchar(255) collate utf8_bin NOT NULL default '0',
`bild7_thumb` varchar(255) collate utf8_bin NOT NULL default '0',
`bild8_thumb` varchar(255) collate utf8_bin NOT NULL default '0',
PRIMARY KEY (`ID_press`)
) ENGINE=MyISAM AUTO_INCREMENT=392 DEFAULT CHARSET=utf8 COLLATE=utf8_bin
AUTO_INCREMENT=392 ;

-- --------------------------------------------------------

--
-- Tabellenstruktur für Tabelle `reference_nb`
--

CREATE TABLE IF NOT EXISTS `reference_nb` (
`ID_reference` int(4) NOT NULL auto_increment,
`ID_basic` int(4) NOT NULL default '0',
`ref1` varchar(255) collate utf8_bin NOT NULL default '0',
`ref2` varchar(255) collate utf8_bin NOT NULL default '0',
`ref3` varchar(255) collate utf8_bin NOT NULL default '0',
`ref4` varchar(255) collate utf8_bin NOT NULL default '0',
PRIMARY KEY (`ID_reference`),
KEY `ref1` (`ref1`)
) ENGINE=MyISAM AUTO_INCREMENT=489 DEFAULT CHARSET=utf8 COLLATE=utf8_bin
COMMENT='Referenznummern' AUTO_INCREMENT=489 ;

Der Status

mysql> SHOW TABLE STATUS LIKE "basic_informations" \G
*************************** 1. row ***************************
Name: basic_informations
Engine: MyISAM
Version: 10
Row_format: Dynamic
Rows: 374
Avg_row_length: 158
Data_length: 59220
Max_data_length: 281474976710655
Index_length: 71680
Data_free: 0
Auto_increment: 641
Create_time: 2006-10-03 10:33:53
Update_time: 2006-10-03 10:33:53
Check_time: 2006-10-03 10:33:53
Collation: utf8_bin
Checksum: NULL
Create_options:
Comment: Haupttabelle
1 row in set (0.00 sec)

mysql> SHOW TABLE STATUS LIKE "images" \G
*************************** 1. row ***************************
Name: images
Engine: MyISAM
Version: 10
Row_format: Dynamic
Rows: 327
Avg_row_length: 310
Data_length: 101404
Max_data_length: 281474976710655
Index_length: 7168
Data_free: 0
Auto_increment: 386
Create_time: 2006-10-03 10:35:12
Update_time: 2006-10-03 10:35:12
Check_time: NULL
Collation: utf8_bin
Checksum: NULL
Create_options:
Comment:
1 row in set (0.00 sec)

mysql> SHOW TABLE STATUS LIKE "inches" \G
*************************** 1. row ***************************
Name: inches
Engine: MyISAM
Version: 10
Row_format: Dynamic
Rows: 4
Avg_row_length: 20
Data_length: 80
Max_data_length: 281474976710655
Index_length: 2048
Data_free: 0
Auto_increment: 5
Create_time: 2006-10-03 10:35:05
Update_time: 2006-10-03 10:35:05
Check_time: NULL
Collation: utf8_bin
Checksum: NULL
Create_options:
Comment: Inches
1 row in set (0.00 sec)

mysql> SHOW TABLE STATUS LIKE "land" \G
*************************** 1. row ***************************
Name: land
Engine: MyISAM
Version: 10
Row_format: Dynamic
Rows: 25
Avg_row_length: 20
Data_length: 504
Max_data_length: 281474976710655
Index_length: 2048
Data_free: 0
Auto_increment: 26
Create_time: 2006-10-01 10:41:22
Update_time: 2006-10-01 10:41:22
Check_time: NULL
Collation: utf8_bin
Checksum: NULL
Create_options:
Comment: Lõnder
1 row in set (0.02 sec)


mysql> SHOW TABLE STATUS LIKE "reference_nb" \G
*************************** 1. row ***************************
Name: reference_nb
Engine: MyISAM
Version: 10
Row_format: Dynamic
Rows: 430
Avg_row_length: 32
Data_length: 13904
Max_data_length: 281474976710655
Index_length: 20480
Data_free: 0
Auto_increment: 489
Create_time: 2006-10-03 10:35:55
Update_time: 2006-10-03 10:35:55
Check_time: 2006-10-03 10:35:55
Collation: utf8_bin
Checksum: NULL
Create_options:
Comment: Referenznummern
1 row in set (0.00 sec)

Das Query

SELECT bi.ID_basic, la.land, i.cover_bild1_thumb, bi.releaseDate,
bi.dateOriginal, bi.name, re.ref1, re.ref2,re.ref3, re.ref4, bi.charge,
bi.name_alternative, bi.show_alternative, inc.inches, bi.prefix,
bi.alternative_date, bi.no_detail FROM basic_informations AS bi INNER JOIN
images AS i ON bi.ID_images = i.ID_image INNER JOIN land AS la ON
bi.ID_land = la.ID_land INNER JOIN reference_nb AS re ON bi.ID_reference =
re.ID_reference INNER JOIN inches As inc ON bi.ID_inch = inc.ID_inch WHERE
(bi.id_hg = 1 AND bi.presskit = 0) ORDER BY bi.dateOriginal, bi.charge,
bi.name, re.ref1, re.ref2, re.ref3,ref4 inc.inches, la.land

Und nun noch das EXPLAIN

mysql> EXPLAIN SELECT bi.ID_basic, la.land, i.cover_bild1_thumb,
bi.releaseDate,
bi.dateOriginal, bi.name, re.ref1, re.ref2,re.ref3, re.ref4, bi.charge,
bi.name
_alternative, bi.show_alternative, inc.inches, bi.prefix,
bi.alternative_date, b
i.no_detail FROM basic_informations AS bi INNER JOIN images AS i ON
bi.ID_images
= i.ID_image INNER JOIN land AS la ON bi.ID_land = la.ID_land INNER JOIN
refere
nce_nb AS re ON bi.ID_reference = re.ID_reference INNER JOIN inches As inc
ON bi
..ID_inch = inc.ID_inch WHERE (bi.id_hg = 1 AND bi.presskit = 0) ORDER BY
bi.date
Original, bi.charge, bi.name, re.ref1, re.ref2, re.ref3,ref4, inc.inches,
la.lan
d
-> \G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: i
type: ALL
possible_keys: PRIMARY
key: NULL
key_len: NULL
ref: NULL
rows: 327
Extra: Using temporary; Using filesort
*************************** 2. row ***************************
id: 1
select_type: SIMPLE
table: bi
type: ref
possible_keys: ID_hg,ID_land,ID_images,ID_inch,ID_reference
key: ID_images
key_len: 4
ref: db122679377.i.ID_image
rows: 1
Extra: Using where
*************************** 3. row ***************************
id: 1
select_type: SIMPLE
table: inc
type: eq_ref
possible_keys: PRIMARY
key: PRIMARY
key_len: 4
ref: db122679377.bi.ID_inch
rows: 1
Extra:
*************************** 4. row ***************************
id: 1
select_type: SIMPLE
table: la
type: eq_ref
possible_keys: PRIMARY
key: PRIMARY
key_len: 4
ref: db122679377.bi.ID_land
rows: 1
Extra:
*************************** 5. row ***************************
id: 1
select_type: SIMPLE
table: re
type: eq_ref
possible_keys: PRIMARY
key: PRIMARY
key_len: 4
ref: db122679377.bi.ID_reference
rows: 1
Extra:
5 rows in set (0.00 sec)

Also auch auf die Gefahr hin, das man mich wieder als unwissenden Idioten
hinstellt, muß ich noch einmal darauf hinweisen, das ich mysql zwar
verwende aber eben kein Experte bin. Mit dem obigen kann ich leider so gut
wie gar nichts anfangen. Ich hoffe, Du kannst diese Angaben in
verständliche Worte packen und mir einen Tip zur Beseitigung des
Speicherfehlers geben.

mfg

Mathias

Re: out of memory

Am Tue, 03 Oct 2006 17:42:14 +0200 schrieb Michael König:

> Oder Du reduzierst die Breite des Index: Ist es wirklich nötig, die
> Spalten alle varchar225 zu machen? Das ist für Referenzen in meinen
> Augen reichlich breit. Dazu müsste man aber wissen, was da wirlich so
> drin steht. Spasseshalber könntest Du ja mal ein
> select max(length()) from für diese 4 Spalten laufen
> lassen. Oder Du kannst aufgrund des fachlichen Indhalts eine Aussage machen.
>
Mit diesem Hinweis konnte ich den Platz auf varchar(80) verringern. Nun
läßt sich auch ein Index über 4 Spalten setzen. Allerdings ändert das auch
nichts daran, das der Server bei der Select Abfrage aussteigt.

> Das zweite, was Du Dir überlegen solltest ist, ob die Spalten wirklich
> utf8_bin codiert sein müssen. Besonders, wenn dasdurch der Platzbedarf
> im Index gegenüber einer "Standardcodierung" vergrößert wird.

Da möchte ich jetzt wirklich nicht darüber diskutieren. Diese Sache ist
wirklich für einen Kunden und der nervt mich schon genug. UTF8 Ist nötig,
da in den Tabellen verschiedene Sprachen (deutsch, englisch, grieschisch
und japanisch) vorkommen. Die Einheitlichkeit von utf8 ist da schon gut.
Natürlich könnte die die DB auch eine andere Kollation haben. Da die
gesamte utf8 Kodierung ja schon über das Charset in php geregelt wird. In
diesem Fall will der Auftraggeber das aber so. Und er soll es haben. Auch
wenn ich damit das Problem nicht löse, aber eine Sortierung über 3 Spalten
reicht auch aus und die Anwendung funktioniert. Im Zweifelsfall ist mir das
wichtiger als die Ursache.

mfg

Mathias

Re: out of memory

Mathias Fiedler wrote:

> soviel zur Tabellenstruktur:

Ich mach jetzt mal den Celko:

Dein Datenmodell ist krank, wie kann man sowas verbrechen?

`releaseDate` mediumtext collate utf8_bin NOT NULL,

`alternative_date` varchar(4) collate utf8_bin NOT NULL default '0',

Und fast der ganze Rest
varchar(255) collate utf8_bin NOT NULL default '0',

Hat sich denn keiner Gedanken über den *Inhalt* dieser Spalten gemacht?


Normalisierungsregeln sind auch scheinbar völlig unbekannt.

Oder die Tabelle "land", warum muss man sich sowas selber basteln?


Wäre ja alles kein Problem, aber du schreibst, du machst das für einen
Kunden. Wenn der dir so ein Datenmodell aufgedrückt hat, hättest du ihm
sagen sollen, dass das Unsinn ist. Mit dem Murks tust du ihm keinen
Gefallen (und dir auch nicht). Aber falls du das gemacht hast, dann kann
einem der Kunde leid tun.

Dieter

Re: out of memory

Am Tue, 03 Oct 2006 22:15:28 +0200 schrieb Dieter Noeth:

> Mathias Fiedler wrote:
>
>> soviel zur Tabellenstruktur:
>
> Ich mach jetzt mal den Celko:
>
> Dein Datenmodell ist krank, wie kann man sowas verbrechen?
>
> `releaseDate` mediumtext collate utf8_bin NOT NULL,
>
> `alternative_date` varchar(4) collate utf8_bin NOT NULL default '0',
>
> Und fast der ganze Rest
> varchar(255) collate utf8_bin NOT NULL default '0',
>
> Hat sich denn keiner Gedanken über den *Inhalt* dieser Spalten gemacht?
>
>
Doch! Deshalb sind die ja so. Was ist daran krank? Meckern kann jeder. Was
soll daran so gravierend falsch sein?

> Normalisierungsregeln sind auch scheinbar völlig unbekannt.
>
Nein! Du weist doch gar nichts über den Inhalt. Wie willst Du da eine
Normalisierung vornehmen?

> Oder die Tabelle "land", warum muss man sich sowas selber basteln?
>
Was gibts denn daran nun schon wieder auszusetzen?
>
> Wäre ja alles kein Problem, aber du schreibst, du machst das für einen
> Kunden. Wenn der dir so ein Datenmodell aufgedrückt hat, hättest du ihm
> sagen sollen, dass das Unsinn ist. Mit dem Murks tust du ihm keinen
> Gefallen (und dir auch nicht). Aber falls du das gemacht hast, dann kann
> einem der Kunde leid tun.
>
Ich freue mich über Deine aufmunternden Worte, aber auch Du fällst in den
selben Trott wie alle anderen. Meckern, meckern, meckern. Wo bleibt denn
mal ein konstruktiver Beitrag? Ein Hinweis auf Fehler oder noch besser ein
Hinweis darauf, wie es (Deiner Meinung nach) sein sollte.

mfg

Mathias

Re: out of memory

Mathias Fiedler wrote:
> Am Tue, 03 Oct 2006 22:15:28 +0200 schrieb Dieter Noeth:
>
>> Mathias Fiedler wrote:
>>
>>> soviel zur Tabellenstruktur:
>> Ich mach jetzt mal den Celko:
>>
>> Dein Datenmodell ist krank, wie kann man sowas verbrechen?
>>
>> `releaseDate` mediumtext collate utf8_bin NOT NULL,
>>
>> `alternative_date` varchar(4) collate utf8_bin NOT NULL default '0',
>>
>> Und fast der ganze Rest
>> varchar(255) collate utf8_bin NOT NULL default '0',
>>
>> Hat sich denn keiner Gedanken über den *Inhalt* dieser Spalten gemacht?
>>
>>
> Doch! Deshalb sind die ja so. Was ist daran krank? Meckern kann jeder. Was
> soll daran so gravierend falsch sein?

Seit wann speichert wann werden Datumsangaben als Text hinterlegt, noch
dazu als mediumtext?


>> Normalisierungsregeln sind auch scheinbar völlig unbekannt.
>>
> Nein! Du weist doch gar nichts über den Inhalt. Wie willst Du da eine
> Normalisierung vornehmen?

`cover_bild1` varchar(255) collate utf8_bin NOT NULL default '0',
`cover_bild2` varchar(255) collate utf8_bin NOT NULL default '0',
`cover_bild3` varchar(255) collate utf8_bin NOT NULL default '0',
`cover_bild4` varchar(255) collate utf8_bin NOT NULL default '0',
`cover_bild5` varchar(255) collate utf8_bin NOT NULL default '0',
`cover_bild6` varchar(255) collate utf8_bin NOT NULL default '0',
`cover_bild7` varchar(255) collate utf8_bin NOT NULL default '0',
`cover_bild8` varchar(255) collate utf8_bin NOT NULL default '0',

Naja, wenn du das normalisiert nennst... Was machst du eigentlich wenn
noch ein Bild dazu kommt? Tabellenstruktur umschreiben?

[...]

Stefan

Re: out of memory

Mathias Fiedler wrote:

>> `releaseDate` mediumtext collate utf8_bin NOT NULL,
>>
>> `alternative_date` varchar(4) collate utf8_bin NOT NULL default '0',
>>
>> Und fast der ganze Rest
>> varchar(255) collate utf8_bin NOT NULL default '0',
>>
>> Hat sich denn keiner Gedanken über den *Inhalt* dieser Spalten gemacht?
>>
>>
> Doch! Deshalb sind die ja so.

Ein releaseDate ist ein mediumtext?
Ein alternative_date ein varchar(4)?

Wenn man irgendwas mit DATE liest, meint man irgendwas mit DATUM, und wo
ist hier irgendwas Datumähnliches?
Und wenn da kein Datum drinsteht, dann solltest du den Namen ändern.


Aus deiner Antwort an Micheal König:
"Mit diesem Hinweis konnte ich den Platz auf varchar(80) verringern."

Wat denn nu?
Entweder da müssen tatsächlich 255 Chars reinpassen und dann kannst du
die Definition nicht einfach auf CHAR(80) ändern oder es hat sich vorher
"keiner Gedanken über den *Inhalt* dieser Spalten gemacht" :-)

Sollen da irgendwelche Dateinamen mit Pfad gespeichert werden?
Dann viel Spass mit den UTF-8 Dateinamen.

> Was ist daran krank? Meckern kann jeder. Was
> soll daran so gravierend falsch sein?
>
>> Normalisierungsregeln sind auch scheinbar völlig unbekannt.
>>
> Nein! Du weist doch gar nichts über den Inhalt. Wie willst Du da eine
> Normalisierung vornehmen?

Wenn ich etwas lese von ID_inch1 bis ID_inch4 oder cover_bild1 bis
cover_bild8 dann ist das eine Repeating Group und das verletzt die erste
Normalform. Man kann vieles rechtfertigen, aber das nicht: Garantiert
kommt irgendwann mal die Anforderung nach einem 9. cover_bild und was dann?

Entweder du weisst nicht, wie man das löst oder du machst es nicht, weil
es dann "zuviele" Tabellen gibt...

>> Oder die Tabelle "land", warum muss man sich sowas selber basteln?
>>
> Was gibts denn daran nun schon wieder auszusetzen?

Es gibt eine deutsche/EU/ISO-Norm (ISO-3166-1) mit genau diesen Daten,
die gibt's sogar fertig für mysql. Warum soll ich 123 für Deutschland
nehmen, wenn jeder andere DE nimmt?

>> Wäre ja alles kein Problem, aber du schreibst, du machst das für einen
>> Kunden. Wenn der dir so ein Datenmodell aufgedrückt hat, hättest du ihm
>> sagen sollen, dass das Unsinn ist. Mit dem Murks tust du ihm keinen
>> Gefallen (und dir auch nicht). Aber falls du das gemacht hast, dann kann
>> einem der Kunde leid tun.
>>
> Ich freue mich über Deine aufmunternden Worte, aber auch Du fällst in den
> selben Trott wie alle anderen. Meckern, meckern, meckern. Wo bleibt denn
> mal ein konstruktiver Beitrag? Ein Hinweis auf Fehler oder noch besser ein
> Hinweis darauf, wie es (Deiner Meinung nach) sein sollte.

Hinweise s.o.
Warum soll ich deine Arbeit machen? Du machst das schließlich für einen
Kunden und nicht zum Spaß. Gib mir saubere Spezifikationen und bezahl
mir meinen Tagessatz von 1200€ und ich mach dir ein Angebot für ein
ordentliches Datenmodell. Kann aber etwas dauern, da ich seit vielen
Jahren mit Datenbanken mein Geld verdiene und die nächsten 10 Tage
erstmal für Lufthansa und Telekom arbeite. War das großkotzig genug von mir?

Mein Rat:
Lerne logische Datenmodellierung.
Mit einem schlechten Datenmodell zwingt man jedes DBMS in die Knie, mit
einem guten Modell geht das nur noch mit schlechtem SQL.
Und mit sowas ruinierst du dir deinen Ruf, zumindest in diesem Bereich
(damit meine ich nicht die NG, sondern bei deinen Kunden)

Dieter

Re: out of memory

Am Wed, 04 Oct 2006 09:17:11 +0200 schrieb Dieter Noeth:

> Mathias Fiedler wrote:
>
>>> `releaseDate` mediumtext collate utf8_bin NOT NULL,
>>>
>>> `alternative_date` varchar(4) collate utf8_bin NOT NULL default '0',
>>>
>>> Und fast der ganze Rest
>>> varchar(255) collate utf8_bin NOT NULL default '0',
>>>
>>> Hat sich denn keiner Gedanken über den *Inhalt* dieser Spalten gemacht?
>>>
>>>
>> Doch! Deshalb sind die ja so.
>
> Ein releaseDate ist ein mediumtext?
> Ein alternative_date ein varchar(4)?
>
> Wenn man irgendwas mit DATE liest, meint man irgendwas mit DATUM, und wo
> ist hier irgendwas Datumähnliches?
> Und wenn da kein Datum drinsteht, dann solltest du den Namen ändern.
>
Das ist genau das, was ich meine. Hier geht es um ein konkretes Problem,
von dem Du keinen blassen Schimmer hast. Aber Du willst mir vorschreiben,
wie ich die Spalten zu belegen habe. Es geht in der Tat um ein Datum. Diese
kann aber auch so 19??, oder so 1988, oder so 1988-10-?? oder so
1988-10-12, oder so November 1988 und auch noch ganz anders aussehen. Da
kommst Du mit einem date Feld nicht weit. Da es sich aber trotzdem eben um
das release Datum handelt, nenne ich das Feld releaseDate. Das ist absolut
in Ordnung. das alternativeDate hat nur 4 Stellen, kann aber auch 19??
heissen, deshalb varchar.
> Aus deiner Antwort an Micheal König:
> "Mit diesem Hinweis konnte ich den Platz auf varchar(80) verringern."
>
> Wat denn nu?
> Entweder da müssen tatsächlich 255 Chars reinpassen und dann kannst du
> die Definition nicht einfach auf CHAR(80) ändern oder es hat sich vorher
> "keiner Gedanken über den *Inhalt* dieser Spalten gemacht" :-)
>
Das ist schon wieder so eine Annahme. Ich habe ein varchar 255 Feld
genommen, weil der Wert auch mal so groß werden kann. Der Kunde konnte
keine bessere Angabe liefern. Die tatsächliche Größe lag bis jetzt
darunter. Deshalb war eine Reduzierung möglich. Ob das die endgültige
Lösung ist, steht noch nicht fest. Es ging doch nur darum, festzustellen ob
mit der Verringerung ein Index über mehrere Spalten möglich ist, was mit ja
beantwortet werden kann, aber nichts an dem Speicherfehler ändert.

> Sollen da irgendwelche Dateinamen mit Pfad gespeichert werden?
> Dann viel Spass mit den UTF-8 Dateinamen.
>
Nein, das geht es nur um Nummern - Buchstaben - Kombinationen
>> Was ist daran krank? Meckern kann jeder. Was
>> soll daran so gravierend falsch sein?
>>
>>> Normalisierungsregeln sind auch scheinbar völlig unbekannt.
>>>
>> Nein! Du weist doch gar nichts über den Inhalt. Wie willst Du da eine
>> Normalisierung vornehmen?
>
> Wenn ich etwas lese von ID_inch1 bis ID_inch4 oder cover_bild1 bis
> cover_bild8 dann ist das eine Repeating Group und das verletzt die erste
> Normalform. Man kann vieles rechtfertigen, aber das nicht: Garantiert
> kommt irgendwann mal die Anforderung nach einem 9. cover_bild und was dann?
>
Die kommt eben nicht! Genau ist deshalb ist die Tabelle ja so gestaltet.

> Entweder du weisst nicht, wie man das löst oder du machst es nicht, weil
> es dann "zuviele" Tabellen gibt...
>
Das ist eine Unterstellung und hat schon wieder nichts mit der
ursprünglichen Frage nach dem Speicherfehler zu tun.
>>> Oder die Tabelle "land", warum muss man sich sowas selber basteln?
>>>
>> Was gibts denn daran nun schon wieder auszusetzen?
>
> Es gibt eine deutsche/EU/ISO-Norm (ISO-3166-1) mit genau diesen Daten,
> die gibt's sogar fertig für mysql. Warum soll ich 123 für Deutschland
> nehmen, wenn jeder andere DE nimmt?
>
Weil ich das dort anders löse! Basta! Es ist mein Problem. Wenn die
Anwendung etwas erfordert, mache ich es so, das es funktioniert. Du hast
schon wieder keine Vorstellung vom Gesmtwerk aber willst alles verbesseren.
Wenn Du wenigstens etwas zum Thema hättest, aber wieder nur heisse Luft,
wie bei den meisten anderen auch.

>>> Wäre ja alles kein Problem, aber du schreibst, du machst das für einen
>>> Kunden. Wenn der dir so ein Datenmodell aufgedrückt hat, hättest du ihm
>>> sagen sollen, dass das Unsinn ist. Mit dem Murks tust du ihm keinen
>>> Gefallen (und dir auch nicht). Aber falls du das gemacht hast, dann kann
>>> einem der Kunde leid tun.
>>>
>> Ich freue mich über Deine aufmunternden Worte, aber auch Du fällst in den
>> selben Trott wie alle anderen. Meckern, meckern, meckern. Wo bleibt denn
>> mal ein konstruktiver Beitrag? Ein Hinweis auf Fehler oder noch besser ein
>> Hinweis darauf, wie es (Deiner Meinung nach) sein sollte.
>
> Hinweise s.o.
> Warum soll ich deine Arbeit machen? Du machst das schließlich für einen
> Kunden und nicht zum Spaß. Gib mir saubere Spezifikationen und bezahl
> mir meinen Tagessatz von 1200¤ und ich mach dir ein Angebot für ein
> ordentliches Datenmodell. Kann aber etwas dauern, da ich seit vielen
> Jahren mit Datenbanken mein Geld verdiene und die nächsten 10 Tage
> erstmal für Lufthansa und Telekom arbeite. War das großkotzig genug von mir?
>
Wenn Du nur mal jemanden brauchst über den Du Dich lustig machen kannst,
weil Du mehr weißt, mußt Du woanders suchen. Wende Dich mal vertrauensvoll
an einen Arzt. Und ja, es ist großkotzig genug. Wenn Du keine Antworten
parat hast, außer diesem Blödsinn, dann lass es lieber!

> Mein Rat:
> Lerne logische Datenmodellierung.
> Mit einem schlechten Datenmodell zwingt man jedes DBMS in die Knie, mit
> einem guten Modell geht das nur noch mit schlechtem SQL.

Mein Modell ist vielleicht nicht perfekt, aber nicht so schlecht, das der
DB Server aussteigen muß. Wenn es unter mysql4 problemlos läuft, meine
Abfrage nicht mal 0,5 sec braucht und unter mysql5 plötzlich gar nichts
mehr geht, dann muß es schon gravierende Änderungen gegeben haben. Darüber
könntest Du dich mal auslassen, das wäre dann wennigstens ein Beitrag zum
Thema.

> Und mit sowas ruinierst du dir deinen Ruf, zumindest in diesem Bereich
> (damit meine ich nicht die NG, sondern bei deinen Kunden)
>
Das lass mal meine Sorge sein.

Mathias

Re: out of memory

Am Wed, 04 Oct 2006 08:48:56 +0200 schrieb Weinzierl Stefan:

> Mathias Fiedler wrote:
>> Am Tue, 03 Oct 2006 22:15:28 +0200 schrieb Dieter Noeth:
>>
>>> Mathias Fiedler wrote:
>>>
>>>> soviel zur Tabellenstruktur:
>>> Ich mach jetzt mal den Celko:
>>>
>>> Dein Datenmodell ist krank, wie kann man sowas verbrechen?
>>>
>>> `releaseDate` mediumtext collate utf8_bin NOT NULL,
>>>
>>> `alternative_date` varchar(4) collate utf8_bin NOT NULL default '0',
>>>
>>> Und fast der ganze Rest
>>> varchar(255) collate utf8_bin NOT NULL default '0',
>>>
>>> Hat sich denn keiner Gedanken über den *Inhalt* dieser Spalten gemacht?
>>>
>>>
>> Doch! Deshalb sind die ja so. Was ist daran krank? Meckern kann jeder. Was
>> soll daran so gravierend falsch sein?
>
> Seit wann speichert wann werden Datumsangaben als Text hinterlegt, noch
> dazu als mediumtext?
>
Nochmal, was hat das mit der Frage zu tun? Nichts. Warum das so ist, habe
ich bereits Dieter geantwortet, kannst Du da nachlesen.
>
>>> Normalisierungsregeln sind auch scheinbar völlig unbekannt.
>>>
>> Nein! Du weist doch gar nichts über den Inhalt. Wie willst Du da eine
>> Normalisierung vornehmen?
>
> `cover_bild1` varchar(255) collate utf8_bin NOT NULL default '0',
> `cover_bild2` varchar(255) collate utf8_bin NOT NULL default '0',
> `cover_bild3` varchar(255) collate utf8_bin NOT NULL default '0',
> `cover_bild4` varchar(255) collate utf8_bin NOT NULL default '0',
> `cover_bild5` varchar(255) collate utf8_bin NOT NULL default '0',
> `cover_bild6` varchar(255) collate utf8_bin NOT NULL default '0',
> `cover_bild7` varchar(255) collate utf8_bin NOT NULL default '0',
> `cover_bild8` varchar(255) collate utf8_bin NOT NULL default '0',
>
> Naja, wenn du das normalisiert nennst... Was machst du eigentlich wenn
> noch ein Bild dazu kommt? Tabellenstruktur umschreiben?
>
Es kommt kein Bild mehr dazu ! Auch das hat sicherlich keine Auswirkungen
auf den Speicherbedarf meiner Abfrage. Also wieder einer, der sich nur gern
mal über andere ausläßt. Wo bleibt Dein Beitrag zum eigentlichen Problem?
Wenn Du es auch nicht weist, dann sie doch lieber ganz still !

mfg

Mathias

Re: out of memory

Mathias Fiedler wrote:

> Das ist genau das, was ich meine. Hier geht es um ein konkretes Problem,
> von dem Du keinen blassen Schimmer hast. Aber Du willst mir vorschreiben,
> wie ich die Spalten zu belegen habe. Es geht in der Tat um ein Datum. Diese
> kann aber auch so 19??, oder so 1988, oder so 1988-10-?? oder so
> 1988-10-12, oder so November 1988 und auch noch ganz anders aussehen. Da
> kommst Du mit einem date Feld nicht weit.

OK, da kommt also dann auch sowas wie:
"Das war so gegen Ende 2004, kann aber auch Anfang 2005 gewesen sein,
ne, wenn ich richtig überlege, doch im November 2004"
Und das ist dann noch die Kurzversion, wiel in Mediumtext passen ja noch
knapp 16MB weiterer Text.

> Da es sich aber trotzdem eben um
> das release Datum handelt, nenne ich das Feld releaseDate. Das ist absolut
> in Ordnung. das alternativeDate hat nur 4 Stellen, kann aber auch 19??
> heissen, deshalb varchar.

Oh, ich dachte inzwischen macht man alle Jahreszahlen 4-stellig, aber
ist ja noch hin bis 2100. Und ansonsten passt in VARCHAR(4) ja nicht
viel rein.

>> Entweder da müssen tatsächlich 255 Chars reinpassen und dann kannst du
>> die Definition nicht einfach auf CHAR(80) ändern oder es hat sich vorher
>> "keiner Gedanken über den *Inhalt* dieser Spalten gemacht" :-)
>>
> Das ist schon wieder so eine Annahme. Ich habe ein varchar 255 Feld
> genommen, weil der Wert auch mal so groß werden kann. Der Kunde konnte
> keine bessere Angabe liefern.

Dann sag dem Kunden, dass er keine Datenbank braucht, sondern Freitext,
sowas wie AskSam, dann braucht er gar keine Angaben.

>>>> Normalisierungsregeln sind auch scheinbar völlig unbekannt.
>>>>
>>> Nein! Du weist doch gar nichts über den Inhalt. Wie willst Du da eine
>>> Normalisierung vornehmen?
>> Wenn ich etwas lese von ID_inch1 bis ID_inch4 oder cover_bild1 bis
>> cover_bild8 dann ist das eine Repeating Group und das verletzt die erste
>> Normalform. Man kann vieles rechtfertigen, aber das nicht: Garantiert
>> kommt irgendwann mal die Anforderung nach einem 9. cover_bild und was dann?
>>
> Die kommt eben nicht!

Famous Last Words

> Weil ich das dort anders löse! Basta! Es ist mein Problem.

Du löst vieles anders.

> Wenn die
> Anwendung etwas erfordert, mache ich es so, das es funktioniert. Du hast
> schon wieder keine Vorstellung vom Gesmtwerk aber willst alles verbesseren.

Du solltest besser ünstler werden, da geht so ein Gesamtwerk vielleicht
durch.

> Wenn Du nur mal jemanden brauchst über den Du Dich lustig machen kannst,
> weil Du mehr weißt, mußt Du woanders suchen.

Suchen muss ich nicht mehr.
Du bist wirklich hoffnungslos lernresistent.

>> Mein Rat:
>> Lerne logische Datenmodellierung.
>> Mit einem schlechten Datenmodell zwingt man jedes DBMS in die Knie, mit
>> einem guten Modell geht das nur noch mit schlechtem SQL.
>
> Mein Modell ist vielleicht nicht perfekt, aber nicht so schlecht, das der
> DB Server aussteigen muß. Wenn es unter mysql4 problemlos läuft, meine
> Abfrage nicht mal 0,5 sec braucht und unter mysql5 plötzlich gar nichts
> mehr geht, dann muß es schon gravierende Änderungen gegeben haben.

Dein Modell enthält gerade mal ein paar Hundert Rows, da ist sogar
awk/grep auf Flatfile schnell.
Und jetzt sag nicht "Da kommen garantiert nicht mehr als xxxx Rows
rein", spätestens beim nächsten Mal geht's dann doch um 6-7-8-9-stellige
Zahlen.

>> Und mit sowas ruinierst du dir deinen Ruf, zumindest in diesem Bereich
>> (damit meine ich nicht die NG, sondern bei deinen Kunden)
>>
> Das lass mal meine Sorge sein.

Gerne doch.

Da sind übrigens absichtlich nirgendwo Smileys, ist nämlich nicht mehr
lustig. Für mich EOT.

Dieter

Re: out of memory

Am Wed, 04 Oct 2006 11:36:09 +0200 schrieb Dieter Noeth:

> Mathias Fiedler wrote:
>
>> Das ist genau das, was ich meine. Hier geht es um ein konkretes Problem,
>> von dem Du keinen blassen Schimmer hast. Aber Du willst mir vorschreiben,
>> wie ich die Spalten zu belegen habe. Es geht in der Tat um ein Datum. Diese
>> kann aber auch so 19??, oder so 1988, oder so 1988-10-?? oder so
>> 1988-10-12, oder so November 1988 und auch noch ganz anders aussehen. Da
>> kommst Du mit einem date Feld nicht weit.
>
> OK, da kommt also dann auch sowas wie:
> "Das war so gegen Ende 2004, kann aber auch Anfang 2005 gewesen sein,
> ne, wenn ich richtig überlege, doch im November 2004"
> Und das ist dann noch die Kurzversion, wiel in Mediumtext passen ja noch
> knapp 16MB weiterer Text.
>
Fast, es kann auch Anfang 200 heissen. Aber was hat das mit dem Problem zu
tun. Die Anwendung erfordert derasrtige Angaben. Außerdem kann ich nicht
erkenne, was daran zu dem Speicherfehler führen soll.

>
> Dann sag dem Kunden, dass er keine Datenbank braucht, sondern Freitext,
> sowas wie AskSam, dann braucht er gar keine Angaben.
>
Warum? Ich will nicht die Welt verbessern, sondern meinem Kunden ein
Programm liefern, welches da macht was er braucht. Und wenn er die Daten so
angibt, dann ist es eben so. Ganz egeal wie falsch Dir diese Angaben
erscheinen mögen, was hat das mit dem Speicherfehler zu tun?


>
> Famous Last Words
>
Ja.

>> Weil ich das dort anders löse! Basta! Es ist mein Problem.
>
> Du löst vieles anders.
Sicherlich. Sonst würde ja alles gleich aussehen. Ich lasse mich gern
belehren, aber zur Sache, nicht zu Meinungen. Auch hier gilt wieder, meine
Lösungen mögen Dir nicht gefallen, aber auch das führte nicht zu dem
Fehler.


> Suchen muss ich nicht mehr.
> Du bist wirklich hoffnungslos lernresistent.
>
Du bietest ja auch nichts an außer Deiner Meinung über meine DB. Mit dem
eigentlichen Problem hat das nichts zu tun.

> Dein Modell enthält gerade mal ein paar Hundert Rows, da ist sogar
> awk/grep auf Flatfile schnell.
> Und jetzt sag nicht "Da kommen garantiert nicht mehr als xxxx Rows
> rein", spätestens beim nächsten Mal geht's dann doch um 6-7-8-9-stellige
> Zahlen.
>
Nein eben gerade nicht. Der Datenbestand steht weitestgehend fest. Es
kommen pro Jahr max. 3-4 DS dazu. Und schnell eght es eben nur unter mysql4
nicht aber unter mysql5. Dazu wäre ein Beitrag interessant.

Mathias

Re: out of memory

Am Sun, 01 Oct 2006 19:22:11 +0200 schrieb Claus Reibenstein:

> Wenn man MySQL 5 richtig konfiguriert, sollten auch die alten Skripte
> laufen. Es mag die eine oder andere Ausnahme geben, besonders wenn sie
> sich auf proprietäre Features verlassen, die in der neuen Version nicht
> mehr - oder zumindest nicht mehr in der Form - funktionieren. In Deinem
> Fall sehe ich das aber nicht.

Ihr geht immer alle davon aus, jeder hat einene eigenen Server und kann da
nun schalten und walten wie er will. Es gibt aber noch Menschen, die nuzten
das Angebot eines Hosters wie 1&1 oder Strato. Auch wenn man weis, wie es
geht, dort kannst Du nicht einfach die Config Dateien ändern. Also muß man
mit der Standarvariante auskommen.

Mathias

Re: out of memory

> Was Claus tut, weiß ich nicht, aber für mich ist es ein Hinweis. Ein
> Hinweis, mal zu überprüfen, ob es vielleicht an sowas liegen könnte.
> Wenn ich mich richtig erinnere, kam dieser Hinweis relativ früh. Daß er
> nicht das gewünschte Ergebnis brachte, brauchst Du niemandem
> vorzuwerfen, weil es eben nur ein Hinweis war, woran es gelegen haben
> könnte.
>
Das Buch ist sehr umfangreich. Selbst nach den Aussagen über
Feldübergreifende Indexe und größenverhältnisse in Verbindung mit utf8,
wüßte ich noch nicht wo ich suchen sollte um den Speicherfehler abstellen
zu können.

>> Auch ohne Schrauben drehen und der Hilfe
>> von Michael, habe ich den fehler gefunden. Es liegt an der Art
>> Indexierung. Es muß ein Index über mehrere Spalten sein und nicht ein
>> Index für jede Spalte.
>
> Na dann ist ja gut.
>
>
>> Noch etwas hinterher. Nicht jedem ist es
>> (serverbedingt) möglich, an der my.cnf zu schrauben. aber auch diese
>> Scripte müssen funktionieren.
>
> Ja, aber in diesem Fall sollte man entweder davon ausgehen können, daß
> der Server richtig konfiguriert wurde - oder daß er kaputt ist und sein
> Admin getreten werden müßte.
>
Warum kann denn nicht auch mal mysql nicht ganz ok. sein ?
Die Tatsache, das es openSource und nicht von MS ist, macht es doch nicht
unfehlbar.
>
>> [Es gab keine Hinweise]
>>
>> Genau. Nutze EXPLAIN, habe ich gemacht, keiner will das File lesen.
>
> Ist normal. Der Hinweis, es als plaintext hier reinzuschreiben, mit \G,
> war da (wenn auch spät); da gibt es keinen Grund, daß Du das jetzt
> nochmal anführst.
>
Der Hinweis mit \g kam ziemlich spät, wurde von mir dann für die Anmtwort
an Kris dann auch verwendet.

> Daß der Dialog, der verkürzt so ablief:
>
> "Ich kann und will das File nicht öffnen. Bitte stell es in plaintext
> rein". - "Ich kann die Datei lesen, also bist Du zu doof dafür, ich hab
> die Info bereitgestellt, also habt ihr mir gefälligst zu helfen"
>
> nicht gerade die Hilfsbereitschaft erhöht, sollte Dir hoffentlich klar
> sein.
>
Ich habe nie jemanden genötigt, mir zu helfen. Alles was ich sgate war:

Wenn Ihr Antwortet, dann bitte auf die Frage.

Meine DB ins lächerliche ziehen, Felder als unsinnig bezeichnen, den Kunden
als dooof hinstellen, meine Versuche schlecht zu machen, hat alles nichts
mit der Frage zu tun. Wieso muß nur jeder denken, er müßte mir erklären,
das man ein Datum in ein date Feld speichert, Länder nicht nochmal extra in
eine Tabelle bringt oder ein Varchar Feld nicht mit 255 und utf8 belegt?
Und das alles, ohne die Anwendung zu kennen? Und vor allem ohne jeden Bezug
zur Frage. Man kann doch sagen, varchar 255 mit Kollation utf8 braucht 765
Byte. Aber nein, stattdessen wird gepöbelt und gemeckert, und auf Beiträgen
von vor 1 Jahr herumgetreten.


> Kleiner Tip: Besser wäre gewesen:
>
> "Ich kann und will das File nicht öffnen. Bitte stell es in plaintext
> rein". - "Wie kann ich das tun, ohne da mir die Tabellenstruktur
> zerfleddert wird?" - "Mit \G statt ; am Schluß." -> Explain-Ausgabe
> posten, Hilfe möglich.
>
Da hast Du allerdings recht.

>> Lies das Administratorhandbuch, toller Hinweis.
>
> Natürlich. Zumindest die relevanten Stellen.
>
Die sind ja aber nicht rot gekennzeichnet. Man muß schon wissen nach was
man sucht. Deshalb habe ich ja gefragt. Im Admin Handbuch kann man nunmal
nicht nach Speicherfehler suchen.

>> Schraub an der my.cnf, ein noch tollerer Hinweis.
>
> Es ist der naheliegendste neben Indexoptimierung, aber davon wolltest DU
> ja erst auch nix hören.
>
Ich sagte ja schon, nicht immer möglich.

>> Bei mir kommt deranhang auch an.
>
> Schön für Dich. Du solltest aber nicht immer von Dir auf andere
> schließen.
>

>
> Auf Indexproblematik (daß Du vielleicht nicht die richtigen Indizes
> hast), wurdest Du *sehr* frühzeitig hingewiesen, Deine Reaktion war
> sinngemäß: "Seid ihr denn alle doof? Natürlich habe ich Indizes, ich bin
> ja nicht bekloppt."
>
> Du solltest vielleicht mal versuchen, Ratschläge als solche aufzufassen
> und nicht als Beleidigung.
>
Hier dazu der Beitrag von Axel:

Das ist ein JOIN über 5 Tabellen. Ohne passende Indexe (ich erinnere an
den Thread "zwei Tabellen") kann da ein durchaus fettes Zwischenergebnis
entstehen, das in Folge den Server an Out-of-memory sterben läßt.

Wo ist da der Rat? Das ist eine Unterstellung ! Der Mann nimmt einfach
etwas an, wass Ihm in den Kram passt um um sich zu schiessen. Das fasse
icih sehr wohl als Beleidigung auf !


> Warum fragst Du, wenn Du keine Antworten willst?

Warum antwortet Ihr mir mit allem nur nicht mit dem was gefragt wurde?
Keiner zwingt Euch, auf mein Posting zu antworten.

Ich habe auf die Frage von Kris eine zeimlcih umfangreiche Struktur meiner
Tabellen gepostet. Und nun, nachdem alles bekannt sein dürfte, was nötig
ist, gibt es immer noch keine antwort. Übrigens kam das erst so spät, weil
Kris der erste war, der wirklich konkret nach etwas gefragt hat.

Aber selbst jetzt kommen nur Größenwahn und Beleidigungen, wie z.B. von
Dieter:

Dein Datenmodell ist krank, wie kann man sowas verbrechen?

oder von Stefan:

Seit wann speichert wann werden Datumsangaben als Text hinterlegt, noch
dazu als mediumtext?

Alles, ohne zu wissen, wie die Daten in den Feldern aussehen !

Was hat dasa mit Ratschlägen zu tun? Wer ist hier nicht kooperativ?

Mathias

Re: out of memory

Mathias Fiedler schrieb:
> [...]
> Es kommt kein Bild mehr dazu ! Auch das hat sicherlich keine Auswirkungen
> auf den Speicherbedarf meiner Abfrage. Also wieder einer, der sich nur gern
> mal über andere ausläßt. Wo bleibt Dein Beitrag zum eigentlichen Problem?
> Wenn Du es auch nicht weist, dann sie doch lieber ganz still !

Matthias, Matthias, kurzfristig dachte ich wirklich, Du hättest dir
Kurve gekriegt. War wohl zu optimistisch.

Aber zur Sache: Deine Aussage ist Falsch und bitte, jetzt nimm endlich
mal ein Buch zum Thema Datenbanken, SQL, MYSql und ähnliches, legts
unters Kopfkissen, nimms mit auf Klo oder lies es einfach..... ;-)

Jetzt stell Idr bitte mal (rein theoretisch und losgelöst von Deinem
aktuelle Problem, wir wollen ja mal weiterkommen vor)

Du hast eine Tabelle mit genau einer Spalte varchar(100).
Auf diese Tabelle machst Du ein Select und bekommst 50 Zeilen zurück.
Der Einfachheit nehmen wir jetzt noch an, die Spalte ist voll gefüllt.
(den Unterschied zwischen varchar und char kennst Du, wenn nicht, denk
an das Buch).

Dann musst Du Dir fürs Sortieren 50 x 100 Zeichen merken. Das bekommen
wir hin, oder.

Jetzt stell Dir vor, die Tabelle hat noch 10 weitere Spalten mit jeweils
varchar(255). Die schleppst Du jetzt in Deinem Resultset mir, selbst
wenn Dich der Inhalt an dieser Stelle einen feuchte Schmutz
interessieren. Das amcht dann ( 10 x 255 + 100 ) x 50

Jetzt erzähl mir nicht, dass das kein Unterschied macht.

Also nicht so weit aus dem Fenster lehnen.

So far,
Michael

PS: Ich weiss, dieses Posting bringt Dich in Deinem out off memory nicht
weiter, aber vielleicht lernst Du dabei etwas mehr über SQL und wie eine
DBMS so arbeitet und wieso Du Dir beim Datenmodell etwas mehr Zeit
nehmen solltest.

Und wirklich: Man kann einem Chef oder Auftrageber sagen, wenn die
Vorgaben gar zu scheisse sind.

Re: out of memory

Mathias Fiedler schrieb:
> [...]
>
> Nein eben gerade nicht. Der Datenbestand steht weitestgehend fest. Es
> kommen pro Jahr max. 3-4 DS dazu. Und schnell eght es eben nur unter mysql4
> nicht aber unter mysql5. Dazu wäre ein Beitrag interessant.
>
> Mathias

Gut dann mal anders.
Ich habe im Job zwei Datenbanken. Einmal Test und einmal Produktion.
Jetzt kommt es manchmal vor, dass ein Select auf der Test ein echter
Turbo ist, während man die Daten auf der Produktion schneller vorn Hand
raussuchen könnte.

Was ist der Grund (beide Datenbanken haben das gleiche Release).
Der Grund ist, dass der Optimizer aufgrund irgendwelcher Unterschiede in
den Daten einen anderen Plan ausgetüftelt hat. Und der eine ist eben
Klasse und der andere ist Schrott. Und das sehe ich dann, weil ich mir
den Executionplan anschaue.

Und was hilft dir das jetzt?

Lasse den exakt gleichen Select auf denselben Daten einmal unter mysql4
und einmal unter mysql5 laufen, und zieh dabei den Plan.

Den vergleichst Du jetzt und ich möchte wetten, das gibt es
Unterschiede. Jetzt weisst Du zumindest, wieso das Ding einmal absemmelt
und einmal schön schnell zum Ende kommt.

Falls Du Dich gründlich mit den Plänen bschäftigt hat und immer noch
Hilfe brauchst, wäre eine Möglichkeit, die Pläne hier mal zu posten
(aber he, so dass jeder sie lesen kann) und freundlich zu fragen, ob Dir
jemand helfen kann.

Und noch eins möchte ich Dir mitgeben:
Alles was hier gesagt wird, insbesondere die Kritik an dem Datenmodell
hat mit Deinem Problem zu tun. Vielleicht nicht kurzfristig, aber Du
wirst, nachdem Du das Out-Of-Memory irgendwie mit der Brechstange
hingebogen hat, sehr bald vor dem nächsten Problem stehen.

Den wie ich Dir in einem anderen Zusammenhang mal gesagt habe.
Auf einem morschen, windschiefen und baufälligen Fundament solltest Du
kein Haus bauen. Und wenn doch, wird es zuerst Setzungsrisse bekommen
und irgendwann mit Getöse einstürzen.

Michael

Re: out of memory

Mathias Fiedler wrote:
> hier die gewünschten daten.
>
> soviel zur Tabellenstruktur:

Anderswo wurde ja schon gesagt: Normal ist das nicht. Normal im
Datenbanksinn sind Datenstrukturen, wenn sie so ungefähr in 3NF sind
(http://de.wikipedia.org/wiki/3NF,
http://katze-mit-wut.azundris.com/archives/116-Nermalisierun g.html).
Feldnamen, die durchnumeriert sind, sind immer schon ein deutlicher Hinweis
auf nicht normalisierte Datenstrukturen.

Normalisierung ist sogar dann wichtig, wenn Du der Meinung bist, daß die
Anzahl der Felder sich niemals ändert. Wenn Du zum Beispiel ein Cover mit 4
Bildern hast, dann kannst Du nach einem Bild mit dem Titel "Satriani"
unnormalisiert nur mit einem fetten OR oder einer UNION suchen:

SELECT id_cover
FROM covers
WHERE titel_bild1 like "%satriani%"
OR titel_bild2 like "%satriani%"
OR titel_bild3 like "%satriani%"
OR titel_bild4 like "%satriani%"

Wenn Du gar nach der Bild-ID statt nach der Cover-ID fragst, wird es richtig
schmutzig. Normalisiert ergäbe sich eine 1:n Beziehung zwischen Covern und
Bildern, sodaß Du

SELECT c.id_cover
FROM covers AS c JOIN bilder as b ON b.id_cover = c.id_cover
WHERE b.titel_bild like "%satriani%";

fragen kannst und sogar

SELECT b.id_bild
FROM covers AS c JOIN bilder as b ON b.id_cover = c.id_cover
WHERE b.titel_bild like "%satriani%";

nicht mehr weh tut.

Außerdem braucht es nicht mehr vier Indices auf titel_bild1, titel_bild2 und
so weiter, sondern ein Index auf titel_bild reicht, und die Suche tut so
viel weniger weh.

Deine Tabelle images zum Beispiel ließe sich viel besser auftrennen: Erzeuge
eine Tabelle image_roles und setze da Paare role_id (ein Tinyint unsigned
wird genügen) und role_name rein. Role_names sind so "coverbild",
"innencoverbild", "innen", "coverbild_thumbnail" und so weiter.

Die Tabelle images ist dann noch (id_image, id_basic, role_id, image_number,
image_text). Du suchst dann nach dem 3. Bild mit der Role innencoverbild
so:

select i.id_image
, i.image_text
from images as i join image_roles as ir on ir.role_id = i.role_id
where i.image_number = 3
and ir.role_name = "innencoverbild"

und Du listest alle Innencover von Satriani in der korrekten Reihenfolge
entsprechend mit

select i.id_image
, i.image_text
, i.image_number
from images as i join image_roles as ir on ir.role_id = i.role_id
join basic_informations as bi on bi.id_basic = i.id_basic
where ir.role_name = "innencoverbild"
and bi.bandname like "%satriani%"
order by bi.id_basic
, i.image_number;

Derselbe Stunt muß auch für die Presskit-Tabelle gemacht werden und für die
References.

Nebenbei bemerkt sollten in Datenbanken nicht nur alle Felder NOT NULL sein,
es sei denn, man hat eine gute Story (Du machst das bereits sehr richtig),
sondern auch alle INTEGER sollten UNSIGNED sein, es sei denn, man kann
zeigen, daß man hier wirklich Zahlen mit Vorzeichen haben will. Das
verhindert nicht nur Fehler, sondern verdoppelt mal so eben den nutzbaren
Range.

Was Zeichenketten angeht, ist meine Empfehlung immer, auf Server-, Schema-
und Tabellenebene einen Singlebyte-Zeichensatz, etwa latin1, zu verwenden.
Einzelne Spalten, die Texte in fremden Sprachen mit Sonderzeichensätzen
enthalten, sollten im Singlebyte-Zeichensatz und mit der Collation
gespeichert werden, die zu dieser Sprache gehört. Nur wenn eine Spalte
wirklich mehrsprachig ist, sollte die Spalte (und nur diese eine Spalte) in
einem Multibyte-Zeichensatz definiert werden. Das alles ist in
http://blog.koehntopp.de/archives/1424-MySQL-Zeichensatz-Gru ndlagen.html
noch mal in länger und mit Beispielen nachzulesen. Die wichtige Information
hier: Selbst wenn Deine Anwendung utf8 redet, muß es die Datenbank nicht
zwingend tun.

Zu dem releaseDate als mediumtext ist ja anderswo auch schon was gesagt
worden: Ein Mediumtext hat 3 Längenbytes, kann also 16 MB Speichern. Das
ist auch in utf8 ein wenig neben der Spur. Möglicherweise willst Duch auch
einfach etwas unscharfes, aber dennoch quantifizierbares haben: Einen
Daterange mit "releaseDateBegin date not null" und "releaseDateEnd date not
null", sodaß Du mit einem passenden BETWEEN-Konstrukt fuzzy suchen kannst.
Irgendwann in den 90ern wäre dann releaseDateBegin = "1990-01-01" und
releaseDateEnd = "1999-12-31". Solche Angaben sind ausreichend vage, aber
dennoch mit einer Datenbank erschließbar. "Irgendwann in den 90ern" ist es
nicht.


Das SHOW CREATE TABLE habe ich abgefragt, damit ich sehen kann, welche
Felder in Deiner Datenbankdefinition vorkommen und ich besser verstehen
kann, wie sie in Beziehung zueinander stehen.

SHOW TABLE STATUS für diese Tabellen sagt mir nun, wieviele Zeilen in jeder
Tabelle sind, wie breit diese sind und welche Storage Engine mit welchem
Row_Format zu verwendest. Data_length und Index_length geben mir die Größe
Deiner Daten in Bytes an. Alle diese Informationen sind nützlich um zu
entscheiden, ob die Aufgaben des Optimizers weiter unten im Text irgendwie
sinnvoll sind oder fischig aussehen.

EXPLAIN SELECT ... gibt zu einer Query den Query Plan aus, also welche
Tabellen in Deiner Query wie und in welcher Reihenfolge miteinander
verbunden werden. Die Tabellen werden, da Du inner joins verwendet hast,
nicht zwingend in der Reihenfolge miteinander verbunden, die Du
aufgeschrieben hast, sondern können durch den Optimizer umgestellt werden.
Das ist gut, denn so ist es für den Server oft möglich, die Query
effizienter auszuführen.

Für jede Tabelle in Deinem JOIN wird im EXPLAIN eine Zeile generiert. Der
select_type ist dabei immer SIMPLE, weil Deine Query ein einfacher Join
ohne Subqueries oder Union-Clauses ist. Die table gibt an, welche wann an
die Reihe kommt. Hier wird der Join also von der "images AS i" Tabelle
getrieben, die im nächsten Schritt mit basic_informations AS bi verbunden
wird.

Der type gibt an, auf welche Weise die Tabelle gelesen wird. ALL bedeutet,
daß ein Full Table Scan gemacht wird. Bei MyISAM bedeutet das, daß die
MYD-Datei für diese Tabelle linear von vorne nach hinten durchgelesen wird,
alle Data_length Bytes davon.

Ein "INDEX" würde bedeuten, daß dasselbe mit einem Index gemacht wird, also
(mit einem Teil) der MYI-Datei - ein Index-Scan kann verwendet werden, wenn
alle zu lesenden Daten in Kopie auch in der MYI-Datei vorhanden sind. Die
Daten im Index sind jedoch kleiner als die Daten im MYD, sodaß weniger
Blöcke geladen werden müssen.

Ein "RANGE" wäre noch besser - es ist ein Index-Scan auf einen Teilbereich
eines Index, der wiederum ein Teilbereich der MYI-Datei ist. Wir müssen
also noch weniger Blöcke lesen.

Ein "ref_or_null", "ref" oder "eq_ref" sind dagegen keine Scans, sondern
Index-Lookups. Wir können also mit einem Indexwert in den Index gegen und
bekommen dann mehrere (ref_or_null, ref) oder genau eine (ref) Zeile im
Tausch dagegen zurück. Das ist in allen (bis auf einige pathologische)
Fällen schneller als ein ALL, INDEX oder RANGE scan.

"const" oder "system" wären noch besser, denn sie deuten darauf hin, daß die
Ersetzung von Indexwerten durch die indizierten Werte nicht in der
JOIN-Schleife gemacht werden muß, sondern schon im Optimizer passieren kann
- die betreffende Tabelle kann also aus dem Query-Plan gestrichen werden.

Ob und welcher Index verwendet werden kann sagt Dir "possible_keys" - diese
Indices sieht der Optimizer und zieht sie in Betracht. "key" ist dann
derjenige Index, der wirklich verwendet worden ist - er kann ganz oder in
Teilen verwendet werden. "key_len" ist die Anzahl der Bytes aus dem Index
die verwendet wurden, und wenn Du die Indexdefinition kennst, kannst Du
daraus erkennen, welcher Sub-Part des Index verwendet worden ist.

Wenn Du einen *ref hast, dann willst Du natürlich wissen, wie die Verbindung
zu der übergeordneten Tabellen in der Join-Schleife hergestellt word. Die
Spalte "ref" sagt Dir das: Mit dem Scan durch images AS I finden wir zum
Beispiel i.ID_image-Werte (ref aus Zeile 2), die wir gegen den
ID_Images-Index aus basic_informations AS bi joinen. Für jede der 327
Zeilen aus images AS i bekommen wir so eine Zeile in basic_informations AS
bi (rows = 327 in i, rows = 1 in bi).

Die Badness der Query ist die Anzahl der Rows, die wir durchsehen müssen, um
den Resultset zu bestimmen. In einem SIMPLE-Join ist das das Produkt aller
Rows - bei Dir also 327 * 1 * 1 * 1 * 1. Stellt man die Badness gegen die
Größe des Resultsets kann kan erkennen, ob die Query noch optimierbar ist.
In Deinem Fall wird der Resultset von 327 (*1...) noch weiter eingeschränkt
durch die Bedingung auf bi.id_hg und bi.presskit. Da wir im JOIN aber schon
ID_images benötigen, um die Verbindung von bi zu i herzustellen, und wir
pro Tabelle nur einen Index verwenden können, muß der Server hier manuell
die Daten durchseihen - "using where" zeigt Dir das an. Der Index auf ID_hg
kann nicht verwendet werden und existierte einer auf ID_presskit wäre er
auch nicht benutzbar.

Dein Datenbankserver generiert nun ein Resultat und wäre das Resultat nicht
geordnet, könnte der Resultset von der Join-Schleife inkrementell
herausgedrückt werden ohne jemals auf dem Server materialisiert zu werden.

Durch das ORDER BY ist das nicht mehr möglich - das Query-Resultat muß auf
dem Server in Form einer temporären Tabelle materialisiert werden, die dann
manuell und ohne Hilfe von Indices sortiert werden muß. Im EXPLAIN sehen
wir das als "using temporary" - der Resultset wird materialisiert und
"using filesort" - die temporäre Tabelle wird nun manuell sortiert.

Eine temporäre Tabelle versucht MySQL als MEMORY-Tabelle zu erzeugen, weil
das schneller ist, solange sie nicht größer als tmp_table_size wird. Wird
sie größer, geht die temporäre Tabelle als MyISAM auf die Platte.

Ist die Tabelle kleiner als tmp_table_size, versucht MySQL sie als MEMORY zu
erzeugen. Scheitert das, geht die temporäre Tabelle ebenfalls als MyISAM
auf die Platte. Das Anlegen einer MEMORY-Tabelle kann scheiter - selbst
wenn sie kleiner ist als tmp_table_size - wenn die MEMORY-Tabelle größer
wird als max_heap_table_size oder wenn sie (also das Zwischenresultat)
Typen enthält, die MEMORY nicht darstellen kann. Dazu gehört zum Beispiel
alles mit BLOB oder TEXT im Namen.

In jedem Fall geht der Statuszähler created_tmp_tables einen rauf. Geht die
Tabelle außerdem noch auf die Platte, geht zusätzlich
created_tmp_disk_tables nach oben. Mit "FLUSH STATUS", Deiner Query und
"SHOW SESSION STATUS LIKE '%TMP%'" kannst Du das nachprüfen.

Manuelle Sortierung bedeutet, daß wir einen sort_buffer erzeugen müssen -
dazu werden sort_buffer_size Bytes für die Connection bestellt, die Daten
sortiert und dann der sort_buffer so schnell als möglich freigegeben
(Tatsächlich ist es, wenn ich den Code richtig erinnere, noch
komplizierter. In einer Connection können mehrere, bis zu drei,
Speicherblöcke von sort_buffer_size zugleich verwendet werden).

In Deiner Query versuchst Du nun, nach

bi.dateOriginal (3 Byte)
bi.charge (4 Byte)
bi.name (765 Byte)
re.ref1 (765 Byte)
re.ref2 (765 Byte)
re.ref3 (765 Byte)
re.ref4 (765 Byte)
inc.inches (15 Byte)
la.land (765 Byte)

== total sortlen 4612 Byte

zu sortieren. Ich habe den Code in sql/filesort.cc:filesort() nicht mit
Deinen Werten durchgetraced, aber es sieht aus, als ob es Dich irgendwo
zwischen Zeile 198 bis 217 zerlegt:

memavl= thd->variables.sortbuff_size;
min_sort_memory= max(MIN_SORT_MEMORY, param.sort_length*MERGEBUFF2);
while (memavl >= min_sort_memory)
{
ulong old_memavl;
ulong keys= memavl/(param.rec_length+sizeof(char*));
param.keys=(uint) min(records+1, keys);
if ((sort_keys= (uchar **) make_char_array(param.keys, param.rec_length,
MYF(0))))
break;
old_memavl=memavl;
if ((memavl=memavl/4*3) < min_sort_memory && old_memavl >
min_sort_memory)
memavl= min_sort_memory;
}
if (memavl < min_sort_memory)
{
my_error(ER_OUTOFMEMORY,MYF(ME_ERROR+ME_WAITTANG),
thd->variables.sortbuff_size);
goto err;
}

min_sort_memory ist für Dich 4612 * 15 = 69180. memavl ist by Default
sort_buffer_size = 2M minus ein bischen. Und zu dem ER_OUTOFMEMORY kommen
wir, wenn memavl irgendwann mal zwischen min_sort_memory/4*3 und
min_sort_memory zu liegen kommt. Was genau da ab geht, verstehe ich so beim
überlesen aber nicht und zum Tracen bin ich hier nicht ausgerüstet.

Spielen an sort_buffer_size kann die Bedingungen hier aber verändern und den
Fehler so vielleicht verhindern.

Kris

Re: out of memory

Am Wed, 04 Oct 2006 22:54:52 +0200 schrieb Michael König:

> Und wirklich: Man kann einem Chef oder Auftrageber sagen, wenn die
> Vorgaben gar zu scheisse sind.

Leider nur bedingt.

Mathias

Re: out of memory

Am Wed, 04 Oct 2006 23:15:55 +0200 schrieb Michael König:

> Falls Du Dich gründlich mit den Plänen bschäftigt hat und immer noch
> Hilfe brauchst, wäre eine Möglichkeit, die Pläne hier mal zu posten
> (aber he, so dass jeder sie lesen kann) und freundlich zu fragen, ob Dir
> jemand helfen kann.
Die Pläne sind doch da. Zwar etwas spät, aber ich ahbe doch alles zum Theme
auf den Beitrag von Chris gepostet.
>
> Und noch eins möchte ich Dir mitgeben:
> Alles was hier gesagt wird, insbesondere die Kritik an dem Datenmodell
> hat mit Deinem Problem zu tun. Vielleicht nicht kurzfristig, aber Du
> wirst, nachdem Du das Out-Of-Memory irgendwie mit der Brechstange
> hingebogen hat, sehr bald vor dem nächsten Problem stehen.

Ich habe keine Probleme mit Kritik. Das mein DB Modell nun nicht der letzte
Schliff ist, habe ich ja geschnallt. Da ich aber kein mysql Experte bin,
sondern die DB eben zur Datenspeicherung für php benötige, habe ich mit
diesen tiefgreifenden Dingen noch nicht befasst. Datenbankdesignist ein
eigener Studiengang, das lernt man numal nicht aus einem Handbuch. Das
weist Du ja auch.
Mein Ärger rührt daher, das hier fast jeder mit Annahmen um sich wirft, die
jeder Grundlage entbeeren, und das die eineige Hinweise zwar in der Sache
richtig sind aber eben das Problem nicht lösen. Der brauchbarste Ansatz
war bisher der von Kris. Das muß ich aber erst mal in Ruhe verarbeiten. Für
Euch mag das ja alles kein Problem darstellen, für mcih ist das schon
starker Tobak.

mfg

Mathias

Re: out of memory

Am Wed, 04 Oct 2006 23:24:02 +0200 schrieb Kristian Köhntopp:


>
> Normalisierung ist sogar dann wichtig, wenn Du der Meinung bist, daß die
> Anzahl der Felder sich niemals ändert. Wenn Du zum Beispiel ein Cover mit 4
> Bildern hast, dann kannst Du nach einem Bild mit dem Titel "Satriani"
> unnormalisiert nur mit einem fetten OR oder einer UNION suchen:
>
Da ich nie nach Bildern suchen muß, war das für mich nie relvant. Es ist
eine reine Ausgliederung für die Anzeige. Die tabelle basic_informations
enthält alle relevanten dinge. Auch die id_images, die in der Tabelle
images vorkommt. Somit habe ich die Bilder zu dem Datensatz. Da die
Bildernamen nicht bekannt sind (für den User) wird auch nie eine Suche
danach nötig.
>
>
> Deine Tabelle images zum Beispiel ließe sich viel besser auftrennen: Erzeuge
> eine Tabelle image_roles und setze da Paare role_id (ein Tinyint unsigned
> wird genügen) und role_name rein. Role_names sind so "coverbild",
> "innencoverbild", "innen", "coverbild_thumbnail" und so weiter.
>
> Die Tabelle images ist dann noch (id_image, id_basic, role_id, image_number,
> image_text). Du suchst dann nach dem 3. Bild mit der Role innencoverbild
> so:
>
> select i.id_image
> , i.image_text
> from images as i join image_roles as ir on ir.role_id = i.role_id
> where i.image_number = 3
> and ir.role_name = "innencoverbild"
>
> und Du listest alle Innencover von Satriani in der korrekten Reihenfolge
> entsprechend mit
>
> select i.id_image
> , i.image_text
> , i.image_number
> from images as i join image_roles as ir on ir.role_id = i.role_id
> join basic_informations as bi on bi.id_basic = i.id_basic
> where ir.role_name = "innencoverbild"
> and bi.bandname like "%satriani%"
> order by bi.id_basic
> , i.image_number;
>
> Derselbe Stunt muß auch für die Presskit-Tabelle gemacht werden und für die
> References.
>
Das muß ich erst mal setzen lassen.

> Nebenbei bemerkt sollten in Datenbanken nicht nur alle Felder NOT NULL sein,
> es sei denn, man hat eine gute Story (Du machst das bereits sehr richtig),
> sondern auch alle INTEGER sollten UNSIGNED sein, es sei denn, man kann
> zeigen, daß man hier wirklich Zahlen mit Vorzeichen haben will. Das
> verhindert nicht nur Fehler, sondern verdoppelt mal so eben den nutzbaren
> Range.
>
Merk ich mir

> Was Zeichenketten angeht, ist meine Empfehlung immer, auf Server-, Schema-
> und Tabellenebene einen Singlebyte-Zeichensatz, etwa latin1, zu verwenden.
> Einzelne Spalten, die Texte in fremden Sprachen mit Sonderzeichensätzen
> enthalten, sollten im Singlebyte-Zeichensatz und mit der Collation
> gespeichert werden, die zu dieser Sprache gehört.

Auftraggeber ist utf8 Fetischist

Hierbei ging es nicht um Werte sondern um Exaktheit. Es ist eine
Discographie für ein Museum und auf den Platten steht das Datum in dem
Format, wie es die Firma damals wollte. Das wird 1:1 übernommen. Einige
Platten sind nicht mehr existent. Man weis nur 19??. Für die Einordnung
wird ein weiteres Datum verwednet, das schätzt der Museums-Chef. Deshalb
diese Angabe. Taucht diese Paltte wieder auf, kann der Wert exakt geändert
werden.

>
> Das SHOW CREATE TABLE habe ich .....

Das muß ich erst mal alles in Ruhe verarbeiten.

Danke für die Ausführungen.

mfg

Mathias

Re: out of memory

Mathias Fiedler wrote:


>> Was Claus tut, weiß ich nicht, aber für mich ist es ein Hinweis. Ein
>> Hinweis, mal zu überprüfen, ob es vielleicht an sowas liegen könnte.
>> Wenn ich mich richtig erinnere, kam dieser Hinweis relativ früh. Daß
>> er nicht das gewünschte Ergebnis brachte, brauchst Du niemandem
>> vorzuwerfen, weil es eben nur ein Hinweis war, woran es gelegen haben
>> könnte.
>>
> Das Buch ist sehr umfangreich. Selbst nach den Aussagen über
> Feldübergreifende Indexe und größenverhältnisse in Verbindung mit utf8,
> wüßte ich noch nicht wo ich suchen sollte um den Speicherfehler
> abstellen zu können.

Zugegeben, Dein Problem scheint ein eher subtiles zu sein, das sich nicht
unbedingt auf Anhieb lösen läßt. Zudem scheint Deine Anwendung MySQL an
gewisse Grenzen zu bringen.


>>> Noch etwas hinterher. Nicht jedem ist es
>>> (serverbedingt) möglich, an der my.cnf zu schrauben. aber auch diese
>>> Scripte müssen funktionieren.
>>
>> Ja, aber in diesem Fall sollte man entweder davon ausgehen können, daß
>> der Server richtig konfiguriert wurde - oder daß er kaputt ist und
>> sein Admin getreten werden müßte.
>>
> Warum kann denn nicht auch mal mysql nicht ganz ok. sein ?

Das ist natürlich auch möglich, aber erstmal geht man von dem
naheliegenden aus. Das ist das Übliche, wenn man Fehler eingrenzen will.


> Die Tatsache, das es openSource und nicht von MS ist, macht es doch
> nicht unfehlbar.

Das stimmt allerdings.


>> Ist normal. Der Hinweis, es als plaintext hier reinzuschreiben, mit
>> \G, war da (wenn auch spät); da gibt es keinen Grund, daß Du das jetzt
>> nochmal anführst.
>>
> Der Hinweis mit \g kam ziemlich spät, wurde von mir dann für die
> Anmtwort an Kris dann auch verwendet.

Nur zur Info: \G <> \g.


>> Daß der Dialog, der verkürzt so ablief:
>>
>> "Ich kann und will das File nicht öffnen. Bitte stell es in plaintext
>> rein". - "Ich kann die Datei lesen, also bist Du zu doof dafür, ich
>> hab die Info bereitgestellt, also habt ihr mir gefälligst zu helfen"
>>
>> nicht gerade die Hilfsbereitschaft erhöht, sollte Dir hoffentlich klar
>> sein.
>>
> Ich habe nie jemanden genötigt, mir zu helfen. Alles was ich sgate war:
>
> Wenn Ihr Antwortet, dann bitte auf die Frage.
>
> Meine DB ins lächerliche ziehen, Felder als unsinnig bezeichnen, den
> Kunden als dooof hinstellen, meine Versuche schlecht zu machen, hat
> alles nichts mit der Frage zu tun.

Der Ton in NGs ist manchmal recht hart, aber denke daran: Wie man in den
Wald hineinruft, so schallt es heraus. Ich hab jetzt grad keine Lust, zu
schauen, wie sich das in welcher Reihenfolge entwickelt hat, aber Deine
Reaktion auf die Bitte, den Inhalt der .doc-Datei in problemlos lesbarer
Form nochmal zu posten, war sehr pampig, da brauchst Du Dich ber
entsprechende Reduktion der Hilfbereitschaft nicht zu wundern.


> Wieso muß nur jeder denken, er müßte mir erklären, das man ein Datum in
> ein date Feld speichert,

Weil es so ist? Weil Du um einen Ratschlag gefragt hast? Normalerweise
sollte man froh sein, wenn man Optimierungstips bekommt...

> oder ein Varchar Feld nicht mit 255 und utf8 belegt?

Daß man "das nicht tut", ist so schlicht Unfug - aber es kann zu
Problemen führen. Dessen sollte man sich bewußt sein.

> Und das alles, ohne die Anwendung zu kennen?

Viele der genannten Probleme sind anwendungsunabhängig.


>>> Lies das Administratorhandbuch, toller Hinweis.
>>
>> Natürlich. Zumindest die relevanten Stellen.
>>
> Die sind ja aber nicht rot gekennzeichnet. Man muß schon wissen nach
> was man sucht. Deshalb habe ich ja gefragt. Im Admin Handbuch kann man
> nunmal nicht nach Speicherfehler suchen.

Stimmt. Aber die entsprechenden my.cnf-Stellen hättest Du finden können,
und dann schreiben können "Ein Ändern der my.cnf auf ... brachte keine
Änderung" o.ä.)


>> Du solltest vielleicht mal versuchen, Ratschläge als solche
>> aufzufassen und nicht als Beleidigung.
>>
> Hier dazu der Beitrag von Axel:
>
> Das ist ein JOIN über 5 Tabellen. Ohne passende Indexe (ich erinnere an
> den Thread "zwei Tabellen") kann da ein durchaus fettes
> Zwischenergebnis entstehen, das in Folge den Server an Out-of-memory
> sterben läßt.
>
> Wo ist da der Rat?

Das ist ein impliziter Hinweis, daß es eben an der Abwesenheit passender
Indizes liegen könnte.


> Das ist eine Unterstellung ! Der Mann nimmt einfach etwas an, wass Ihm
> in den Kram passt um um sich zu schiessen. Das fasse icih sehr wohl als
> Beleidigung auf !

Wenn Du tatsächlich die zitierte Textpassage als Beleidigung auffaßt,
kann ich Dir wirklich nicht mehr helfen. Lag es im Endeffekt nicht in
der Tat an einem unpassenden Index? Also hat er doch richtig gelegen...


> Warum antwortet Ihr mir mit allem nur nicht mit dem was gefragt wurde?
> Keiner zwingt Euch, auf mein Posting zu antworten.

Wie gesagt - ein aufgetretenes Problem, dessen Ursache nicht sofort auf
der Hand liegt, muß man eben eingrenzen bzw. man muß mögliche Ursachen
auf ihre Relevanz für das Problem testen.


> Ich habe auf die Frage von Kris eine zeimlcih umfangreiche Struktur
> meiner Tabellen gepostet. Und nun, nachdem alles bekannt sein dürfte,
> was nötig ist, gibt es immer noch keine antwort. Übrigens kam das erst
> so spät, weil Kris der erste war, der wirklich konkret nach etwas
> gefragt hat.

Vielleicht hat noch niemand eine weiterführende Lösung gefunden?
Vielleicht war man auch der Meinung, Du hättest die Lösung
(Multi-Column-Index nötig) bereits gefunden?


> Aber selbst jetzt kommen nur Größenwahn und Beleidigungen, wie z.B. von
> Dieter:
>
> Dein Datenmodell ist krank, wie kann man sowas verbrechen?

Nicht sehr nett, aber vermutlich ist es so (hab nicht genau geschaut).
Was er damit meinte: Da herrscht erhebliches Optimierungspotential und
Probleme sind vorprogrammiert. Zum Beispiel die von Dir beobachteten.


> Seit wann speichert wann werden Datumsangaben als Text hinterlegt, noch
> dazu als mediumtext?

Ist aber so, vor allem, weil es zusätzlich erhebliche Probleme bereitet.


> Alles, ohne zu wissen, wie die Daten in den Feldern aussehen !

Muß man nicht wissen, um eine Grobbeurteilung eines Datenmodelles
durchzuführen. Zum Beispiel Kalenderdatum: Daß das Datum applikations-
oder inmterfaceseitig als TT.MM.JJJJ bereitgestellt wird, ist kein rund,
es auch so zu speichern - Umwandlung ist applikationsseitig trivial, und
AFAIR stellt MySQL auch Funktionen hierfür bereit.


Thomas
--
»"Na, das war ja einfach«, sagt der Mensch und beweist, weil's gerade so
schön war, dass schwarz gleich weiß ist, und kommt wenig später auf einem
Zebrastreifen ums Leben. [Douglas Adams: Per Anhalter durch die Galaxis]

Re: out of memory

Ich danke Dir für Deine Ausführungen und möchte jetzt auch nicht weiter auf
einzelne Punkte eingehen. Es ist aber numlal so, das meine Anwendung die
Discographie einer Rockgruppe für ein Museum darstellt. Da diese Gruppe
Ihre Platten von über 50 Labels hat produzieren lassen, auch im Ausland,
kann die Datumsangabe variieren. Ein japanisches Datum sieht nun mal
vollkommen anders aus als ein amerikanisches oder deutsches. Da die Leute
dort absoluten Wert auf Autentizität legen, muß die Angabe in der
Discographie genau der auf der Platte entsprechen. Das bedeutet, ich kann
für das Release Datum kein Date Feld nehmen. Es muß text oder varchar sein
und Kollation utf8. Unter mysql4 gab es keine kollation und es ging auch.
Der Kunde nutzt aber mysql5 und schwört auf utf8, weil ihm das irgendwann
mal einer schmackhaft gemacht hat.
Die numerierten Einträge in presskit und image habe ich so gemacht, weil
ich genau weis, das da nichts mehr dazukommt. Vielleicht nicht genau im
Sinne der 3. NF (ich weis schon, was das ist), aber für mich brauchbar. Da
ich dort auch auch nur eine ID vergleiche, war das für mich kein Grund
etwas zu ändern. Damit wird mein Server bestimmt nicht aussteigen.
Beim Sortieren nach 4 vrachar(255) Feldern mit Kollation utf8 kann das wohl
vorkommen, wie ich nach dem Posting von Kris nun weis.
Das war mir vorher so nicht klar. Für die Zukunft werde ich aber etwas
besser darauf achten.
Aber aus den Ausführungen zum Datum kannst Du schon erkennen, das eben ein
date Feld dafür nicht geeignet ist. Das kann natürlich keiner wissen, der
den Sachverhalt nicht kennt. Aber dann kann auch keiner sagen, Dein Modell
ist scheiße. Da muß man zumindest doch mal Fragen, warum das so gemacht
ist, bevor man beginnt, wild in der Gegend rumzuballern. Das ich dann sauer
werde, dürfte wohl normal sein.
Und wenn bereits der dritte Beitrag zu dem Thema so beginnt:

Dein Name kam mir gleich so bekannt vor. Und tatsächlich, Google
bescheinigt dir eine nicht vernachlässigbare Historie an - sagen
wir mal unkooperativen - Postings in dieser Gruppe. Deine Beiträge
in diesem Thread lassen irgendwie auch keine Besserung erkennen.

wird es auch nicht besser. Da hat also jemand tatsächlich die Zeit, bei
Google nach alten Beiträgen von mir zu suchen um sinngemäß zu behaupten:
Du warst damals schon blöd, Du bist es auch heute noch. Für eine sinnvollen
Beitrag fehlt ihm aber die Zeit. Die Unterstellung mit den Indexen kam von
dem selben User.
Wie auch dieses:

Weil nicht sein kann, was nicht sein darf? Nach all den Hinweisen, die
du in der Vergangenheit hier schon bekommen hast, hätte ich angenommen,
daß du zumindest mal EXPLAIN selber bemühst und notwendige Indexe
nachrüstest. Habe ich dich wohl überschätzt.

Daher mein Unverständnis. Er nimmt an, es gibt keinen Index. Keine Frage,
kein Hinweis,keine Hilfe, nur Unterstellung und auch gleich noch eins
obendrauf. Der Mann hat anscheinend eine Glaskugel, die Ihm alles verrät.
Nur ist die gerade defekt.

Ich sagte es bereits in einem meiner letzten Postings. Es ist mir egal, wie
beleidigt mache Leute sind, wenn man Ihren "Rat" nicht akzeptiert. Ich
werde weiterhin meine Meinung vertreten und auch weiter in der NG posten.
Es gibt immer noch Leute, die wirkliche Hilfe anbieten. Alle anderen sind
mir egal. Ob ich ins Killfile wandere und gar keine Antworten erhalte oder
ob ich mir oben genannten Müll anhören muß, ist doch egal. Hilfe ist weder
das eine noch das andere, das Killfile spart wenigstens noch Ärger und
Traffic und grenzt den Thread auf Menschen ein, die noch wissen, was Hilfe
bedeutet. Auf die ganze heisse Luft, die von den vielen "Experten" kam,
kann ich leicht verzichten.

Schau Dir den Thread doch an:
Frage gestellt
über 60 Beiträge dazu
Frage noch immer nicht gelöst.

Das spricht doch für sich, oder?

Die 12 Beiträge, die wirklich zur Problemlösung beitragen wollten, hätten
doch gereicht. Das waren Deine Beiträge, die von Kris und von Michael. Der
Rest bläht nur den Thread auf.

mfg

Mathias

Re: out of memory

Mathias Fiedler schrieb:
> Am Wed, 04 Oct 2006 23:15:55 +0200 schrieb Michael König:
>
>
>>Falls Du Dich gründlich mit den Plänen bschäftigt hat und immer noch
>>Hilfe brauchst, wäre eine Möglichkeit, die Pläne hier mal zu posten
>>(aber he, so dass jeder sie lesen kann) und freundlich zu fragen, ob Dir
>>jemand helfen kann.
>
> Die Pläne sind doch da. Zwar etwas spät, aber ich ahbe doch alles zum Theme
> auf den Beitrag von Chris gepostet.


Hallo,
ich kann nur einen finden (gepostet am 3.10 um 19:55). Ich nehme an,
dass ist der zu MySql 5.
Kannst Du jetzt bitte noch den "alten" schicken, oder sagen, wo Du ihn
schon gepostet hast.

Gruß,
Michael

Re: out of memory

> Hallo,
> ich kann nur einen finden (gepostet am 3.10 um 19:55). Ich nehme an,
> dass ist der zu MySql 5.
> Kannst Du jetzt bitte noch den "alten" schicken, oder sagen, wo Du ihn
> schon gepostet hast.
>
Der alte ist identisch ausser der Angabe der Kollation weil die in mysql4
nicht unterstützt wird.

mfg

Mathias

Re: out of memory

Mathias Fiedler wrote:

> Ein japanisches Datum sieht nun mal vollkommen anders aus als ein
> amerikanisches oder deutsches. Da die Leute dort absoluten Wert auf
> Autentizität legen, muß die Angabe in der Discographie genau der auf
> der Platte entsprechen.

Naja, das ist ja schonmal ein Grund, es auf Deine Art und Weise zu
machen. Es ist aber ein absoluter Sonderfall und beraubt Dich im
Gegenzug einer datumsbezogenen Suche. Ein zusätzliches Feld in
date-Format, welches das Datum in normalisierter Form enthält wäre evtl.
nicht verkehrt - aber auch fehleranfällig, weil es Anomalien erzeugen
kann.


> Es muß text oder varchar sein und Kollation utf8.

text würde ich nur im absoluten Ausnahmefall nehmen - varchar ist i.a. zu
bevorzugen.

> Die numerierten Einträge in presskit und image habe ich so gemacht,
> weil ich genau weis, das da nichts mehr dazukommt. Vielleicht
> nicht genau im Sinne der 3. NF (ich weis schon, was das ist), aber für
> mich brauchbar. Da ich dort auch auch nur eine ID vergleiche, war das
> für mich kein Grund etwas zu ändern. Damit wird mein Server bestimmt
> nicht aussteigen. Beim Sortieren nach 4 vrachar(255) Feldern mit
> Kollation utf8 kann das wohl vorkommen, wie ich nach dem Posting von
> Kris nun weis. Das war mir vorher so nicht klar.

Also u.U. doch nicht brauchbar?

Manche Hinweise auf suboptimale Struktur sind - auch wenn sie zunächst
abwegig erscheinen - oft doch der Schlüssel zur Lösung.


Aber zurück zu Deinem Problem: Hilft es vielleicht, das Suchergebnis in
eine temporäre Tabelle zu schreiben und diese dann sortiert abzurufen?
Also

CREATE TEMPORARY TABLE tt (INDEX (text1,text2,text3,text4)) SELECT ...
FROM ...;
SELECT * FROM tt ORDER BY text1,text2,text3,text4;

(hier ist eine der Ausnahmen, wo SELECT * IMHO ok ist, da die Reihenfolge
unmittelbar davor ja festgelegt wurde)

Das entkoppelt die beiden Vorgänge, so daß der erste vielleicht
wesentlich schneller und unkomplizierter geht und seine Indizes optimal
nutzen kann, zweite sich hingegen gänzlich auf das Sortieren
konzentrieren kann.

Geht natürlich nur, wenn es nicht allzuviele Daten sind und entweder die
Tabelle gleich wieder weggeräumt wird oder aber die Verbindung ohnehin
getrennt wird.

Thomas
--
Wer lächelt, wenn etwas schiefgeht, weiß einen, den er dafür
verantwortlich machen kann.

Re: out of memory

Mathias Fiedler wrote:

> Ich danke Dir für Deine Ausführungen und möchte jetzt auch nicht weiter
> auf einzelne Punkte eingehen. Es ist aber numlal so, das meine Anwendung
> die Discographie einer Rockgruppe für ein Museum darstellt. Da diese
> Gruppe Ihre Platten von über 50 Labels hat produzieren lassen, auch im
> Ausland, kann die Datumsangabe variieren. Ein japanisches Datum sieht nun
> mal vollkommen anders aus als ein amerikanisches oder deutsches. Da die
> Leute dort absoluten Wert auf Autentizität legen, muß die Angabe in der
> Discographie genau der auf der Platte entsprechen. Das bedeutet, ich kann
> für das Release Datum kein Date Feld nehmen. Es muß text oder varchar sein
> und Kollation utf8. Unter mysql4 gab es keine kollation und es ging auch.
> Der Kunde nutzt aber mysql5 und schwört auf utf8, weil ihm das irgendwann
> mal einer schmackhaft gemacht hat.
> Die numerierten Einträge in presskit und image habe ich so gemacht, weil
> ich genau weis, das da nichts mehr dazukommt. Vielleicht nicht genau im
> Sinne der 3. NF (ich weis schon, was das ist), aber für mich brauchbar. Da
> ich dort auch auch nur eine ID vergleiche, war das für mich kein Grund
> etwas zu ändern. Damit wird mein Server bestimmt nicht aussteigen.
> Beim Sortieren nach 4 vrachar(255) Feldern mit Kollation utf8 kann das
> wohl vorkommen, wie ich nach dem Posting von Kris nun weis.
> Das war mir vorher so nicht klar. Für die Zukunft werde ich aber etwas
> besser darauf achten.
> Aber aus den Ausführungen zum Datum kannst Du schon erkennen, das eben ein
> date Feld dafür nicht geeignet ist. Das kann natürlich keiner wissen, der
> den Sachverhalt nicht kennt. Aber dann kann auch keiner sagen, Dein Modell
> ist scheiße. Da muß man zumindest doch mal Fragen, warum das so gemacht
> ist, bevor man beginnt, wild in der Gegend rumzuballern. Das ich dann
> sauer werde, dürfte wohl normal sein.

Bist Du absolut sicher, dass ein relationales Datenbanksystem für Deine
Anwendung das Mittel der Wahl ist?

Vielleicht hilft dies hier weiter:

http://www.allegro-c.de/a-r.htm

Auch der Link von dort zu den objektorientierten Datenbanksystemen könnte
nützlich sein (oder schau mal dieses Schlagwort in der Wikipedia nach, die
ist da wahrscheinlich aktueller).

Es geht in dem Text um ein Datenbanksystem, das hauptsächlich für
Bibliothekskataloge eingesetzt wird, aber keineswegs ausschließlich dafür
geeignet ist. Bücher sind ein wichtiges Beispiel für die Objekte, die sich
entsetzlich schlecht in das relationale Korsett pressen lassen, aber bei
weitem nicht das einzige. Deine Daten könnten in diese Kategorie gehören,
wie mir scheint.

Re: out of memory

Mathias Fiedler schrieb:
>>Hallo,
>>ich kann nur einen finden (gepostet am 3.10 um 19:55). Ich nehme an,
>>dass ist der zu MySql 5.
>>Kannst Du jetzt bitte noch den "alten" schicken, oder sagen, wo Du ihn
>>schon gepostet hast.
>>
>
> Der alte ist identisch ausser der Angabe der Kollation weil die in mysql4
> nicht unterstützt wird.
>
> mfg
>
> Mathias

Hy,
tja, in diesem Fall dürfte wohl das sortieren dieser utf8 Spalten mit
dem Kollation zusammen (deutlich) teurer sein, als ohne das Zeug.

Dann wäre mein Tipp. Schau Dir Spalte für Spalte in den diversen
Tabellen nochmal an und überlege, ob da wirklich thematisch fachlich
z.B. varchar(255) gebraucht wird.

Klar kann man z.B. bei der Spalte Wohnort sagen, woher soll ich wissen,
dass mir 100 Zeichen genügen. Vielleicht gibt es bald eine kleines Nest
irgendwo in .... dessen Name 500 Zeichen hat. ;-)

Trotzdem würde ich hier das Risiko eingehen und varchar(80) verwenden.

Ich weiss ja nicht, was genau in diesen Referenz-Spalten fachlich
drinsteht. Aber kann das wirklich mal 255 Zeichen bekommen? Und wenn
255, wieso dann nicht aus Vorsicht doch lieber 500?

Wenn Du sagst, bsiher genügt Dir an dieser Stelle varchar(80) dann nimm
das doch auch.
Zur allergrößten Not hilft Dir dann irgendwann entweder sinnvolles
abkürzen oder aber ein "alter table ... modify".

Schönes WE,
Michael

Re: out of memory

Am Fri, 06 Oct 2006 14:17:25 +0200 schrieb Hertha Steck:

> ist Du absolut sicher, dass ein relationales Datenbanksystem für Deine
> Anwendung das Mittel der Wahl ist?
>
> Vielleicht hilft dies hier weiter:
>
> http://www.allegro-c.de/a-r.htm

Ich habe es überflogen. Es scheint ein durchaus interessanter Ansatz zu
sein, jedoch mit großem Lernaufwand verbunden. Es handelt sich ja um ein
vollkommen anderes System. Ich werde es aber im Auge behalten und bei
Gelegenheit mal näher besehen. Mein Projekt ist übrigens fertig und
funktioniert.

mfg

Mathias

Re: out of memory

Am Fri, 06 Oct 2006 10:16:50 +0200 schrieb Thomas Rachel:

> Aber zurück zu Deinem Problem: Hilft es vielleicht, das Suchergebnis in
> eine temporäre Tabelle zu schreiben und diese dann sortiert abzurufen?
> Also
>
> CREATE TEMPORARY TABLE tt (INDEX (text1,text2,text3,text4)) SELECT ...
> FROM ...;
> SELECT * FROM tt ORDER BY text1,text2,text3,text4;
>
> (hier ist eine der Ausnahmen, wo SELECT * IMHO ok ist, da die Reihenfolge
> unmittelbar davor ja festgelegt wurde)

Danke für den Hinweis. In ähnlichen Situationen werde ich darauf
zurückgreifen. Momentan ist das Projekt abgeschlossen und funktioniert.

mfg

Mathias