From benedikt at quirmbach.de Thu Jun 1 11:02:06 2006 From: benedikt at quirmbach.de (Benedikt Quirmbach) Date: Thu, 1 Jun 2006 11:02:06 +0200 Subject: Leerzeichen verschwindet Message-ID: <34EEA922-7056-43BD-B0C4-9CCEC8F0956F@quirmbach.de> Hallo Liste, ich habe eine MySQL-Tabelle mit u.a. einem Feld: varchar(256). In dieses Feld schreibe ich per PHP einen neuen Inhalt, den ich aus einem HTML-Formular entnehme: "REPLACE INTO bestellungen SET text1='" . mysql_escape_string (urldecode($text1)) . "'... Wenn ich im Formular nur ein Leerzeichen eingebe, kommt dieses Leerzeichen in meinem php-Script auch an. In der mysql-Tabelle ist es aber nicht mehr vorhanden. Da bleibt das Feld leer bzw. wird geleert. Mit anderen Buchstaben oder mit Leerzeichen in Kombination mit anderen Buchstaben passiert das nicht. Kann mir jemand erklären, woran das liegt? Und was ich dagegen tun kann? Viele Grüße Benedikt -- Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter -->> http://www.4t2.com/mysql From technik at echtwahr.com Thu Jun 1 11:27:27 2006 From: technik at echtwahr.com (Technik via echtwahr.com - Neuer Server) Date: Thu, 1 Jun 2006 11:27:27 +0200 Subject: Leerzeichen verschwindet In-Reply-To: <34EEA922-7056-43BD-B0C4-9CCEC8F0956F@quirmbach.de> Message-ID: <000e01c6855d$998d12d0$1601a8c0@shivaball> Hallo Benedikt, > Kann mir jemand erklären, woran das liegt? Und was ich dagegen tun kann? Ja im Handbuch steht es: If you need a column for which trailing spaces are not removed, consider using a BLOB or TEXT type. If you want to store binary values such as results from an encryption or compression function that might contain arbitrary byte values, use a BLOB column rather than a CHAR or VARCHAR column, to avoid potential problems with trailing space removal that would change data values. Mit freundlichen Grüssen Thomas Goik -- Ihre Auktionsseiten im Internet http://www.auxion.de http://www.Xhammer.de -- Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter -->> http://www.4t2.com/mysql From benedikt at quirmbach.de Thu Jun 1 12:12:11 2006 From: benedikt at quirmbach.de (Benedikt Quirmbach) Date: Thu, 1 Jun 2006 12:12:11 +0200 Subject: Leerzeichen verschwindet In-Reply-To: <000e01c6855d$998d12d0$1601a8c0@shivaball> References: <000e01c6855d$998d12d0$1601a8c0@shivaball> Message-ID: <26628BF3-FCE3-44BC-9CCB-247103F57710@quirmbach.de> Danke, Thomas! Die Stelle hatte ich in der Doku nicht gefunden. Ich hatte auch nicht gedacht, dass in einem solchen Feld standardmäßig führende Leerzeichen ausgefiltert werden.. Am 01.06.2006 um 11:27 schrieb Technik via echtwahr.com - Neuer Server: > Hallo Benedikt, > >> Kann mir jemand erklären, woran das liegt? Und was ich dagegen tun >> kann? > > Ja im Handbuch steht es: > If you need a column for which trailing spaces are not removed, > consider > using a BLOB or TEXT type. If you want to store binary values such as > results from an encryption or compression function that might contain > arbitrary byte values, use a BLOB column rather than a CHAR or VARCHAR > column, to avoid potential problems with trailing space removal > that would > change data values. > > > > > Mit freundlichen Grüssen > Thomas Goik > > -- > Ihre Auktionsseiten im Internet > http://www.auxion.de > http://www.Xhammer.de > > > > -- > Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter > -->> http://www.4t2.com/mysql > -- Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter -->> http://www.4t2.com/mysql From o.wiemer at audiovisuellemedien.de Thu Jun 1 13:36:27 2006 From: o.wiemer at audiovisuellemedien.de (Oliver Wiemer) Date: Thu, 01 Jun 2006 13:36:27 +0200 Subject: Unknown column Message-ID: <447ED13B.4@audiovisuellemedien.de> Ich habe ein kleines Problemchen, was vermutlich am Syntax liegt. Das ganze läuft unter mysql 4xx. Mit einer 5.0.21 kommt folgender Fehler. SELECT * FROM rrartikel_kategorie ak, rrartikel a LEFT OUTER JOIN rrartikel_optionen ao ON ao.FK_Artikel_ID = ak.FK_Artikel_ID LEFT OUTER JOIN rrartikel_variationen av ON av.FK_Artikel_ID = ak.FK_Artikel_ID where FK_Kategorie_ID = '28' and ak.FK_Artikel_ID = a.Artikel_ID and a.SperreD < '1' ORDER BY ak.Pos, a.NameD ASC Unknown column 'ak.FK_Artikel_ID' in 'on clause' Sieht jemand den Fehler? Viele Grüße Olli -- Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter -->> http://www.4t2.com/mysql From norbert at itbw.de Thu Jun 1 13:51:27 2006 From: norbert at itbw.de (Norbert Pfeiffer) Date: Thu, 1 Jun 2006 13:51:27 +0200 Subject: Leerzeichen verschwindet References: <000e01c6855d$998d12d0$1601a8c0@shivaball> Message-ID: <001301c68571$b8edd1f0$6502a8c0@PFEIFFER> Hallo Thomas, > Ja im Handbuch steht es: > If you need a column for which trailing spaces are not removed, consider > using a BLOB or TEXT type. If you want to store binary values such as > results from an encryption or compression function that might contain > arbitrary byte values, use a BLOB column rather than a CHAR or VARCHAR > column, to avoid potential problems with trailing space removal that would > change data values. hmm, hast Du dazu eine Kapitel- oder Abschnitts-Ueberschrift. Sonst findet man das ja nie ... m. b. G. N. Pfeiffer --------------------- normal: 06131-1436094 Notruf: 0163-3613642 --------------------- e.o.f. -- Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter -->> http://www.4t2.com/mysql From lists at sebastianmendel.de Thu Jun 1 14:08:08 2006 From: lists at sebastianmendel.de (Sebastian Mendel) Date: Thu, 01 Jun 2006 14:08:08 +0200 Subject: Leerzeichen verschwindet In-Reply-To: <001301c68571$b8edd1f0$6502a8c0@PFEIFFER> References: <000e01c6855d$998d12d0$1601a8c0@shivaball> <001301c68571$b8edd1f0$6502a8c0@PFEIFFER> Message-ID: <447ED8A8.8030603@sebastianmendel.de> Norbert Pfeiffer schrieb: > Hallo Thomas, > >> Ja im Handbuch steht es: >> If you need a column for which trailing spaces are not removed, consider >> using a BLOB or TEXT type. If you want to store binary values such as >> results from an encryption or compression function that might contain >> arbitrary byte values, use a BLOB column rather than a CHAR or VARCHAR >> column, to avoid potential problems with trailing space removal that >> would >> change data values. > hmm, > hast Du dazu eine Kapitel- oder Abschnitts-Ueberschrift. > Sonst findet man das ja nie ... steht direkt bei der Beschreibung zum varchar: http://dev.mysql.com/doc/refman/5.0/en/char.html 6. Absatz: "VARCHAR values are not padded when they are stored. Handling of trailing spaces is version-dependent. As of MySQL 5.0.3, trailing spaces are retained when values are stored and retrieved, in conformance with standard SQL. Before MySQL 5.0.3, trailing spaces are removed from values when they are stored into a VARCHAR column; this means that the spaces also are absent from retrieved values." ebenso http://dev.mysql.com/doc/refman/4.1/en/char.html 6. Absatz: "VARCHAR values are not padded when they are stored. Trailing spaces in MySQL version up to and including 4.1 are removed from values when stored in a VARCHAR column; this also means that the spaces are absent from retrieved values." -- Sebastian -- Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter -->> http://www.4t2.com/mysql From daur at so-nso.de Fri Jun 2 18:25:46 2006 From: daur at so-nso.de (Tobias Daur) Date: Fri, 02 Jun 2006 18:25:46 +0200 Subject: update mit ermittelten werten in einer query In-Reply-To: <447D3989.4080907@sebastianmendel.de> References: <1148816398.3729.108.camel@laptd> <1149024394.1503.21.camel@laptd> <447D3989.4080907@sebastianmendel.de> Message-ID: <1149265546.1753.60.camel@laptd> > du hattest leider nicht geschrieben welche MySQL Version du einsetzt ... > und traurige Wahrheit ist nunmal das immer noch viele auf 4.0 oder 3 Right: Erst wenn man die Lösung für ein Problem hat, weiß man, wie die Frage lautet. Kaum war ich bei den Subselects angekommen, war mir klar, daß ich "4.1" hätte rufen sollen ;=) Immerhin bin ich damit nicht allein - schließlich war beim Anhalter die Antwort 42 auch da, bevor die Frage gesucht wurde ... cu Tobias -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : nicht verfügbar Dateityp : application/pgp-signature Dateigröße : 189 bytes Beschreibung: Dies ist ein digital signierter Nachrichtenteil URL : http://lists.mushaake.org/pipermail/mysql-de/attachments/20060602/ca3def75/attachment.bin From driessen at edv-driessen.de Mon Jun 12 23:39:22 2006 From: driessen at edv-driessen.de (Uwe Driessen) Date: Mon, 12 Jun 2006 23:39:22 +0200 Subject: AW: Log Dateien bearbeiten In-Reply-To: <448DC792.6050102@kiel-media.de> Message-ID: <000f01c68e68$ab985cf0$0565a8c0@uwe> > Betreff: Re: Log Dateien bearbeiten Mit binären Daten kenne ich mich nicht aus läuft allerding Mysql im Debug mode dann kannste jedes einzelne SQL Statment sehen und entsprechend bearbeiten und evtl. auch wieder reparieren gilt aber nur für die Statements selber wenn da ein Delete where drinne ist die daten sind wech. Habe mir gerade mal die Binäries angeschaut für die gilt das selbe wenn ich das richtige sehe. Einzige chance die ich sehe ist alles in einen nachvollziehbaren zustand bringen (letztes Backup) die Binaries so bearbeiten das du die dann wieder bis vor den Spielereien in die Datenbank auf einer 2. maschine wieder aufbaust und dann mit der Originalen vergleichst. Sollte die Möglichkeit sein die am meisten erfolg verspricht. Wenn die Schweizer Nummernkonten von deinem Chef gelöscht hat hilft eh nur flucht *gg Mit freundlichen Grüßen Uwe -- Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter -->> http://www.4t2.com/mysql From mysql at universalware.de Mon Jun 12 23:53:45 2006 From: mysql at universalware.de (=?iso-8859-1?Q?Andreas_M=FCller?=) Date: Mon, 12 Jun 2006 23:53:45 +0200 Subject: Log Dateien bearbeiten In-Reply-To: <000f01c68e68$ab985cf0$0565a8c0@uwe> Message-ID: <005101c68e6a$ae3e8bd0$1400a8c0@nbandreas> Hallo, also da gibt es eigentlich eine einfache Lösung: - das Log mit dem Programm mysqlbinlog als SQL Script ausgeben lassen # mysqlbinlog -s logfile-bin.xxxx > script.sql - das Script bearbeiten # vi script.sql - das bearbeitete Script mit mysql weiterverarbeiten # mysql > http://www.4t2.com/mysql From andreas.kretschmer at schollglas.com Tue Jun 13 06:56:18 2006 From: andreas.kretschmer at schollglas.com (Andreas Kretschmer) Date: Tue, 13 Jun 2006 06:56:18 +0200 Subject: Log Dateien bearbeiten In-Reply-To: <448DC792.6050102@kiel-media.de> References: <448DC792.6050102@kiel-media.de> Message-ID: <20060613045618.GA26979@webserv.wug-glas.de> am 12.06.2006, um 21:59:14 +0200 mailte Henning Evers folgendes: > Hi Matthias, > zur Sache selbst kann ich nichts sagen, allerdings sind html-Mails auf der > Liste nicht gern gesehen. > > Danke, > Henning > > > Matthias Köstler schrieb: > >Hallo, TOFU auch. Andreas -- Andreas Kretschmer (Kontakt: siehe Header) Heynitz: 035242/47215, D1: 0160/7141639 GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net === Schollglas Unternehmensgruppe === -- Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter -->> http://www.4t2.com/mysql From norbert at itbw.de Tue Jun 13 08:07:29 2006 From: norbert at itbw.de (Norbert Pfeiffer) Date: Tue, 13 Jun 2006 08:07:29 +0200 Subject: Tabelle voll - was nun ... Message-ID: <000501c68eaf$ab427c80$6502a8c0@PFEIFFER> Hallo, beim Stand von 16.268.486 Reccords in 'tblsignal' from 'xtractit' bekomme ich von MySQL nur noch eine Meldung "Error - table voll". Weitere Daten: tblsignal.MYD - 4.294.967.288 Bytes, Plattenausnutzung 41,3% Gibt es da noch varianten um weiter zu machen, oder ist hier bei MySQL definitiv Schluss ... m. b. G. N. Pfeiffer --------------------- normal: 06131-1436094 Notruf: 0163-3613642 --------------------- e.o.f. -- Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter -->> http://www.4t2.com/mysql From andreas.kretschmer at schollglas.com Tue Jun 13 08:19:15 2006 From: andreas.kretschmer at schollglas.com (Andreas Kretschmer) Date: Tue, 13 Jun 2006 08:19:15 +0200 Subject: Tabelle voll - was nun ... In-Reply-To: <000501c68eaf$ab427c80$6502a8c0@PFEIFFER> References: <000501c68eaf$ab427c80$6502a8c0@PFEIFFER> Message-ID: <20060613061914.GD26979@webserv.wug-glas.de> am 13.06.2006, um 8:07:29 +0200 mailte Norbert Pfeiffer folgendes: > Hallo, > > beim Stand von 16.268.486 Reccords in 'tblsignal' from 'xtractit' > bekomme ich von MySQL nur noch eine Meldung "Error - table voll". > Weitere Daten: > tblsignal.MYD - 4.294.967.288 Bytes, Plattenausnutzung 41,3% 4 GByte? Filesystemlimit? > > Gibt es da noch varianten um weiter zu machen, oder ist hier > bei MySQL definitiv Schluss ... vielleicht auch das... Andreas -- Andreas Kretschmer (Kontakt: siehe Header) Heynitz: 035242/47215, D1: 0160/7141639 GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net === Schollglas Unternehmensgruppe === -- Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter -->> http://www.4t2.com/mysql From lists at sebastianmendel.de Tue Jun 13 09:39:19 2006 From: lists at sebastianmendel.de (Sebastian Mendel) Date: Tue, 13 Jun 2006 09:39:19 +0200 Subject: Tabelle voll - was nun ... In-Reply-To: <000501c68eaf$ab427c80$6502a8c0@PFEIFFER> References: <000501c68eaf$ab427c80$6502a8c0@PFEIFFER> Message-ID: <448E6BA7.3060107@sebastianmendel.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Norbert Pfeiffer schrieb: > Hallo, > > beim Stand von 16.268.486 Reccords in 'tblsignal' from 'xtractit' > bekomme ich von MySQL nur noch eine Meldung "Error - table voll". > Weitere Daten: > tblsignal.MYD - 4.294.967.288 Bytes, Plattenausnutzung 41,3% das müsste eher am OS liegen, z.B. Linux 2.2 oder Win mit FAT(32) > Gibt es da noch varianten um weiter zu machen, oder ist hier > bei MySQL definitiv Schluss ... nein, MySQL kann mehr, außer du hast noch eine 3.22 Version ... ;-) http://dev.mysql.com/doc/refman/5.0/en/table-size.html - -- Sebastian Mendel www.sebastianmendel.de -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) iD8DBQFEjmunX/0lClpZDr4RAlwdAJ42q7J8klYvqqVTdEs9EkpjmS0IoQCgsDBC bp+bESzkucb/M05ASOvAuSA= =akhO -----END PGP SIGNATURE----- -- Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter -->> http://www.4t2.com/mysql From norbert at itbw.de Tue Jun 13 09:54:55 2006 From: norbert at itbw.de (Norbert Pfeiffer) Date: Tue, 13 Jun 2006 09:54:55 +0200 Subject: Tabelle voll - was nun ... References: Message-ID: <004001c68ebe$af596680$6502a8c0@PFEIFFER> Hai, > was hast du denn da für eine struktur ? hmm, nix besonderes, eine auto_incrment-Spalte, der Rest sind int-, varchar- und text-Felder. > hast du schon mal nach winzigen fehlerchen geschaut ? hmm, keine Ahnung was Du meinst ... > index ok ? davon gehe ich aus, da Selects problemlos funktionieren. "ORDER BY idx" ist vielmals schneller als "ORDER BY asd" m. b. G. N. Pfeiffer --------------------- normal: 06131-1436094 Notruf: 0163-3613642 --------------------- e.o.f. -- Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter -->> http://www.4t2.com/mysql From norbert at itbw.de Tue Jun 13 10:20:24 2006 From: norbert at itbw.de (Norbert Pfeiffer) Date: Tue, 13 Jun 2006 10:20:24 +0200 Subject: Tabelle voll - was nun ... References: <000501c68eaf$ab427c80$6502a8c0@PFEIFFER> <448E6BA7.3060107@sebastianmendel.de> Message-ID: <005601c68ec2$4c62a290$6502a8c0@PFEIFFER> Hi Sebastian, was ich habe steht nicht zur Debatte, das laeuft in der Firma. Und die Firma hat XP Prof, NTFS und MySQL 4.0 local. Online laeuft MySQL/4.1.10a unter Linux 2.6.11.4-20a-smp. Laut http://dev.mysql.com/doc/refman/5.0/en/table-size.html sollte es das Problem also gar nicht geben tun ... Und nun Du wieder ... m. b. G. N. Pfeiffer --------------------- normal: 06131-1436094 Notruf: 0163-3613642 --------------------- e.o.f. -- Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter -->> http://www.4t2.com/mysql From lists at sebastianmendel.de Tue Jun 13 11:21:27 2006 From: lists at sebastianmendel.de (Sebastian Mendel) Date: Tue, 13 Jun 2006 11:21:27 +0200 Subject: Tabelle voll - was nun ... In-Reply-To: <005601c68ec2$4c62a290$6502a8c0@PFEIFFER> References: <000501c68eaf$ab427c80$6502a8c0@PFEIFFER> <448E6BA7.3060107@sebastianmendel.de> <005601c68ec2$4c62a290$6502a8c0@PFEIFFER> Message-ID: <448E8397.2070503@sebastianmendel.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Norbert Pfeiffer schrieb: > Hi Sebastian, > > was ich habe steht nicht zur Debatte, das laeuft in der Firma. "außer du hast noch eine 3.22 Version ... ;-) " ... mit der du in deiner Firma zurechtkommen musst. zieh dich doch nicht an solchen Formulierungen hoch, du weißt doch genau was ich gemeint habe, was du hast interessiert mich natürlich auch einen scheisdreck - es ging natürlich um die Verwendete MySQL Version und Umgebung - vollkommen irrelevant ob die bei dir in irgendeiner Firma oder auf dem Mond läuft. > Und die Firma hat XP Prof, NTFS und MySQL 4.0 local. > Online laeuft MySQL/4.1.10a unter Linux 2.6.11.4-20a-smp. > Laut http://dev.mysql.com/doc/refman/5.0/en/table-size.html > sollte es das Problem also gar nicht geben tun ... > > Und nun Du wieder ... Ja und der Tabellentyp? Und hast du die Seite mal durchgelesen wozu ich den Link geschickt habe? Und warum schriebst du gleich der Einfachheit halber welche Version Verwendung findet (an welchem Ort auch und bei wem auch immer) " By default, MySQL creates MyISAM tables with an internal structure that allows a maximum size of about 4GB. You can check the maximum table size for a MyISAM table with the SHOW TABLE STATUS statement or with myisamchk -dv tbl_name. See Section 13.5.4, ?SHOW Syntax?. If you need a MyISAM table that is larger than 4GB and your operating system supports large files, the CREATE TABLE statement supports AVG_ROW_LENGTH and MAX_ROWS options. See Section 13.1.5, ?CREATE TABLE Syntax?. You can also change these options with ALTER TABLE to increase a table's maximum allowable size after the table has been created. See Section 13.1.2, ?ALTER TABLE Syntax?. " http://dev.mysql.com/doc/refman/5.0/en/table-size.html - -- Sebastian Mendel www.sebastianmendel.de -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) iD8DBQFEjoOXX/0lClpZDr4RAq0CAKCQmPhwkrqFAK3R9ECXnm5HXey6wACgrVeo sCqo7e+NQ1PcFRa9oARs8A0= =pPgy -----END PGP SIGNATURE----- -- Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter -->> http://www.4t2.com/mysql From lists at sebastianmendel.de Tue Jun 13 14:08:52 2006 From: lists at sebastianmendel.de (Sebastian Mendel) Date: Tue, 13 Jun 2006 14:08:52 +0200 Subject: Tabelle voll - was nun ... In-Reply-To: <448E8397.2070503@sebastianmendel.de> References: <000501c68eaf$ab427c80$6502a8c0@PFEIFFER> <448E6BA7.3060107@sebastianmendel.de> <005601c68ec2$4c62a290$6502a8c0@PFEIFFER> <448E8397.2070503@sebastianmendel.de> Message-ID: <448EAAD4.2040600@sebastianmendel.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sebastian Mendel schrieb: > " By default, MySQL creates MyISAM tables with an internal structure > that allows a maximum size of about 4GB. You can check the maximum table > size for a MyISAM table with the SHOW TABLE STATUS statement or with > myisamchk -dv tbl_name. See Section 13.5.4, ?SHOW Syntax?. > > If you need a MyISAM table that is larger than 4GB and your operating > system supports large files, the CREATE TABLE statement supports > AVG_ROW_LENGTH and MAX_ROWS options. See Section 13.1.5, ?CREATE TABLE > Syntax?. You can also change these options with ALTER TABLE to increase > a table's maximum allowable size after the table has been created. See > Section 13.1.2, ?ALTER TABLE Syntax?. " > > http://dev.mysql.com/doc/refman/5.0/en/table-size.html Und? Konntest du Tabelle ändern so das sie jetzt größer als 4GB werden kann? - -- Sebastian Mendel www.sebastianmendel.de -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) iD8DBQFEjqrUX/0lClpZDr4RAnovAJ9eFDutYAOBN+vfh9Sac1OFRuyYBQCfYPNC HsqnLnP5lbLjNNlACVs3vRA= =ObLw -----END PGP SIGNATURE----- -- Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter -->> http://www.4t2.com/mysql From norbert at itbw.de Tue Jun 13 12:48:48 2006 From: norbert at itbw.de (Norbert Pfeiffer) Date: Tue, 13 Jun 2006 12:48:48 +0200 Subject: Tabelle voll - was nun ... References: <000501c68eaf$ab427c80$6502a8c0@PFEIFFER> <448E6BA7.3060107@sebastianmendel.de> <005601c68ec2$4c62a290$6502a8c0@PFEIFFER> <448E8397.2070503@sebastianmendel.de> Message-ID: <001201c68eea$d5eae3b0$6502a8c0@PFEIFFER> Hi Sebastian, > zieh dich doch nicht an solchen Formulierungen hoch ... f.f. rofl > Ja und der Tabellentyp? wieso, der ist default MyISAM, wer sollte den, und warum, aendern. > Und warum schriebst du gleich der Einfachheit halber welche > Version Verwendung findet ... hmm, weil ich Dir die Gelegenheit nehmen wollte, danach zu fragen. Da sich das Problem komplizierter als angenommen gestaltet, wurde eine Loesung ohne fachmaennische Verwirrung gefunden. Wir teilen die Tabelle monatsweise auf ... Also schlaf weiter ... ;-) m. b. G. N. Pfeiffer --------------------- normal: 06131-1436094 Notruf: 0163-3613642 --------------------- e.o.f. -- Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter -->> http://www.4t2.com/mysql From driessen at edv-driessen.de Tue Jun 13 15:27:36 2006 From: driessen at edv-driessen.de (Uwe Driessen) Date: Tue, 13 Jun 2006 15:27:36 +0200 Subject: AW: Tabelle voll - was nun ... In-Reply-To: <001201c68eea$d5eae3b0$6502a8c0@PFEIFFER> Message-ID: <003f01c68eed$22e03470$0565a8c0@uwe> Hallo Norbert > > zieh dich doch nicht an solchen Formulierungen hoch ... f.f. > rofl Seid nett zu einander > > > Ja und der Tabellentyp? > wieso, > der ist default MyISAM, wer sollte den, und warum, aendern. Du weil dann mehr in die Tabelle passt *gg > Da sich das Problem komplizierter als angenommen gestaltet, > wurde eine Loesung ohne fachmaennische Verwirrung gefunden. > Wir teilen die Tabelle monatsweise auf ... Jo so kann man das auch lösen *gg Mit freundlichen Grüßen Uwe Drießen -- Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter -->> http://www.4t2.com/mysql From norbert at itbw.de Tue Jun 13 17:01:23 2006 From: norbert at itbw.de (Norbert Pfeiffer) Date: Tue, 13 Jun 2006 17:01:23 +0200 Subject: Tabelle voll - was nun ... References: <003f01c68eed$22e03470$0565a8c0@uwe> Message-ID: <004d01c68efa$470e3740$6502a8c0@PFEIFFER> Hallo Uwe, > > > zieh dich doch nicht an solchen Formulierungen hoch ... f.f. > > rofl > Seid nett zu einander sind wir doch, willst Du mal Posts sehen, die wir selbst zensiert haben ... ;-) > > > Ja und der Tabellentyp? > > wieso, > > der ist default MyISAM, wer sollte den, und warum, aendern. > Du weil dann mehr in die Tabelle passt *gg grien, InnoDB habe ich unter Windoof noch nirgends flott laufen sehen und langsam kann MyISAM auch: ALTER TABLE tblSignal CHANGE strTimeStamp dTimeStamp datetime; Query OK, 16268486 rows affected (12 min 35.61 sec) Datensätze: 16268486 Duplikate: 0 Warnungen: 0 ALTER TABLE tblSignal ADD KEY(dTimeStamp); Query OK, 16268486 rows affected (19 min 27.44 sec) Datensätze: 16268486 Duplikate: 0 Warnungen: 0 > > Wir teilen die Tabelle monatsweise auf ... > Jo so kann man das auch lösen *gg na-ja, wenn man sich die Werte oben anschaut, erlaubt das zwar ein erholsames Arbeiten, aber richtig okay ist das weniger ... m. b. G. N. Pfeiffer --------------------- normal: 06131-1436094 Notruf: 0163-3613642 --------------------- e.o.f. -- Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter -->> http://www.4t2.com/mysql From mysql at universalware.de Tue Jun 13 17:25:09 2006 From: mysql at universalware.de (=?iso-8859-1?Q?Andreas_M=FCller?=) Date: Tue, 13 Jun 2006 17:25:09 +0200 Subject: Tabelle voll - was nun ... In-Reply-To: <004d01c68efa$470e3740$6502a8c0@PFEIFFER> Message-ID: <050501c68efd$9420b780$1400a8c0@nbandreas> Hallo Norbert, > InnoDB habe ich unter Windoof noch nirgends flott laufen sehen > und langsam kann MyISAM auch: InnoDB läuft bei mir auf einer 40 GB Datenbank unter Windows richtig flott. Die befürchteten Performanceeinbusen bei der Umstellung von MyISAM auf InnoDB waren nicht zu verzeichnen. Die Datenbank enthält einige Tabellen zwischen 10 und 30 Millionen Datensätze. Der benötigte Plattenplatz liegt je nach Daten beim Faktor 2 bis 2,5 von MyISAM Tabellen. Da InnoDB auch Nutz-Daten und nicht nur Index-Daten wie MyISAM cacht lohnt es sich hier die InnoDB Puffer etwas höher zu wählen als bei MyISAM (so Faktor 1,5 bis 2). Bei solch einer Umstellung sollte man prüfen ob anschließend noch MyISAM Tabellen verwendet werden auf dem Server und den Key-Buffer entsprechend reduzieren - der würde sonst brach liegen und nur RM verschwenden. > ALTER TABLE tblSignal CHANGE strTimeStamp dTimeStamp datetime; > Query OK, 16268486 rows affected (12 min 35.61 sec) > Datensätze: 16268486 Duplikate: 0 Warnungen: 0 > > ALTER TABLE tblSignal ADD KEY(dTimeStamp); > Query OK, 16268486 rows affected (19 min 27.44 sec) > Datensätze: 16268486 Duplikate: 0 Warnungen: 0 Das diese Statements langsam sind liegt an der Art und Weise wie MyISAM mit Strukturänderungen umgeht. Dazu baut MyISAM zunächst eine temporäre Tabelle auf in dem es die Daten aus der originalen Tabelle kopiert und baut danach im Fall von Index Änderungen alle Indices nacheinander neu auf. Seit 4.1 kommt es mir vor als ob er wenigstens ab und an so schlau ist und bestehende Indices nur umkopiert und nicht neu sortiert. Ab MySQL 5.0 bzw. 5.1 soll sich da noch einiges getan haben sowas solche banalen Änderungen schneller von statten gehen. Gruß, Andreas -- Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter -->> http://www.4t2.com/mysql From driessen at edv-driessen.de Tue Jun 13 18:01:43 2006 From: driessen at edv-driessen.de (Uwe Driessen) Date: Tue, 13 Jun 2006 18:01:43 +0200 Subject: AW: Tabelle voll - was nun ... In-Reply-To: <004d01c68efa$470e3740$6502a8c0@PFEIFFER> Message-ID: <004301c68f02$aa950fc0$0565a8c0@uwe> Hallo Norbert Nee was zensiert wurde will ich gar nicht sehen aber zeigt das der Wortfilter funktioniert. > > > der ist default MyISAM, wer sollte den, und warum, aendern. > > Du weil dann mehr in die Tabelle passt *gg > grien, > InnoDB habe ich unter Windoof noch nirgends flott laufen sehen > und langsam kann MyISAM auch: Auf die Dauer hilft nur power power power *g Wie wäre es bei den Datenmengen mal mit nem schönen schnellen Raid und ner anständigen Maschine mit Ram satt und Prozz. Leistung satt Oder willste immer Kaffee zwischendurch kochen gehen > > ALTER TABLE tblSignal CHANGE strTimeStamp dTimeStamp datetime; > Query OK, 16268486 rows affected (12 min 35.61 sec) > Datensätze: 16268486 Duplikate: 0 Warnungen: 0 > > ALTER TABLE tblSignal ADD KEY(dTimeStamp); > Query OK, 16268486 rows affected (19 min 27.44 sec) > Datensätze: 16268486 Duplikate: 0 Warnungen: 0 > Mit freundlichen Grüßen Uwe Drießen -- Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter -->> http://www.4t2.com/mysql From norbert at itbw.de Tue Jun 13 19:21:09 2006 From: norbert at itbw.de (Norbert Pfeiffer) Date: Tue, 13 Jun 2006 19:21:09 +0200 Subject: Tabelle voll - was nun ... References: <004301c68f02$aa950fc0$0565a8c0@uwe> Message-ID: <000401c68f0d$e02cb150$6502a8c0@PFEIFFER> Hallo, > Nee was zensiert wurde will ich gar nicht sehen aber > zeigt das der Wortfilter funktioniert. nee, es hiess ja Selbstzensur, oder traust Du mir nicht zu, einen bloeden Wortfilter auszutricksen ... > Auf die Dauer hilft nur power power power *g genau, ich habe Oracle-DB's gesehen, die haben jede MySQL-DB wie eine Oma mit Gehhilfe erscheinen lassen, aber der Rechner passte auch unter keinen Schreibtisch ... Vielleicht liest Andreas dies ja noch, dann koennte er etwas zu diesen Zahlen sagen. In den Klammern stehen die transferierten Records und dahinter die Zeit in ms. Das sind die einzelnen INSERT ... SELECT'S fuer eine monatsweise Aufteilung: ----------------------------------------- tblMess200404 [ 677] 113.592,257 ms tblMess200405 [ 38] 110.332,322 ms tblMess200406 [ 213] 113.222,906 ms tblMess200407 [ 777.983] 155.006,859 ms tblMess200408 [ 780.297] 173.189,429 ms tblMess200409 [ 784.425] 128.730,820 ms tblMess200410 [ 844.619] 134.826,306 ms tblMess200411 [ 766.082] 126.650,940 ms tblMess200412 [ 690.361] 129.391,962 ms tblMess200501 [ 876.450] 137.157,942 ms tblMess200502 [1.158.705] 150.941,615 ms tblMess200503 [ 893.055] 136.689,012 ms tblMess200504 [1.060.131] 141.987,725 ms tblMess200505 [1.177.963] 146.664,244 ms tblMess200506 [ 969.928] 139.846,733 ms tblMess200507 [ 862.068] 118.658,117 ms tblMess200508 [ 843.615] 110.599,296 ms tblMess200509 [ 867.846] 125.019,157 ms tblMess200510 [ 968.160] 147.357,750 ms tblMess200511 [ 819.445] 129.076,082 ms tblMess200512 [ 812.269] 156.610,316 ms tblMess200601 [ 191.701] 114.188,460 ms tblMess200602 [ 0] 112.224,316 ms tblMess200603 [ 0] 113.869,974 ms tblMess200604 [ 0] 111.348,056 ms tblMess200605 [ 0] 112.936,735 ms tblMess200606 [ 0] 109.195,142 ms ----------------------------------------- m. b. G. N. Pfeiffer --------------------- normal: 06131-1436094 Notruf: 0163-3613642 --------------------- e.o.f. -- Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter -->> http://www.4t2.com/mysql From mysql at universalware.de Tue Jun 13 20:41:15 2006 From: mysql at universalware.de (=?iso-8859-1?Q?Andreas_M=FCller?=) Date: Tue, 13 Jun 2006 20:41:15 +0200 Subject: Tabelle voll - was nun ... In-Reply-To: <000401c68f0d$e02cb150$6502a8c0@PFEIFFER> Message-ID: <053701c68f18$f460ced0$1400a8c0@nbandreas> Hallo Norbert, > Vielleicht liest Andreas dies ja noch, dann koennte er > etwas zu diesen Zahlen sagen. In den Klammern stehen > die transferierten Records und dahinter die Zeit in ms. > Das sind die einzelnen INSERT ... SELECT'S fuer eine > monatsweise Aufteilung: Jo der liest das noch :-) Also ich nehme mal an es geht da um die 16 Millionen Tabelle a 4 GB. Und ich nehme weiter an das Statement sah jeweils so aus: INSERT INTO table(fieldlist) SELECT fieldlist FROM fulltable WHERE date>='xxxx-xx-xx' and date<='xxxx-xxx-xx' Stutzig macht mach vor allem die relativ lange Laufzeit obwohl die Ergebnismenge leer ist. Das sieht sehr danach aus das der Key nicht optimal genutzt werden kann. Da wäre es sicher besser gewesen den alten Datentyp varchar (?) beizubehalten und mit LIKE 'xxxx-xx-%' die Monate zu trennen. Gruß, Andreas -- Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter -->> http://www.4t2.com/mysql From norbert at itbw.de Tue Jun 13 21:44:50 2006 From: norbert at itbw.de (Norbert Pfeiffer) Date: Tue, 13 Jun 2006 21:44:50 +0200 Subject: Tabelle voll - was nun ... References: <053701c68f18$f460ced0$1400a8c0@nbandreas> Message-ID: <005d01c68f22$7aa4f990$16b2a8c0@LionPC> Hallo Andreas, > Jo der liest das noch :-) prima > Also ich nehme mal an es geht da um die 16 Millionen > Tabelle a 4 GB. Und ich nehme weiter an das Statement > sah jeweils so aus: > INSERT INTO table(fieldlist) > SELECT fieldlist > FROM fulltable > WHERE date>='xxxx-xx-xx' and date<='xxxx-xxx-xx' hmm, genauer so: INSERT INTO table(fieldlist) SELECT fieldlist FROM fulltable WHERE YEAR(datum)='xxxx' AND MONTH(datum)='xx'; Dafuer habe ich ja extra das Feld konvertiert und indiziert, weil ich vorher gemerkt hatte, dass ein ORDER BY datumsstring einen einfachen SELECT auf 5 Minuten ausweitet. In sofern sind 2 Minuten schon ein Erfolg. Dass MySQL den Index nicht ordentlich nutzen kann, wird stimmen. Vielleicht haette man: KEY 'aa' (YEAR(datum)) KEY 'bb' (MONTH(datum)) setzen sollen, werde ich morgen(other) mal testen. m. b. G. Norbert ___________________ t-net 06131-6192673 eplus 0163-3613642 ------------------- e.o.m. -- Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter -->> http://www.4t2.com/mysql From mysql at universalware.de Tue Jun 13 22:12:28 2006 From: mysql at universalware.de (=?iso-8859-1?Q?Andreas_M=FCller?=) Date: Tue, 13 Jun 2006 22:12:28 +0200 Subject: Tabelle voll - was nun ... In-Reply-To: <005d01c68f22$7aa4f990$16b2a8c0@LionPC> Message-ID: <055c01c68f25$b210b880$1400a8c0@nbandreas> Hallo Norbert, da bleibt mir erstmal ein lautes ohhhjeee ... Also MySQL und auch fast alle anderen RDBMS können Funktionsaufrufe nicht optimieren. Daher ist es absolut zu vermeiden Methodenaufrufe zu verwenden wenn man Ranges wie in dem Beispiel hier verwenden kann. Eine Query SELECT * FROM fulltable WHERE Year(datum)='2006' and Month(datum)='01' ist IMMER ein nicht optimierbarer Full-Table-Scan. D.h. jeder Datensatz muss angefasst und geprüft werden. Die Abfrage SELECT * FROM fulltable WHERE datum>='2006-01-02' and datum<='2006-01-31' ist dagegen sehr gut optimierbar wenn ein Index über das Feld 'datum' existiert. Für den Fall (und so war es ja anfangs bei dir) das das Datum sogar in einem varchar Feld gespeichert ist kann man auch folgendes verwenden: SELECT * FROM fulltable WHERE datum LIKE '2006-01-%' Erstaunlicherweise ist das sogar manchmal schneller als die Range über das Datum. Warum? Darüber kann man spekulieren oder den Code lesen. Ich vermute mal das ein String Range besser optimiert ist als ein Date-Range. Gruß, Andreas -- Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter -->> http://www.4t2.com/mysql From norbert at itbw.de Tue Jun 13 22:48:54 2006 From: norbert at itbw.de (Norbert Pfeiffer) Date: Tue, 13 Jun 2006 22:48:54 +0200 Subject: Tabelle voll - was nun ... References: <055c01c68f25$b210b880$1400a8c0@nbandreas> Message-ID: <006f01c68f2a$cd2f37e0$16b2a8c0@LionPC> Hallo Andreas, danke, habe ich wieder was gelernt, und das in meinem Alter ... ;-) > da bleibt mir erstmal ein lautes ohhhjeee ... hmm, stell Dir vor, alle wuessten, was Du weisst. Dich wuerde die blanke Langeweile umtreiben, willst Du das, na also ... ;-) Okay, mache ich einen String draus und poste das Ergebnis. m. b. G. Norbert ___________________ t-net 06131-6192673 eplus 0163-3613642 ------------------- e.o.m. -- Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter -->> http://www.4t2.com/mysql From lists at sebastianmendel.de Wed Jun 14 09:31:10 2006 From: lists at sebastianmendel.de (Sebastian Mendel) Date: Wed, 14 Jun 2006 09:31:10 +0200 Subject: Tabelle voll - was nun ... In-Reply-To: <006f01c68f2a$cd2f37e0$16b2a8c0@LionPC> References: <055c01c68f25$b210b880$1400a8c0@nbandreas> <006f01c68f2a$cd2f37e0$16b2a8c0@LionPC> Message-ID: <448FBB3E.1020305@sebastianmendel.de> Norbert Pfeiffer schrieb: > Hallo Andreas, > > danke, > habe ich wieder was gelernt, und das in meinem Alter ... ;-) du bist aber auch immer so spärlich mit deinen Informationen ... da hat ja mal wieder Rainer Zufall geholfen das du die verwendete Abfrage doch noch mitgeschickt hast ... ;-) -- Sebastian -- Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter -->> http://www.4t2.com/mysql From mysql at universalware.de Thu Jun 15 11:33:03 2006 From: mysql at universalware.de (=?iso-8859-1?Q?Andreas_M=FCller?=) Date: Thu, 15 Jun 2006 11:33:03 +0200 Subject: Abfrageoptimierung Message-ID: <0dea01c6905e$b3ff33d0$1400a8c0@nbandreas> Hallo zusammen, ich hab da mal eine kleine Denksport-Aufgabe: Ich habe eine Tabelle mit rund 150.000 Datensätzen. Die Tabelle enthält die Daten von hochgeladenen bzw. vom Server daraus erzeugten Dateien. Zu Replikations- und Backup-Zwecken wird der Inhalt der Dateien mit in der Datenbank gespeichert. Im Durchschnitt ist jeder Datensatz 10 KB groß. Damit ist die gesamte Tabelle rund 1,5 GB groß. CREATE TABLE `files` ( `file_id` int(11) NOT NULL auto_increment, `user_id` int(11) NOT NULL, `filekey` varchar(32) NOT NULL, `filename` varchar(255) NOT NULL, `filesize` int(11) NOT NULL, `filedate` datetime NOT NULL, `contenttype` varchar(255) NOT NULL, `data` longblob, PRIMARY KEY (`file_id`), UNIQUE KEY `filekey` (`filekey`), KEY `user_id` (`user_id`), ) ENGINE=MyISAM; Nun möchte ich gern die Summe von 'filesize' über alle Datensätze haben: SELECT Sum(filesize) FROM files; Auf Grund der größe der Tablelle dauert diese Abfrage recht lang (ca. 60 Sekunden). Wie kann man das beschleunigen und warum funktioniert das ? Eine Aufteilung in zwei Tabellen z.B. eine mit dem Blob Feld und eine mit den restlichen Daten ist keine gewüschte Lösung. Viel Spass beim grübeln :-) Gruß, Andreas -- Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter -->> http://www.4t2.com/mysql From andreas.kretschmer at schollglas.com Thu Jun 15 11:54:00 2006 From: andreas.kretschmer at schollglas.com (Andreas Kretschmer) Date: Thu, 15 Jun 2006 11:54:00 +0200 Subject: Abfrageoptimierung In-Reply-To: <0dea01c6905e$b3ff33d0$1400a8c0@nbandreas> References: <0dea01c6905e$b3ff33d0$1400a8c0@nbandreas> Message-ID: <20060615095400.GB28567@webserv.wug-glas.de> am 15.06.2006, um 11:33:03 +0200 mailte Andreas Müller folgendes: > SELECT Sum(filesize) FROM files; > > Auf Grund der größe der Tablelle dauert diese Abfrage recht lang (ca. 60 > Sekunden). > > Wie kann man das beschleunigen und warum funktioniert das ? Eine Aufteilung Du machst einen full table scan, und das dauert halt. Lagere die Metadaten in eine extra table aus, die ist dann kleiner. > in zwei Tabellen z.B. eine mit dem Blob Feld und eine mit den restlichen > Daten ist keine gewüschte Lösung. Warum nicht? Referentielle Integrität ist für MySQL-Loser wohl noch immer ein Fremdwort. Du könntest mit einem VIEW sogar wieder deine bisherige Table darstellen. Ähm, VIEWS kann MySQL glaub noch nicht, oder? > > Viel Spass beim grübeln :-) Du könntest auch einen Trigger schreiben, der bei allen Operationen sich in einer extra table die aktuelle Größe merkt. Aber ich weiß grad nicht, ob und wie gut TRIGGER in MySQL schon funktionieren. Mit freundlichen Grüßen, A. Kretschmer -- Andreas Kretschmer (Kontakt: siehe Header) Heynitz: 035242/47215, D1: 0160/7141639 GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net === Schollglas Unternehmensgruppe === -- Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter -->> http://www.4t2.com/mysql From lists at sebastianmendel.de Thu Jun 15 12:06:32 2006 From: lists at sebastianmendel.de (Sebastian Mendel) Date: Thu, 15 Jun 2006 12:06:32 +0200 Subject: Abfrageoptimierung In-Reply-To: <20060615095400.GB28567@webserv.wug-glas.de> References: <0dea01c6905e$b3ff33d0$1400a8c0@nbandreas> <20060615095400.GB28567@webserv.wug-glas.de> Message-ID: <44913128.40209@sebastianmendel.de> Andreas Kretschmer schrieb: > am 15.06.2006, um 11:33:03 +0200 mailte Andreas Müller folgendes: >> SELECT Sum(filesize) FROM files; >> >> Auf Grund der größe der Tablelle dauert diese Abfrage recht lang (ca. 60 >> Sekunden). >> >> Wie kann man das beschleunigen und warum funktioniert das ? Eine Aufteilung > > Du machst einen full table scan, und das dauert halt. Lagere die > Metadaten in eine extra table aus, die ist dann kleiner. > > >> in zwei Tabellen z.B. eine mit dem Blob Feld und eine mit den restlichen >> Daten ist keine gewüschte Lösung. > > Warum nicht? Referentielle Integrität ist für MySQL-Loser wohl noch Sonst gehts noch, oder? Reis dich mal ein bisschen am Riemen! > immer ein Fremdwort. Du könntest mit einem VIEW sogar wieder deine > bisherige Table darstellen. Ähm, VIEWS kann MySQL glaub noch nicht, > oder? Kann es. >> Viel Spass beim grübeln :-) > > Du könntest auch einen Trigger schreiben, der bei allen Operationen sich > in einer extra table die aktuelle Größe merkt. Aber ich weiß grad > nicht, ob und wie gut TRIGGER in MySQL schon funktionieren. Kann es auch. > Mit freundlichen Grüßen, A. Kretschmer achso, das MySQL-Lo(o)ser war freundlich gemeint ... -- Sebastian -- Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter -->> http://www.4t2.com/mysql From lists at sebastianmendel.de Thu Jun 15 12:07:33 2006 From: lists at sebastianmendel.de (Sebastian Mendel) Date: Thu, 15 Jun 2006 12:07:33 +0200 Subject: Abfrageoptimierung In-Reply-To: <0dea01c6905e$b3ff33d0$1400a8c0@nbandreas> References: <0dea01c6905e$b3ff33d0$1400a8c0@nbandreas> Message-ID: <44913165.30207@sebastianmendel.de> Andreas Müller schrieb: > Hallo zusammen, > > ich hab da mal eine kleine Denksport-Aufgabe: > > Ich habe eine Tabelle mit rund 150.000 Datensätzen. Die Tabelle enthält die > Daten von hochgeladenen bzw. vom Server daraus erzeugten Dateien. Zu > Replikations- und Backup-Zwecken wird der Inhalt der Dateien mit in der > Datenbank gespeichert. Im Durchschnitt ist jeder Datensatz 10 KB groß. Damit > ist die gesamte Tabelle rund 1,5 GB groß. > > CREATE TABLE `files` ( > `file_id` int(11) NOT NULL auto_increment, > `user_id` int(11) NOT NULL, > `filekey` varchar(32) NOT NULL, > `filename` varchar(255) NOT NULL, > `filesize` int(11) NOT NULL, > `filedate` datetime NOT NULL, > `contenttype` varchar(255) NOT NULL, > `data` longblob, > PRIMARY KEY (`file_id`), > UNIQUE KEY `filekey` (`filekey`), > KEY `user_id` (`user_id`), > ) ENGINE=MyISAM; > > Nun möchte ich gern die Summe von 'filesize' über alle Datensätze haben: > > SELECT Sum(filesize) FROM files; > > Auf Grund der größe der Tablelle dauert diese Abfrage recht lang (ca. 60 > Sekunden). > > Wie kann man das beschleunigen und warum funktioniert das ? Eine Aufteilung > in zwei Tabellen z.B. eine mit dem Blob Feld und eine mit den restlichen > Daten ist keine gewüschte Lösung. na eventuell hilft ja ein Index auf die Spalte, kommt drauf wie oft diese Abfrage benötigt wird und somit den Nachteil der eventuell langsameren Inserts aufwiegt. -- Sebastian -- Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter -->> http://www.4t2.com/mysql From andreas.kretschmer at schollglas.com Thu Jun 15 12:16:58 2006 From: andreas.kretschmer at schollglas.com (Andreas Kretschmer) Date: Thu, 15 Jun 2006 12:16:58 +0200 Subject: Abfrageoptimierung In-Reply-To: <44913165.30207@sebastianmendel.de> References: <0dea01c6905e$b3ff33d0$1400a8c0@nbandreas> <44913165.30207@sebastianmendel.de> Message-ID: <20060615101652.GC28567@webserv.wug-glas.de> am 15.06.2006, um 12:07:33 +0200 mailte Sebastian Mendel folgendes: > na eventuell hilft ja ein Index auf die Spalte, kommt drauf wie oft diese > Abfrage benötigt wird und somit den Nachteil der eventuell langsameren > Inserts aufwiegt. Was genau soll ein Index bringen, wenn ein Full Table Scan gemacht wird? Liegts an der Hitze? Mit freundlichen Grüßen, A. Kretschmer -- Andreas Kretschmer (Kontakt: siehe Header) Heynitz: 035242/47215, D1: 0160/7141639 GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net === Schollglas Unternehmensgruppe === -- Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter -->> http://www.4t2.com/mysql From mysql at universalware.de Thu Jun 15 12:31:06 2006 From: mysql at universalware.de (=?iso-8859-1?Q?Andreas_M=FCller?=) Date: Thu, 15 Jun 2006 12:31:06 +0200 Subject: Abfrageoptimierung In-Reply-To: <20060615101652.GC28567@webserv.wug-glas.de> Message-ID: <0e0301c69066$cfb35c20$1400a8c0@nbandreas> Hallo zusammen, also kurz zu den Meldungen: Es ist eben genau nicht gewünscht daraus zwei Tabellen zu machen weil es: 1. eine bessere Lösung bei MySQL(!) gibt, in anderen RDBMS kann das durchaus die einzige sinnvolle Lösung sein 2. zu viele Änderungen an der Programmlogik vorgenommen werden müsste Ich kenne die Lösung und wollte euch die Aufgabe nur mal zum grübeln geben. Da ich gemerkt habe das die praktischen Kenntnisse über die internen Arbeitsweisen von MySQL nicht so weit verbreitet sind (siehe Thread 'Tabelle voll - was nun ...') dachte ich mir sowas wäre sicher ab und an eine gute Idee gelöste Probleme aus der täglichen Praxis mal vorzustellen und zu erklären warum es funktioniert :-) Gruß, Andreas -- Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter -->> http://www.4t2.com/mysql From andreas.kretschmer at schollglas.com Thu Jun 15 12:43:51 2006 From: andreas.kretschmer at schollglas.com (Andreas Kretschmer) Date: Thu, 15 Jun 2006 12:43:51 +0200 Subject: Abfrageoptimierung In-Reply-To: <0e0301c69066$cfb35c20$1400a8c0@nbandreas> References: <20060615101652.GC28567@webserv.wug-glas.de> <0e0301c69066$cfb35c20$1400a8c0@nbandreas> Message-ID: <20060615104351.GD28567@webserv.wug-glas.de> am 15.06.2006, um 12:31:06 +0200 mailte Andreas Müller folgendes: > Hallo zusammen, > also kurz zu den Meldungen: > > Es ist eben genau nicht gewünscht daraus zwei Tabellen zu machen weil es: > 1. eine bessere Lösung bei MySQL(!) gibt, in anderen RDBMS kann das durchaus > die einzige sinnvolle Lösung sein Dann nenne sie doch. Und ja, andere RDBMS haben bleistiftsweise solche Probleme gar nicht erst: http://pgsql.info/pg/toast.php Mit freundlichen Grüßen, A. Kretschmer -- Andreas Kretschmer (Kontakt: siehe Header) Heynitz: 035242/47215, D1: 0160/7141639 GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net === Schollglas Unternehmensgruppe === -- Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter -->> http://www.4t2.com/mysql From lists at sebastianmendel.de Thu Jun 15 12:46:39 2006 From: lists at sebastianmendel.de (Sebastian Mendel) Date: Thu, 15 Jun 2006 12:46:39 +0200 Subject: Abfrageoptimierung In-Reply-To: <0e0301c69066$cfb35c20$1400a8c0@nbandreas> References: <0e0301c69066$cfb35c20$1400a8c0@nbandreas> Message-ID: <44913A8F.6010806@sebastianmendel.de> Andreas Müller schrieb: > Hallo zusammen, > also kurz zu den Meldungen: > > Es ist eben genau nicht gewünscht daraus zwei Tabellen zu machen weil es: > 1. eine bessere Lösung bei MySQL(!) gibt, in anderen RDBMS kann das durchaus > die einzige sinnvolle Lösung sein > 2. zu viele Änderungen an der Programmlogik vorgenommen werden müsste > > Ich kenne die Lösung und wollte euch die Aufgabe nur mal zum grübeln geben. > Da ich gemerkt habe das die praktischen Kenntnisse über die internen > Arbeitsweisen von MySQL nicht so weit verbreitet sind (siehe Thread 'Tabelle > voll - was nun ...') dachte ich mir sowas wäre sicher ab und an eine gute > Idee gelöste Probleme aus der täglichen Praxis mal vorzustellen und zu > erklären warum es funktioniert :-) also bei mir bringt der Index schon Vorteile, allerdings habe ich jetzt keine 1.5M Datensätze um zu sehen wie sehr sich das dort dann auswirkt das macht es sowieso schwer da zu testen ... wie ist denn nun die Lösung? -- Sebastian -- Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter -->> http://www.4t2.com/mysql From andreas.kretschmer at schollglas.com Thu Jun 15 13:00:47 2006 From: andreas.kretschmer at schollglas.com (Andreas Kretschmer) Date: Thu, 15 Jun 2006 13:00:47 +0200 Subject: Abfrageoptimierung In-Reply-To: <44913A8F.6010806@sebastianmendel.de> References: <0e0301c69066$cfb35c20$1400a8c0@nbandreas> <44913A8F.6010806@sebastianmendel.de> Message-ID: <20060615110047.GE28567@webserv.wug-glas.de> am 15.06.2006, um 12:46:39 +0200 mailte Sebastian Mendel folgendes: > >voll - was nun ...') dachte ich mir sowas wäre sicher ab und an eine gute > >Idee gelöste Probleme aus der täglichen Praxis mal vorzustellen und zu > >erklären warum es funktioniert :-) > > also bei mir bringt der Index schon Vorteile, allerdings habe ich jetzt Sehr, sehr unwahrscheinlich. Kannst Du das an einem EXPLAIN belegen? > keine 1.5M Datensätze um zu sehen wie sehr sich das dort dann auswirkt Bei Dir hat wahrscheinlich ein Cache zugeschlagen. 1.4 Millionen Rows: scholl=*# explain analyse select sum(flaeche) from bde_meldungen ; QUERY PLAN -------------------------------------------------------------------------------------------------------------------------------- Aggregate (cost=49087.98..49087.99 rows=1 width=8) (actual time=6982.656..6982.658 rows=1 loops=1) -> Seq Scan on bde_meldungen (cost=0.00..45587.18 rows=1400318 width=8) (actual time=0.071..3610.087 rows=1400318 loops=1) Total runtime: 6982.749 ms (3 rows) scholl=*# create index idx_flaeche on bde_meldungen (flaeche); CREATE INDEX scholl=*# explain analyse select sum(flaeche) from bde_meldungen ; QUERY PLAN -------------------------------------------------------------------------------------------------------------------------------- Aggregate (cost=49087.98..49087.99 rows=1 width=8) (actual time=8049.720..8049.723 rows=1 loops=1) -> Seq Scan on bde_meldungen (cost=0.00..45587.18 rows=1400318 width=8) (actual time=0.042..4190.269 rows=1400318 loops=1) Total runtime: 8049.823 ms (3 rows) Der Ausführungsplan ist genau identisch, daß es mit Index sogar länger dauert dürfte an einem paralell anderem laufenden Job liegen. Btw.: da da ist nicht MySQL, falls sich jemand über die Details des EXPLAIN wundert. Mit freundlichen Grüßen, A. Kretschmer -- Andreas Kretschmer (Kontakt: siehe Header) Heynitz: 035242/47215, D1: 0160/7141639 GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net === Schollglas Unternehmensgruppe === -- Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter -->> http://www.4t2.com/mysql From t.wolf at gmx.at Thu Jun 15 13:14:26 2006 From: t.wolf at gmx.at (T.Wolf) Date: Thu, 15 Jun 2006 13:14:26 +0200 Subject: unsubscribe t.wolf@gmx.at Message-ID: <200606151114.k5FBEQ531361@mailscanner.unido.org> -------------- nächster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: http://lists.mushaake.org/pipermail/mysql-de/attachments/20060615/e22dcb0b/attachment.html From mysql at universalware.de Thu Jun 15 13:16:56 2006 From: mysql at universalware.de (=?iso-8859-1?Q?Andreas_M=FCller?=) Date: Thu, 15 Jun 2006 13:16:56 +0200 Subject: Abfrageoptimierung In-Reply-To: <20060615104351.GD28567@webserv.wug-glas.de> Message-ID: <0e0a01c6906d$375992d0$1400a8c0@nbandreas> Hallo zusammen, zu A. Kretschmer: Falls du es nicht bemerkt hast ist dies hier eine MySQL Liste. D.h. Diskussionen das andere RDBMS das ganz anders machen sind unsinnig. Es geht hier um Lösungen für MySQL. Nun gut dann zu Lösung. Die Antwort ist schon gefallen wenn auch nur als Vermutung: Ein Index auf die Spalte. Wo liegt nun eigentlich das Problem bei der Aufgabe? MySQL muss in dem Fall einen full table scan durchführen. Da nun die Datensätze so groß sind muss MySQL immer sehr viele Daten von der Platte lesen bze. auf der Tabelle positionieren. Es sind zwar nur 150.000 Datensätze aber eben 1,5 GB Daten und das dauert. Legt man nun einen Index auf die Spalte so verwendet der Optimizer automatisch diesen Index weil er damit NICHT mehr auf die Datendatei zugreifen muss denn die Werte die er addieren soll befinden sich ja bereis im Index. D.h. es ist "billiger" einen full index scan zu machen als einen full table scan. Das ganze lässt sich so verallgemeinern: MySQL liest nur dann Daten aus der Datentabelle wenn es Spalten benötigt die es über einen gewählten Index nicht bekommt. In allen anderen Fällen verwendet es die im Index gespeicherten Daten OHNE auf die Datentabelle zurückzugreifen. So können häufig verwendete Abfragen durchaus optimiert indem man an den Zugriffsschlüssel einfach noch die Spalte(n) angängt die man aus den Daten lesen will. Im genannten Beispiel heisst das: Möchte ich eine performate Lösung haben um die Summe von 'filesize' pro user_id zu ermitteln so kann ich zwar einen einfachen Index auf 'user_id' verwenden - nur führt das zu Zugriffen auf die Datendatei weil der Wert für 'filesize' gelesen werden muss. Lege ich einen Index über 'user_id,filesize' an so erfolgt die Abfrag ausschließlich im Index. Es ist natürlich immer zu prüfen ob ein weiterer Index der Gesamtperformance zuträglich ist oder eher nicht. Jeder Index mehr brenst unweigerlich INSERT und DELETE sowei ggf. UPDATE. Man sollte auch prüfen welcher Index notwendig ist und welcher nicht. Im Beispiel wäre ein Index auf 'user_id' und ein weiterer auf 'user_id,filesize' ein Index zu viel. Der letztere würde in der Regel ausreichen weil er auch für einen reine Selektion auf Basis user_id ausreichend ist: MySQL kann von links Teilausdrücke in einem Index verwenden. Gruß, Andreas -- Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter -->> http://www.4t2.com/mysql From lists at sebastianmendel.de Thu Jun 15 14:19:50 2006 From: lists at sebastianmendel.de (Sebastian Mendel) Date: Thu, 15 Jun 2006 14:19:50 +0200 Subject: Abfrageoptimierung In-Reply-To: <20060615110047.GE28567@webserv.wug-glas.de> References: <0e0301c69066$cfb35c20$1400a8c0@nbandreas> <44913A8F.6010806@sebastianmendel.de> <20060615110047.GE28567@webserv.wug-glas.de> Message-ID: <44915066.5000005@sebastianmendel.de> Andreas Kretschmer schrieb: > am 15.06.2006, um 12:46:39 +0200 mailte Sebastian Mendel folgendes: >>> voll - was nun ...') dachte ich mir sowas wäre sicher ab und an eine gute >>> Idee gelöste Probleme aus der täglichen Praxis mal vorzustellen und zu >>> erklären warum es funktioniert :-) >> also bei mir bringt der Index schon Vorteile, allerdings habe ich jetzt > > Sehr, sehr unwahrscheinlich. Kannst Du das an einem EXPLAIN belegen? sehr sehr wahrscheinlich, da du anscheinend keinen MySQL-Server hast wirst du es wohl auch nie zu Gesicht bekommen, denn die EXPLAIN-Ausagbe könnte ich zwar hier hinschreiben aber warum solltest du der mehr glauben als mir ... hätte ja auch nur ich hier hin geschrieben >> keine 1.5M Datensätze um zu sehen wie sehr sich das dort dann auswirkt > > Bei Dir hat wahrscheinlich ein Cache zugeschlagen. Mein Cache schlägt überhaupt nicht, und zweitens bin ich ja nicht ganz so bescheuert wie du es anscheinend glaubst. > [... total am Thema vorbei ...] > > > Btw.: da da ist nicht MySQL, falls sich jemand über die Details des > EXPLAIN wundert. genau, was soll dein Posting dann hier also? Andreas hat es ja bereits geschrieben - aber ich kann es ja nochmal bestätigen ein EXPLAIN bestätigt das _MySQL_!!!!!! den Index verwendet. Und bitte geh doch mit deinen PostgreSQL Themen auf ein PostgreSQL-Liste, hier geht es um MySQL! -- Sebastian -- Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter -->> http://www.4t2.com/mysql From norbert at itbw.de Fri Jun 16 09:51:52 2006 From: norbert at itbw.de (Norbert Pfeiffer) Date: Fri, 16 Jun 2006 09:51:52 +0200 Subject: Tabelle voll - was nun ... Message-ID: <000701c69119$c07152e0$6502a8c0@PFEIFFER> Hallo Andreas, die Umstellung des Indexes von DateTime auf Varchar(20) hat deutliche Veraenderungen gezeigt: ----------------------------------------- vorher tblMess200510 [ 968.160] 147.357,750 ms tblMess200511 [ 819.445] 129.076,082 ms tblMess200512 [ 812.269] 156.610,316 ms tblMess200601 [ 191.701] 114.188,460 ms tblMess200602 [ 0] 112.224,316 ms tblMess200603 [ 0] 113.869,974 ms tblMess200604 [ 0] 111.348,056 ms tblMess200605 [ 0] 112.936,735 ms tblMess200606 [ 0] 109.195,142 ms ----------------------------------------- nachher tblMess200601 [1.037.833] 59.488,953 ms tblMess200602 [1.118.297] 59.947,298 ms tblMess200603 [1.168.625] 60.853,128 ms tblMess200604 [1.139.913] 61.128,919 ms tblMess200605 [1.567.009] 99.553,064 ms tblMess200606 [ 0] 30,573 ms ----------------------------------------- Wobei das fuer mich total unbefriedigend ist, auch wenn Du glaubhaft versicherst, dass dies bei allen RDBMS so ausfaellt. Es muss jedoch noch angemerkt werden, dass beim 2. Lauf nur noch 6Mio Records in der Haupttabelle waren, vorher hatte sie 16Mio Records. m. b. G. N. Pfeiffer --------------------- normal: 06131-1436094 Notruf: 0163-3613642 --------------------- e.o.f. -- Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter -->> http://www.4t2.com/mysql From mysql at universalware.de Fri Jun 16 10:30:25 2006 From: mysql at universalware.de (=?iso-8859-1?Q?Andreas_M=FCller?=) Date: Fri, 16 Jun 2006 10:30:25 +0200 Subject: Tabelle voll - was nun ... In-Reply-To: <000701c69119$c07152e0$6502a8c0@PFEIFFER> Message-ID: <12d901c6911f$1e138fd0$1400a8c0@nbandreas> Hallo Norbert, > Wobei das fuer mich total unbefriedigend ist, auch wenn > Du glaubhaft versicherst, dass dies bei allen RDBMS so > ausfaellt. das habe ich nicht. Ich habe gesagt das ein Range über das DateTime Feld wesentlich schneller ist als Funktionsaufrufe. Und das es bei MySQL manchmal so ist das String-Ranges schneller sind als DateTime-Ranges. D.h. um das richtig vergleichen zu können solltest es einmal mit Funktionsaufrufen, einmal mit DateTime-Range (also größer und kleiner) und einmal mit String-Range (LIKE) versuchen. Dann kommen vergleichbare Zahlen heraus. Andere RDBMS können sich da ganz anders verhalten. Aber wie gestern schon bei der Denksportaufgabe haben wir ja hier MySQL also kümmere ich mich hier um das Verhalten bei MySQL. Gruß, Andreas -- Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter -->> http://www.4t2.com/mysql From lists at sebastianmendel.de Fri Jun 16 10:49:49 2006 From: lists at sebastianmendel.de (Sebastian Mendel) Date: Fri, 16 Jun 2006 10:49:49 +0200 Subject: Tabelle voll - was nun ... In-Reply-To: <12d901c6911f$1e138fd0$1400a8c0@nbandreas> References: <12d901c6911f$1e138fd0$1400a8c0@nbandreas> Message-ID: <449270AD.7050800@sebastianmendel.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andreas Müller schrieb: > Hallo Norbert, > >> Wobei das fuer mich total unbefriedigend ist, auch wenn >> Du glaubhaft versicherst, dass dies bei allen RDBMS so >> ausfaellt. > > das habe ich nicht. Ich habe gesagt das ein Range über das DateTime Feld > wesentlich schneller ist als Funktionsaufrufe. > Und das es bei MySQL manchmal so ist das String-Ranges schneller sind als > DateTime-Ranges. > > D.h. um das richtig vergleichen zu können solltest es einmal mit > Funktionsaufrufen, einmal mit DateTime-Range (also größer und kleiner) und > einmal mit String-Range (LIKE) versuchen. Dann kommen vergleichbare Zahlen > heraus. > > Andere RDBMS können sich da ganz anders verhalten. Aber wie gestern schon > bei der Denksportaufgabe haben wir ja hier MySQL also kümmere ich mich hier > um das Verhalten bei MySQL. also ich würde es als DateTeime Feld lassen und es mal wie folgt probieren mit nur einem Funktionsaufruf, z. B. WHERE EXTRACT(YEAR_MONTH FROM `datum`) = 'yyyymm'; oder WHERE DATE_FORMAT(`datum`, "%Y%m") = 'yyyymm'; oder ganz und gar ohne Funktionsaufruf z. B.: WHERE `datum` LIKE 'xxxx-xx-__'; oder WHERE `datum` BETWEEN 'xxxx-xx-00' AND 'yyyy-yy-00'; - -- Sebastian Mendel www.sebastianmendel.de -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) iD8DBQFEknCtX/0lClpZDr4RAotPAKCiXWfONt+hTufFfLVAEXYmgdgWgwCfaIUz Rj5LOvVXu1Z9J42WyffIxwg= =5UI/ -----END PGP SIGNATURE----- -- Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter -->> http://www.4t2.com/mysql From mysql at universalware.de Fri Jun 16 10:56:30 2006 From: mysql at universalware.de (=?iso-8859-1?Q?Andreas_M=FCller?=) Date: Fri, 16 Jun 2006 10:56:30 +0200 Subject: Tabelle voll - was nun ... In-Reply-To: <449270AD.7050800@sebastianmendel.de> Message-ID: <12e401c69122$c31a63c0$1400a8c0@nbandreas> Hallo Sebastian, wie ich schon letztens ausgeführt habe kann MySQL keine Funktionsaufrufe optimieren. Daher wäre folgendes immer ein full table scan und daher extrem langsam. > WHERE EXTRACT(YEAR_MONTH FROM `datum`) = 'yyyymm'; > WHERE DATE_FORMAT(`datum`, "%Y%m") = 'yyyymm'; Handelt es sich in dem Fall um ine DateTime Feld so führt MySQL die Abfrage zwar aus - es wird aber auch hier nichts optimiert und es wird ein full table scan durchgeführt. Handelt es sich um ein varchar Feld dann gilt das hier ein Index verwendet wird und sogar manchmal schneller ist als ein Range über ein DateTime Feld. > WHERE `datum` LIKE 'xxxx-xx-__'; Das, oder die normale schreibweise ohne BETWEEN ist die optimale Abfrage für DateTime Felder: > WHERE `datum` BETWEEN 'xxxx-xx-00' AND 'yyyy-yy-00'; WHERE `datum`>='xxxx-xx-00' AND `datum`<='yyyy-yy-00'; Gruß, Andreas -- Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter -->> http://www.4t2.com/mysql From lists at sebastianmendel.de Fri Jun 16 11:04:39 2006 From: lists at sebastianmendel.de (Sebastian Mendel) Date: Fri, 16 Jun 2006 11:04:39 +0200 Subject: Tabelle voll - was nun ... In-Reply-To: <12e401c69122$c31a63c0$1400a8c0@nbandreas> References: <12e401c69122$c31a63c0$1400a8c0@nbandreas> Message-ID: <44927427.20305@sebastianmendel.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andreas Müller schrieb: > Hallo Sebastian, > wie ich schon letztens ausgeführt habe kann MySQL keine Funktionsaufrufe > optimieren. du meinst MySQL macht einen Unterschied ob es die Daten aus dem Index verwendet oder die Daten aus einem Full-Table-Scan zieht daran fest ob eine Funktion über die Daten läuft oder nicht? Warum? Die Daten sind doch die selben! MySQL macht als nur weil ich eine Funktion verwende einen Full-Table-Scan obwohl es die Daten bereits im Index hat, welchen er ja auch verwenden würde wenn ich keine Funktion nehme? > Daher wäre folgendes immer ein full table scan und daher extrem langsam. > >> WHERE EXTRACT(YEAR_MONTH FROM `datum`) = 'yyyymm'; >> WHERE DATE_FORMAT(`datum`, "%Y%m") = 'yyyymm'; > > Handelt es sich in dem Fall um ine DateTime Feld so führt MySQL die Abfrage > zwar aus - es wird aber auch hier nichts optimiert und es wird ein full 'nichts' ist etwas übertrieben, immerhin ist es nur Einer anstelle von zwei Funktionsaufrufen ... ;-) > table scan durchgeführt. Handelt es sich um ein varchar Feld dann gilt das > hier ein Index verwendet wird und sogar manchmal schneller ist als ein Range > über ein DateTime Feld. > >> WHERE `datum` LIKE 'xxxx-xx-__'; > > Das, oder die normale schreibweise ohne BETWEEN ist die optimale Abfrage für > DateTime Felder: >> WHERE `datum` BETWEEN 'xxxx-xx-00' AND 'yyyy-yy-00'; > > WHERE `datum`>='xxxx-xx-00' AND `datum`<='yyyy-yy-00'; - -- Sebastian Mendel www.sebastianmendel.de -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) iD8DBQFEknQnX/0lClpZDr4RAtkoAJ95Z4rNWECIdUrd61rB6QZUsLDmCQCfTcwf mIu4W69i7kQGs3BI6BREAvQ= =jJ4W -----END PGP SIGNATURE----- -- Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter -->> http://www.4t2.com/mysql From mysql at universalware.de Fri Jun 16 12:10:44 2006 From: mysql at universalware.de (=?iso-8859-1?Q?Andreas_M=FCller?=) Date: Fri, 16 Jun 2006 12:10:44 +0200 Subject: Tabelle voll - was nun ... In-Reply-To: <44927427.20305@sebastianmendel.de> Message-ID: <132001c6912d$216ff8e0$1400a8c0@nbandreas> Hallo Sebastian, > du meinst MySQL macht einen Unterschied ob es die Daten aus dem Index > verwendet oder die Daten aus einem Full-Table-Scan zieht daran fest ob > eine Funktion über die Daten läuft oder nicht? Warum? Die Daten sind > doch die selben! MySQL und so gut wie jedes andere RDBMS kann Funktionsaufrufe nicht dahingehend optimieren das es einen Index zu unterstützung nehmen kann. Eine Funktion ist hier wirklich aus Sicht des Optimizers als Blackbox zu sehen: y=f(x) Daher weiss der Optimizer nicht ob und welcher Index sinnvoll wäre und verwendet einfach mal keinen. Die größen Kosten entstehen in dem Beispiel von Norbert aber durch die Methodenaufrufe die unnötig sind. LIKE und BETWEEN sind keine Funktion sondern Operatoren die der Optimizer daher gut optimieren kann. > 'nichts' ist etwas übertrieben, immerhin ist es nur Einer anstelle von > zwei Funktionsaufrufen ... ;-) Naja dafür findet dann ein String Vergleich statt der teurer ist als Integer vergleiche. Hier müsste man Vergleichsmessungen machen was wirklich schneller ist. Gruß, Andreas -- Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter -->> http://www.4t2.com/mysql From norbert at itbw.de Sun Jun 18 21:43:03 2006 From: norbert at itbw.de (Norbert Pfeiffer) Date: Sun, 18 Jun 2006 21:43:03 +0200 Subject: Warum dauert das so lange ... Message-ID: <000b01c6930f$70145110$6502a8c0@PFEIFFER> Hallo, in der folgenden Tabelle bedeuten: - erste Spalte - Tabellenname - zweite Spalte - Ausfuehrungszeit der SQL-Querys - dritte Spalte - Groesse des SQL-Dumps - zweite Spalte - Ausfuehrungszeit des SQL-Dumps -------------------------------------------------------------------- tblSignal200404 - 87,646 ms - 201.452 byte - 302,208 ms tblSignal200405 - 83,180 ms - 13.592 byte - 68,810 ms tblSignal200406 - 90,545 ms - 61.635 byte - 130,563 ms tblSignal200407 - 95.423,265 ms - 257.974.169 byte - 49.676,567 ms tblSignal200408 - 128.670,725 ms - 271.818.425 byte - 51.402,731 ms tblSignal200409 - 102.994,764 ms - 274.739.884 byte - 24.502,255 ms tblSignal200410 - 108.734,833 ms - 294.870.034 byte - 25.916,900 ms tblSignal200411 - 95.341,528 ms - 271.806.101 byte - 23.963,369 ms tblSignal200412 - 72.231,659 ms - 244.748.194 byte - 20.919,586 ms -------------------------------------------------------------------- Zum einen hat die Geschwindigkeit der Dumps durch das Entfernen deutlich zugenommen, zum anderen kann ich mir die Ausfuehrungszeit fuer $query = "ALTER TABLE $table MODIFY nRowID INT(11)"; $query = "ALTER TABLE $table DROP PRIMARY KEY"; $query = "ALTER TABLE $table DROP KEY nStatus"; $query = "ALTER TABLE $table DROP KEY dTimeStamp"; nicht wirklich erklaeren. DROP kann doch nicht so aufwendig sein ... ? PS: Wenn man die ersten beiden Querys entfernt veringert sich die Zeitdauer nicht etwa auf 50%. Stehe irgendwie im Wald ... :-( m. b. G. N. Pfeiffer --------------------- normal: 06131-1436094 Notruf: 0163-3613642 --------------------- e.o.f. -- Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter -->> http://www.4t2.com/mysql From TConnect at gmx.net Mon Jun 19 14:52:04 2006 From: TConnect at gmx.net (Tim Hildebrandt) Date: Mon, 19 Jun 2006 14:52:04 +0200 Subject: Abfrageoptimierung In-Reply-To: <0e0a01c6906d$375992d0$1400a8c0@nbandreas> Message-ID: <23743A18FACA4D4DA568F55844E70C99251F2D@md40.mediadefine.gmbh> Hallo Andreas, > Im genannten Beispiel heisst das: Möchte ich eine performate > Lösung haben um die Summe von 'filesize' pro user_id zu > ermitteln so kann ich zwar einen einfachen Index auf > 'user_id' verwenden - nur führt das zu Zugriffen auf die > Datendatei weil der Wert für 'filesize' gelesen werden muss. > Lege ich einen Index über 'user_id,filesize' an so erfolgt > die Abfrag ausschließlich im Index. Angenommen, ich protokolliere in einer Weblösung die Klicks der Benutzer mit und merke mir in einer Protokolltabelle, auf welche Rubrik, welches Dokument und welches Bild geklickt wurde. Dann habe ich genau genommen drei Spalten, die für mich interessant sind und die alle ggf. einzeln mit COUNT ausgewertet werden sollen (natürlich über einen Zeitraum, der seinerseits als DATETIME und Index vorliegt). Dann würde es Deiner Ausführung nach mehr Sinn machen, einen Gesamtindex über die Spalten "Klickzeitpunkt, RubrikPfad, DokumentID, BildID" statt jeweils über die einzelnen Spalten zu erzeugen? Oder geht es dabei konkret um Aggregatfunktionen wie z.B. SUM? Ich denke, dass die Menge der Datensätze mittels COUNT auch so recht performant ermittelt werden können, oder? Grüße Tim -- Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter -->> http://www.4t2.com/mysql From norbert at itbw.de Mon Jun 19 15:18:59 2006 From: norbert at itbw.de (Norbert Pfeiffer) Date: Mon, 19 Jun 2006 15:18:59 +0200 Subject: Warum dauert das so lange ... References: <000b01c6930f$70145110$6502a8c0@PFEIFFER> Message-ID: <001d01c693a2$f139a630$6502a8c0@PFEIFFER> Hallo Andreas, biste schon auf den Bahamas oder haengst Du irgendwo im Spital ab? Sach mal wat - bitte ... :-) > in der folgenden Tabelle bedeuten: > - erste Spalte - Tabellenname > - zweite Spalte - Ausfuehrungszeit der SQL-Querys > - dritte Spalte - Groesse des SQL-Dumps > - zweite Spalte - Ausfuehrungszeit des SQL-Dumps > -------------------------------------------------------------------- > tblSignal200404 - 87,646 ms - 201.452 byte - 302,208 ms > tblSignal200405 - 83,180 ms - 13.592 byte - 68,810 ms > tblSignal200406 - 90,545 ms - 61.635 byte - 130,563 ms > tblSignal200407 - 95.423,265 ms - 257.974.169 byte - 49.676,567 ms > tblSignal200408 - 128.670,725 ms - 271.818.425 byte - 51.402,731 ms > tblSignal200409 - 102.994,764 ms - 274.739.884 byte - 24.502,255 ms > tblSignal200410 - 108.734,833 ms - 294.870.034 byte - 25.916,900 ms > tblSignal200411 - 95.341,528 ms - 271.806.101 byte - 23.963,369 ms > tblSignal200412 - 72.231,659 ms - 244.748.194 byte - 20.919,586 ms > -------------------------------------------------------------------- > > Zum einen hat die Geschwindigkeit der Dumps durch das > Entfernen deutlich zugenommen, zum anderen kann ich mir > die Ausfuehrungszeit fuer > $query = "ALTER TABLE $table MODIFY nRowID INT(11)"; > $query = "ALTER TABLE $table DROP PRIMARY KEY"; > $query = "ALTER TABLE $table DROP KEY nStatus"; > $query = "ALTER TABLE $table DROP KEY dTimeStamp"; > nicht wirklich erklaeren. > > DROP kann doch nicht so aufwendig sein ... ? > > PS: > Wenn man die ersten beiden Querys entfernt veringert sich die > Zeitdauer nicht etwa auf 50%. Stehe irgendwie im Wald ... :-( m. b. G. N. Pfeiffer --------------------- normal: 06131-1436094 Notruf: 0163-3613642 --------------------- e.o.f. -- Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter -->> http://www.4t2.com/mysql From lists at sebastianmendel.de Mon Jun 19 15:22:58 2006 From: lists at sebastianmendel.de (Sebastian Mendel) Date: Mon, 19 Jun 2006 15:22:58 +0200 Subject: Abfrageoptimierung In-Reply-To: <23743A18FACA4D4DA568F55844E70C99251F2D@md40.mediadefine.gmbh> References: <23743A18FACA4D4DA568F55844E70C99251F2D@md40.mediadefine.gmbh> Message-ID: <4496A532.1060706@sebastianmendel.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tim Hildebrandt schrieb: > Hallo Andreas, > > > >> Im genannten Beispiel heisst das: Möchte ich eine performate >> Lösung haben um die Summe von 'filesize' pro user_id zu >> ermitteln so kann ich zwar einen einfachen Index auf >> 'user_id' verwenden - nur führt das zu Zugriffen auf die >> Datendatei weil der Wert für 'filesize' gelesen werden muss. >> Lege ich einen Index über 'user_id,filesize' an so erfolgt >> die Abfrag ausschließlich im Index. > > Angenommen, ich protokolliere in einer Weblösung die Klicks der Benutzer mit > und merke mir in einer Protokolltabelle, auf welche Rubrik, welches Dokument > und welches Bild geklickt wurde. Dann habe ich genau genommen drei Spalten, > die für mich interessant sind und die alle ggf. einzeln mit COUNT > ausgewertet werden sollen (natürlich über einen Zeitraum, der seinerseits > als DATETIME und Index vorliegt). Dann würde es Deiner Ausführung nach mehr > Sinn machen, einen Gesamtindex über die Spalten "Klickzeitpunkt, RubrikPfad, > DokumentID, BildID" statt jeweils über die einzelnen Spalten zu erzeugen? du brauchst einen Index über die Spalten die in der Abfrage im ORDER, WHERE oder JOIN Teil vorkommen, und die Reihenfolge ist natürlich auch noch relevant ... wobei neuere MySQL-Versionen auch mehrere Indizes für eine Abfrage verwenden können ... ... und wenn du eh ALLE Felder der Tabelle benötigst wäre der Index selber ja genauso groß wie die Tabelle ... weniger praktisch > Oder geht es dabei konkret um Aggregatfunktionen wie z.B. SUM? Ich denke, > dass die Menge der Datensätze mittels COUNT auch so recht performant > ermittelt werden können, oder? es ging ja nicht um ein simples COUNT(*), und ein COUNT(*) ist auch nur so performant wie der Index der auf der im WHERE verwendeten Spalte liegt. (eventuelle JOINS außer Acht gelassen) - -- Sebastian Mendel www.sebastianmendel.de -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) iD8DBQFElqUyX/0lClpZDr4RAlkBAJ9beefo58NKGWR+H9nWuLE1xxOvgACfQ+6x nHrrlKFLOoRFJXQWy+t6L8s= =MI88 -----END PGP SIGNATURE----- -- Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter -->> http://www.4t2.com/mysql From TConnect at gmx.net Mon Jun 19 16:30:44 2006 From: TConnect at gmx.net (Tim Hildebrandt) Date: Mon, 19 Jun 2006 16:30:44 +0200 Subject: Abfrageoptimierung In-Reply-To: <4496A532.1060706@sebastianmendel.de> Message-ID: <23743A18FACA4D4DA568F55844E70C99251F2F@md40.mediadefine.gmbh> Hallo Sebastian, > > Dann > > würde es Deiner Ausführung nach mehr Sinn machen, einen Gesamtindex > > über die Spalten "Klickzeitpunkt, RubrikPfad, DokumentID, BildID" > > statt jeweils über die einzelnen Spalten zu erzeugen? > > du brauchst einen Index über die Spalten die in der Abfrage > im ORDER, WHERE oder JOIN Teil vorkommen, und die Reihenfolge > ist natürlich auch noch relevant Ist nur eine Tabelle und ausgewertet wird in der Regel nur eine Spalte hinsichtlich eines begrenzten Zeitraums. > ... und wenn du eh ALLE Felder der Tabelle benötigst wäre der > Index selber ja genauso groß wie die Tabelle ... weniger praktisch nun ja, aber ich möchte ja alles wissen. Und das möglichst schnell... :-) Das der Index da recht groß wird, muß ich wohl hinnehmen. Meine Idee diesbezüglich ist es, die Tabelle in mehrere kleinere aufzuteilen und darin immer nur die Daten der jeweiligen Zeit-Bereiche zu speichern. Ich überlege gerade, ob ich als begrenzenden Faktor da die tatsächliche Tabellengröße oder vielleicht sogar einfach nur die Monatszahlen verwende. Also vielleicht "statistik_2006_06", "statistik_2006_07" u.s.w. und die Abfrage dann mittels UNION anhand der tatsächlich abgefragten Zeiträume zusammensetze. Das wäre auf jeden Fall besser als die Tabelle z.B. immer nur jedes Jahr neu beginnen zu lassen, da bei einem Abfragebereich von z.B. 1.1.06 bis 28.2.06 nur zwei Tabellen angefaßt werden müssten... und somit auch nur die darin vorhandenen Datenmengen. Besonders vorteilhaft wäre das ggf. sogar, wenn der Abfragebereich über die Jahresgrenze hinweg geschieht, also z.B: 25.12.05 bis 31.1.06, da auch hier nur zwei vergleichsweise kleine Tabellen betrachtet werden würden. Was sagst Du dazu? Grüße Tim -- Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter -->> http://www.4t2.com/mysql From norbert at itbw.de Mon Jun 19 19:15:08 2006 From: norbert at itbw.de (Norbert Pfeiffer) Date: Mon, 19 Jun 2006 19:15:08 +0200 Subject: Bestaetigung ... Message-ID: <005701c693c3$ed848a70$6502a8c0@PFEIFFER> Hallo Andreas, es sind Bloecke von Daten einzulesen, da moechte ich jedem Block eine ID geben. auto_increment hilft hier ja nicht viel, also habe ich es so versucht: mysql> SELECT (MAX(nHandle) + 1) FROM xtractit.tblSignal; +--------------------+ | (MAX(nHandle) + 1) | +--------------------+ | 235960 | +--------------------+ 1 row in set (1 min 45.80 sec) Das ist natuerlich undiskutabel, soviel Zeit habe ich nicht! Also: mysql> alter table tblsignal ADD KEY (nHandle); Query OK, 11420670 rows affected (6 min 8.92 sec) Datensaetze: 11420670 Duplikate: 0 Warnungen: 0 Und jetzt: mysql> SELECT (MAX(nHandle) + 1) FROM xtractit.tblSignal; +--------------------+ | (MAX(nHandle) + 1) | +--------------------+ | 235960 | +--------------------+ 1 row in set (0.22 sec) Da macht proggen wieder Spass ... m. b. G. N. Pfeiffer --------------------- normal: 06131-1436094 Notruf: 0163-3613642 --------------------- e.o.f. -- Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter -->> http://www.4t2.com/mysql From norbert at itbw.de Mon Jun 19 19:18:12 2006 From: norbert at itbw.de (Norbert Pfeiffer) Date: Mon, 19 Jun 2006 19:18:12 +0200 Subject: Warum dauert das so lange ... References: <001c01c693b6$31e21970$0201a8c0@shivaball> Message-ID: <006001c693c4$59c3e000$6502a8c0@PFEIFFER> Hai Thomas, > hast du schon mal versucht die den ALTER in einen Befehl zu packen > ALTER TABLE $table MODIFY nRowID INT(11), DROP PRIMARY KEY, DROP KEY > nStatus, DROP KEY dTimeStamp hmm, nenne mir einen logischen Grund, warum das was bringen koennte, wenn die Reduzierung auf zwei Statements schon ohne richtigen Erfolg war. m. b. G. N. Pfeiffer --------------------- normal: 06131-1436094 Notruf: 0163-3613642 --------------------- e.o.f. -- Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter -->> http://www.4t2.com/mysql From technik at echtwahr.com Tue Jun 20 00:26:28 2006 From: technik at echtwahr.com (Technik via echtwahr.com - Neuer Server) Date: Tue, 20 Jun 2006 00:26:28 +0200 Subject: Warum dauert das so lange ... In-Reply-To: <006001c693c4$59c3e000$6502a8c0@PFEIFFER> Message-ID: <000001c693ef$74a3da80$0201a8c0@shivaball> Hallo, > hmm, > nenne mir einen logischen Grund, warum das was bringen koennte, wenn > die Reduzierung auf zwei Statements schon ohne richtigen Erfolg war. nun warum es nichts gebracht hat bei der Reduzierung auf 2 Abfragen kann ich dir nicht sagen, allerdings sollte es schneller gehen, da ein ALTER TABLE eine Kopie deiner Tabelle erzeugt in der die Änderungen vorgenommen werden. Wenn du 4 Abfragen erstellst, wird er dir auch 4 mal eine TMD Tabelle erstellen, wo er dann jedes Mal die Änderung vornimmt, wenn du diese Abfrage zusammen legst, sparst du schon mal reichlich an der Zeit die verbraucht wird um ein Kopie deiner Daten zu erstellen. War das "logisch"? Mit freundlichen Grüssen Thomas Goik -- Ihre Auktionsseiten im Internet http://www.auxion.de http://www.Xhammer.de -- Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter -->> http://www.4t2.com/mysql From donning at informenta.de Thu Jun 22 16:19:32 2006 From: donning at informenta.de (Michael Donning) Date: Thu, 22 Jun 2006 16:19:32 +0200 Subject: Suche Pre-Compiler fuer MySQL (nicht MaxDB), Embedded SQL Message-ID: <4A6EDE27BF@informenta.de> Hallo Mailing-List! Ich suche die Datei "mysql-esql.tar.gz" aus dem folgendem Beitrag: http://dev.mysql.com/tech-resources/articles/precompiler-for-embedded-sql.ht ml Sie ist leider nicht mehr auf dem dortigen Server verfügbar. Es geht hier um ein Script, das Embedded-SQL Dateien in C/C++ in ein passendes Format für MySQL umwandelt. (Das hat nichts direkt mit dem Embedded Server von MySQL zu tun.) Mir ist bewußt, daß es einen Precompiler für SAP-DB gibt, aber ich suche aktuell etwas derartiges für MySQL. Es geht konkret um eine Umstellung einer DB2-Anwendung. Ich habe diese Anfrage natürlich auch an MySQL gestellt, aber aktuell noch keine Antwort. Jegliche Hinweise auf das Verbleiben dieser Datei sind willkommen. :) Liebe Grüße, Michael Donning -- Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter -->> http://www.4t2.com/mysql From ndof at gmx.li Thu Jun 22 19:36:21 2006 From: ndof at gmx.li (=?ISO-8859-1?Q?Hans_M=FCller?=) Date: Thu, 22 Jun 2006 19:36:21 +0200 Subject: MySQL embedded Message-ID: <449AD515.9070300@gmx.li> Hallo, früher, gab es immer ein extra Paket MySQL embedded. Kann mir jemand sagen, wo das geblieben ist? Und läuft das auch unter Windows? -- Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter -->> http://www.4t2.com/mysql From donning at informenta.de Fri Jun 23 08:28:36 2006 From: donning at informenta.de (Michael Donning) Date: Fri, 23 Jun 2006 08:28:36 +0200 Subject: MySQL embedded In-Reply-To: <449AD515.9070300@gmx.li> Message-ID: <3C1C03026E5@informenta.de> Hallo Hans, Hans Müller erdachte folgende Zeilen: > früher, gab es immer ein extra Paket MySQL embedded. > Kann mir jemand sagen, wo das geblieben ist? > Und läuft das auch unter Windows? Das ist jetzt glaube ich bei der normalen Version dabei. Steht nach der Installation im Unterverzeichnis \mysql\Embedded. Ich habe hier gerade bei einer installierten Windows-Version nachgeschaut. Beachte aber die Lizensierung. Für viele komerzielle Projekte ist die Lizensierung bei MySql-Embedded leider oft der Killer-Faktor. Grob formuliert: Ist Deine Anwendung Open-Source und unter der GPL. Dann besteht kein Problem. Ist Deine Anwendung nicht unter der GPL, dann mußt Du für jedes verkauftes oder verschenktes (!) Software-Paket einen fixen Lizenzbetrag an MySQL abgeben. Bei großen Stückzahlen ist der Betrag natürlich verhandelbar. Eventuelle Ausnahme: Die Embedded Version von MySQL 3 (nur mit MyISAM) kann wohl gegen Zahlung eines einmaligen zu verhandelnden Obulus danach "Royality Fee Free" verwendet werden. Wie groß der zu entrichtende Betrag ist, wurde mir auf einfach Nachfrage aber noch nicht verraten. Ich kann nur vermuten, daß er sich im fünfstelligen Bereich bewegt. Alle Angaben ohne Gewähr. Genaueres sollte man im Einzelfall lieber persönlich bei mysql erfragen. Liebe Grüße, Michael Donning -- Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter -->> http://www.4t2.com/mysql From mysql at universalware.de Fri Jun 23 08:38:47 2006 From: mysql at universalware.de (=?iso-8859-1?Q?Andreas_M=FCller?=) Date: Fri, 23 Jun 2006 08:38:47 +0200 Subject: Warum dauert das so lange ... In-Reply-To: <001d01c693a2$f139a630$6502a8c0@PFEIFFER> Message-ID: <079801c6968f$ae824320$1500a8c0@nbandreas> Hallo Norbert, > biste schon auf den Bahamas oder haengst Du irgendwo im Spital ab? > Sach mal wat - bitte ... :-) nö da bin ich noch nicht aber war auf dem Standesamt ... von daher melde ich mich die Tage mal :-) Gruß, Andreas -- Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter -->> http://www.4t2.com/mysql From ndof at gmx.li Fri Jun 23 09:18:11 2006 From: ndof at gmx.li (=?ISO-8859-1?Q?Hans_M=FCller?=) Date: Fri, 23 Jun 2006 09:18:11 +0200 Subject: MySQL embedded In-Reply-To: <3C1C03026E5@informenta.de> References: <3C1C03026E5@informenta.de> Message-ID: <449B95B3.2090302@gmx.li> Ich entwickle aus Überzeugung eh nur GPL apps.:) -- Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter -->> http://www.4t2.com/mysql From norbert at itbw.de Fri Jun 23 11:10:45 2006 From: norbert at itbw.de (Norbert Pfeiffer) Date: Fri, 23 Jun 2006 11:10:45 +0200 Subject: Fw: wieso, weshalb, warum Message-ID: <000c01c696a4$ecbe5f60$6502a8c0@PFEIFFER> Hallo, es existieren 2 Tabellen, 'signal' - 11Mio rec und 'error' - 78 rec. In beiden Tabellen gibt es eine nHandle, von der ich den Maximalwert brauche: SELECT MAX(s.nHandle) AS sMX FROM xtra.signal AS s; +--------+ | sMX | +--------+ | 236672 | +--------+ 1 row in set (0.00 sec) SELECT MAX(e.nHandle) AS eMX FROM sigs.error AS e; +--------+ | eMX | +--------+ | 236667 | +--------+ 1 row in set (0.00 sec) aber dann: SELECT IF (MAX(s.nHandle) > MAX(e.nHandle), MAX(s.nHandle), MAX(e.nHandle)) AS mx FROM xtra.signal AS s LEFT JOIN sigs.error AS e ON s.nHandle = e.nHandle; +--------+ | mx | +--------+ | 236672 | +--------+ 1 row in set (2 min 30.86 sec) SELECT IF (MAX(s.nHandle) > MAX(e.nHandle), MAX(s.nHandle), MAX(e.nHandle)) AS mx FROM sigs.error AS e LEFT JOIN xtra.signal AS s ON e.nHandle = s.nHandle; +--------+ | mx | +--------+ | 236667 | +--------+ 1 row in set (0.02 sec) Da bin ich mal auf Eure Kommentare gespannt ... m. b. G. N. Pfeiffer --------------------- normal: 06131-1436094 Notruf: 0163-3613642 --------------------- e.o.f. -- Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter -->> http://www.4t2.com/mysql From lists at sebastianmendel.de Sat Jun 24 08:59:48 2006 From: lists at sebastianmendel.de (Sebastian Mendel) Date: Sat, 24 Jun 2006 08:59:48 +0200 Subject: Fw: wieso, weshalb, warum In-Reply-To: <000c01c696a4$ecbe5f60$6502a8c0@PFEIFFER> References: <000c01c696a4$ecbe5f60$6502a8c0@PFEIFFER> Message-ID: <449CE2E4.10600@sebastianmendel.de> Welche MySQL-Version? Norbert Pfeiffer schrieb: > Hallo, > > es existieren 2 Tabellen, 'signal' - 11Mio rec und 'error' - 78 rec. > In beiden Tabellen gibt es eine nHandle, von der ich den Maximalwert > brauche: > SELECT MAX(s.nHandle) AS sMX FROM xtra.signal AS s; > +--------+ > | sMX | > +--------+ > | 236672 | > +--------+ > 1 row in set (0.00 sec) > > SELECT MAX(e.nHandle) AS eMX FROM sigs.error AS e; > +--------+ > | eMX | > +--------+ > | 236667 | > +--------+ > 1 row in set (0.00 sec) > > aber dann: > SELECT IF (MAX(s.nHandle) > MAX(e.nHandle), MAX(s.nHandle), > MAX(e.nHandle)) AS mx > FROM xtra.signal AS s > LEFT JOIN sigs.error AS e ON s.nHandle = e.nHandle; > +--------+ > | mx | > +--------+ > | 236672 | > +--------+ > 1 row in set (2 min 30.86 sec) > > SELECT IF (MAX(s.nHandle) > MAX(e.nHandle), MAX(s.nHandle), > MAX(e.nHandle)) AS mx > FROM sigs.error AS e > LEFT JOIN xtra.signal AS s ON e.nHandle = s.nHandle; > +--------+ > | mx | > +--------+ > | 236667 | > +--------+ > 1 row in set (0.02 sec) > > Da bin ich mal auf Eure Kommentare gespannt ... Vielleicht kommt das e.nHandle insgesamt nicht 11M mal vor in s.nHandle? Vielleicht kommt das e.nHandle auch in s.nHandle nur 78 mal vor? Das hieße MySQL muss keine 11M Datensätze durch wühlen sondern nur 78. Im Gegensatz dazu muss er bei der ersten Variante immer 11M Datensätze durchwühlen. -- Sebastian -- Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter -->> http://www.4t2.com/mysql From norbert at itbw.de Sat Jun 24 12:54:13 2006 From: norbert at itbw.de (Norbert Pfeiffer) Date: Sat, 24 Jun 2006 12:54:13 +0200 Subject: Fw: wieso, weshalb, warum References: <000c01c696a4$ecbe5f60$6502a8c0@PFEIFFER> <449CE2E4.10600@sebastianmendel.de> Message-ID: <004d01c6977c$8fe95410$16b2a8c0@LionPC> Hallo Sebastian, in die grosse Tabelle kommen alle "guten" Signale, in die kleine Tabelle alle fehlerhaften Records. Das Handle ist die ID eines Logfiles und die haben von 1(Nachts) bis 1M-Signale/Eintraege. Bei sehr kleinen Logfile-Haeppchen kann es passieren, dass ein bestimmtes Handle nur in der Fehlertabelle auftaucht. Also muss ich beide Tabellen bei der Ermittlung des naechsten Wertes beruecksichtigen. Derzeit mache ich das so: get_single('SELECT MAX(nHandle) FROM xtra.signal'); $w2 = $DB->get_single('SELECT MAX(nHandle) FROM sigs.error'); $handle = ($w1 > $w2) ? $w1 : $w2; ?> SELECT MAX(nHandle) ist immer schnell, egal ob grosse oder kleine Tabelle. Aber ein einzelnes Query koennte IMHO noch schneller sein. Nur mir faellt nix gescheites dafuer ein ... :-( Das mit den JOIN's ist ein Schuss in den Ofen. Der eine ist zu langsam und der andere bringt falsche Ergebnisse. Letzteres habe ich gar nicht verstanden. m. b. G. Norbert ___________________ t-net 06131-6192673 eplus 0163-3613642 ------------------- e.o.m. -- Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter -->> http://www.4t2.com/mysql From mysql at universalware.de Sat Jun 24 15:30:39 2006 From: mysql at universalware.de (=?iso-8859-1?Q?Andreas_M=FCller?=) Date: Sat, 24 Jun 2006 15:30:39 +0200 Subject: Abfrageoptimierung In-Reply-To: <4496A532.1060706@sebastianmendel.de> Message-ID: <0d5e01c69792$64e3d4f0$1500a8c0@nbandreas> Hallo Sebastian, > du brauchst einen Index über die Spalten die in der Abfrage im ORDER, > WHERE oder JOIN Teil vorkommen, und die Reihenfolge ist natürlich auch > noch relevant die Reihenfolge ist in der Regel nur bei unvollständigen Index Schlüsseln relevant oder eben für die ORDER BY Optimierung. Für eine WHERE Konditionen ist es in der Regel unerheblich ob bei "WHERE a=1 AND b=2" der Index "a,b" oder "b,a" ist. > ... wobei neuere MySQL-Versionen auch mehrere Indizes für eine Abfrage > verwenden können ... Das gilt an sich aber nur bedingt. Hier sind die Regelwerke recht kompliziert ab wann sich ein Index-Merging lohnt. Kurz und knapp kann man sagen immer dann wenn AND Konditions soweit runtergebrochen werden können das ein zweiter Index die Komplexität des Scans über das Teilresultset verringert. Das hat in dem Fall aber auch viel mit der Konfiguration (Temp Tables, Sort Buffer) zu tun. Das obige Beispiel "WHERE a=1 AND b=2" könnte durchaus in bestimmten Fällen (das hängt auch von der Datenverteilung ab) von zwei Indices über jeweils "a" und "b" profitieren - aber niemals so performat sein wie ein kombinierter Index. > ... und wenn du eh ALLE Felder der Tabelle benötigst wäre der Index > selber ja genauso groß wie die Tabelle ... weniger praktisch Auch das kann man so nicht ganz stehen lassen. Durch den Index entstehen automatisch quasi vorsortierte und durchgezählte Teiltabellen als Index. Diese sind viel besser verzeigert als die Datentabelle und daher meist wesentlich performater verwendbar als die Datentabelle. Es kommt gerade bei Statistik-Tabellen sehr häufig vor das der Index am Ende um einiges größer ist als die Nutzdaten. > es ging ja nicht um ein simples COUNT(*), und ein COUNT(*) > ist auch nur > so performant wie der Index der auf der im WHERE verwendeten Spalte > liegt. (eventuelle JOINS außer Acht gelassen) Wie auch meinem letzten Posting zu entnehmen ist ist gerade Count ein hocheffektives Beispiel für den Index da hier die Anzahl de Datensätze des Schlüssels direkt im Index gespeichert ist. Ist jemandem schonmal aufgefallen das EXPLAIN komischweise genaue Anzahlen von Datensätzen ausgibt die durchlaufen werden? Das kommt daher das auch der Optimizer genau diesen Umstand nutzt und sich die Datensatzzahlen zu nutze macht um zu entscheiden ob und wie ein Index verwendet wird. Gruß, Andreas -- Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter -->> http://www.4t2.com/mysql From lists at sebastianmendel.de Sun Jun 25 08:46:16 2006 From: lists at sebastianmendel.de (Sebastian Mendel) Date: Sun, 25 Jun 2006 08:46:16 +0200 Subject: Fw: wieso, weshalb, warum In-Reply-To: <004d01c6977c$8fe95410$16b2a8c0@LionPC> References: <000c01c696a4$ecbe5f60$6502a8c0@PFEIFFER> <449CE2E4.10600@sebastianmendel.de> <004d01c6977c$8fe95410$16b2a8c0@LionPC> Message-ID: <449E3138.4070304@sebastianmendel.de> Norbert Pfeiffer schrieb: > Hallo Sebastian, > > in die grosse Tabelle kommen alle "guten" Signale, in die kleine > Tabelle alle fehlerhaften Records. Das Handle ist die ID eines > Logfiles und die haben von 1(Nachts) bis 1M-Signale/Eintraege. > > Bei sehr kleinen Logfile-Haeppchen kann es passieren, dass ein > bestimmtes Handle nur in der Fehlertabelle auftaucht. Also muss > ich beide Tabellen bei der Ermittlung des naechsten Wertes > beruecksichtigen. Derzeit mache ich das so: > $w1 = $DB->get_single('SELECT MAX(nHandle) FROM xtra.signal'); > $w2 = $DB->get_single('SELECT MAX(nHandle) FROM sigs.error'); > $handle = ($w1 > $w2) ? $w1 : $w2; > ?> > SELECT MAX(nHandle) ist immer schnell, egal ob grosse oder kleine > Tabelle. Aber ein einzelnes Query koennte IMHO noch schneller sein. > Nur mir faellt nix gescheites dafuer ein ... :-( nHandle kann also in beiden vorkommen, kann aber auch nur in einer vorkommen? MySQL Version? SELECT GREATEST((SELECT MAX(nHandle) FROM xtra.signal), (SELECT MAX(nHandle) FROM sigs.error)); > Das mit den JOIN's ist ein Schuss in den Ofen. Der eine ist zu > langsam und der andere bringt falsche Ergebnisse. Letzteres habe > ich gar nicht verstanden. Weil du ein LEFT JOIN machst, das heißt es werden nur die Datensätze verknüpft die ein Gegenstück in der Linken (LEFT) Tabelle haben, wenn du also Links (die erste) die klein Tabelle hast ist es klar das das JOIN wesentlich kleiner ist als wenn du Links dir große Tabelle hast. Was du wolltest wäre also ein FULL JOIN, habe ich persönlich noch ine gebraucht, wird dir wohl bei deinem Geschwindigkeits-Problem nicht helfen. Das Das so lange dauert könnte vielleicht daran liegen das MySQL ein Problem damit hat das die Tabellen in unterschiedlichen DB's liegen -- Sebastian -- Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter -->> http://www.4t2.com/mysql From lists at sebastianmendel.de Sun Jun 25 08:55:35 2006 From: lists at sebastianmendel.de (Sebastian Mendel) Date: Sun, 25 Jun 2006 08:55:35 +0200 Subject: Abfrageoptimierung In-Reply-To: <0d5e01c69792$64e3d4f0$1500a8c0@nbandreas> References: <0d5e01c69792$64e3d4f0$1500a8c0@nbandreas> Message-ID: <449E3367.9060800@sebastianmendel.de> Andreas Müller schrieb: > Hallo Sebastian, > >> du brauchst einen Index über die Spalten die in der Abfrage im ORDER, >> WHERE oder JOIN Teil vorkommen, und die Reihenfolge ist natürlich auch >> noch relevant > > die Reihenfolge ist in der Regel nur bei unvollständigen Index Schlüsseln > relevant oder eben für die ORDER BY Optimierung. Für eine WHERE Konditionen > ist es in der Regel unerheblich ob bei "WHERE a=1 AND b=2" der Index "a,b" > oder "b,a" ist. natürlich da lassen sich die Bedingungen ja auch beliebig tauschen und der MySQL Optimizer weiß das, das ist ja logisch, aber wie oft hat man schon lediglich Bedingungen im WHERE ohne ein JOIN und ORDER? Und genau das hatte ich ja geschrieben: "du brauchst einen Index über die Spalten die in der Abfrage im ORDER, WHERE oder JOIN Teil vorkommen, und die Reihenfolge ist natürlich auch noch relevant" >> ... und wenn du eh ALLE Felder der Tabelle benötigst wäre der Index >> selber ja genauso groß wie die Tabelle ... weniger praktisch > > Auch das kann man so nicht ganz stehen lassen. Durch den Index entstehen > automatisch quasi vorsortierte und durchgezählte Teiltabellen als Index. > Diese sind viel besser verzeigert als die Datentabelle und daher meist > wesentlich performater verwendbar als die Datentabelle. Es kommt gerade bei > Statistik-Tabellen sehr häufig vor das der Index am Ende um einiges größer > ist als die Nutzdaten. du fängst ja schon an wie Norbert ... ;-) "weniger praktisch" heißt hier nicht das es schlechter ist als keinen Index zu haben ... man muss halt nur Bedenken das die Tabelle hier mindestens doppelt so groß ist wie die eigentlichen Daten. Außer acht gelassen das vielleicht noch andere Indizes existieren ... und dieser große Index ja durch MySQL versucht wird im RAM gehalten zu werden ... -- Sebastian -- Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter -->> http://www.4t2.com/mysql From norbert at itbw.de Mon Jun 26 08:09:08 2006 From: norbert at itbw.de (Norbert Pfeiffer) Date: Mon, 26 Jun 2006 08:09:08 +0200 Subject: wieso, weshalb, warum References: <004601c69833$802329e0$16b2a8c0@LionPC> Message-ID: <004901c698e7$161c5260$6502a8c0@PFEIFFER> Hallo Sebastian, > SELECT GREATEST((SELECT MAX(nHandle) FROM xtra.signal), > (SELECT MAX(nHandle) FROM sigs.error)); hmm, das sieht sehr gut aus, aber 4.0 kann das leider noch nicht. m. b. G. N. Pfeiffer --------------------- normal: 06131-1436094 Notruf: 0163-3613642 --------------------- e.o.f. -- Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter -->> http://www.4t2.com/mysql From mailingliste at ebf.biz Mon Jun 26 23:50:43 2006 From: mailingliste at ebf.biz (Martin Falley) Date: Mon, 26 Jun 2006 23:50:43 +0200 Subject: unsubscribe t.wolf@gmx.at In-Reply-To: <200606151114.k5FBEQ531361@mailscanner.unido.org> References: <200606151114.k5FBEQ531361@mailscanner.unido.org> Message-ID: <200606262350.43997.mailingliste@ebf.biz> Am Donnerstag, 15. Juni 2006 13:14 schrieb T.Wolf: > xmlns:w="urn:schemas-microsoft-com:office:word" > xmlns="http://www.w3.org/TR/REC-html40"> > > > > > > > > >
> >

style=&apsfont-size:10.0pt; > font-family:Arial&aps> 

> >
> > > > Mal ganz davon abgesehen, daß ich bisher auch vergeblich versuche, mich abzumelden, ist das obige Quoting der Müll, den MS-Office schon bei einer _leeren_ Mail produziert. Man mag sich gar nicht erst vorstellen, wieviel Müll das Programm ins Netz scheucht, wenn auch noch Text dazu kommt. Das dann richtig darzustellen, gleicht schon einer Vergewaltigung für jeden Browser/Mail-Client. Nebenbei ist die Mailinglistenadresse ganz sicher der falsche Empfänger für eine Listenabmeldung. Welche Adresse richtig ist, weiß ich aber auch nicht, nachdem die Adresse, die auf der Webseite angegeben ist, auch nicht funktioniert. Scheinbar hilft nur ein stilles Verwerfen dennoch ankommender Listenmails oder in hartnäckigen Fällen solange zu bouncen, bis der Listowner reagiert. ;)) Gruß Martin -- Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter -->> http://www.4t2.com/mysql