CronJob-Service
bei SELFPHP mit ...
|
+ minütlichen Aufrufen
+ eigenem Crontab Eintrag
+ unbegrenzten CronJobs
+ Statistiken
+ Beispielaufrufen
+ Control-Bereich
Führen Sie mit den CronJobs von
SELFPHP zeitgesteuert Programme
auf Ihrem Server
aus. Weitere Infos
|
:: Anbieterverzeichnis ::
Globale Branchen
Informieren Sie sich über ausgewählte Unternehmen im Anbieterverzeichnis von SELFPHP
:: Newsletter ::
Abonnieren Sie hier den kostenlosen
SELFPHP Newsletter!
|
MySQLi/PDO/(MySQL) Anfänger, Fortgeschrittene oder Experten können hier Fragen und Probleme rund um MySQLi/PDO/(MySQL) diskutieren |
09.12.2008, 13:31:28
|
SELFPHP Profi
|
|
Registriert seit: Apr 2008
Alter: 48
Beiträge: 1.938
|
|
AW: Tabelle-Sortierung dauert sehr lang
darüber hinaus habe ich das gefühl, dass die tabelle nicht optimal "designed" ist:
Zitat:
Zitat von daudi
t_verkaeufer mediumint(11) unsigned NOT NULL default '0'
|
der wertebereich von MEDIUMINT ist max. 0 bis 16777215 (vorzeichenlos).
Zitat:
Zitat von daudi
t_beschreibung text collate latin1_german1_ci NOT NULL
|
brauchst du für die beschreibung tatsächlich 65.535 zeichen ? bei der erstellung der tabelle würde ich ausserdem die max. länge angeben.
Zitat:
Zitat von daudi
t_preis double(10,2) default '0.00'
|
DOUBLE (fliesskommazahl mit E +/- 308 ) ist für preisangaben ungeeignet; besser (und platzsparender) ist DECIMAL
Zitat:
Zitat von daudi
t_katalog smallint(11) unsigned NOT NULL default '0'
|
wertebereich von SMALLINT liegt vorzeichenlos zwischen 0 und 65535.
nun, das sind vielleicht keine grossen fehler; sie deuten allerdings auf ein gewisses missverständnis der verwendeten technik hin. kenntnisse über den einsatz des richtigen datentyps gehören zu den basics eines "anständigen" db-designs...
cx
|
09.12.2008, 13:34:04
|
SELFPHP Profi
|
|
Registriert seit: Apr 2008
Alter: 48
Beiträge: 1.938
|
|
AW: Tabelle-Sortierung dauert sehr lang
Zitat:
Zitat von daudi
Ja, ich brauche alle Einträge auf einmal auf der main-seite.
|
vielleicht ist dein server / hosting-paket schlichtweg überfordert. wenn du so grosse datenmengen speichern und in einem rutsch verarbeiten musst... upgrade ?
cx
|
09.12.2008, 16:21:06
|
Anfänger
|
|
Registriert seit: Dec 2008
Alter: 43
Beiträge: 16
|
|
AW: Tabelle-Sortierung dauert sehr lang
Zitat:
Zitat von cortex
darüber hinaus habe ich das gefühl, dass die tabelle nicht optimal "designed" ist:
|
Zitat:
der wertebereich von MEDIUMINT ist max. 0 bis 16777215 (vorzeichenlos).
|
Das stimmt. Habe auf smallint umgestellt.
Zitat:
brauchst du für die beschreibung tatsächlich 65.535 zeichen ? bei der erstellung der tabelle würde ich ausserdem die max. länge angeben.
|
Nein. Aber ich glaube, es wird trotzdem kein platz reserviert, wie z.b bei INT
Zitat:
DOUBLE (fliesskommazahl mit E +/- 308 ) ist für preisangaben ungeeignet; besser (und platzsparender) ist DECIMAL
|
Das ändere ich auch.
Zitat:
wertebereich von SMALLINT liegt vorzeichenlos zwischen 0 und 65535.
|
Hier ist richtig. Es gibts kataloge mit id 3000. Also tinyint passt nicht.
Zitat:
nun, das sind vielleicht keine grossen fehler; sie deuten allerdings auf ein gewisses missverständnis der verwendeten technik hin. kenntnisse über den einsatz des richtigen datentyps gehören zu den basics eines "anständigen" db-designs...
|
Danke für hinweise. Es löst mein Problem nicht, aber die Tabelestruktur ist jetzt ordentlicher.
|
09.12.2008, 16:21:52
|
Anfänger
|
|
Registriert seit: Dec 2008
Alter: 43
Beiträge: 16
|
|
AW: Tabelle-Sortierung dauert sehr lang
Zitat:
Zitat von cortex
vielleicht ist dein server / hosting-paket schlichtweg überfordert. wenn du so grosse datenmengen speichern und in einem rutsch verarbeiten musst... upgrade ?
cx
|
Nein, ich habe ein Dedizierter Server mit 4 GB RAM und Dual-Core
|
09.12.2008, 17:09:31
|
SELFPHP Profi
|
|
Registriert seit: Apr 2008
Alter: 48
Beiträge: 1.938
|
|
AW: Tabelle-Sortierung dauert sehr lang
also checken wir nochmal die problematischen punkte:
- ressourcen prüfen (hardware / hosting)
- datentypen korrigieren
- SELECT * meiden
- indizies definieren
hoppla: die indizies. du hast zwar welche definiert aber - bitte korrigiert mich, wenn ich daneben liege - dass ein index vorliegt, heisst nicht, dass er auch wirksam ist / von MYSQL verwendet wird.
bsp.: tabelle mit 2 spalten a und b. index auf a.
wenn ich SELECT a, b ausführe, brauche ich auch einen index, der die spalten a und b umfasst (?) stichwort mehrspaltiger index.
ausserdem - aus dem handbuch:
Zitat:
MySQL verwendet Indizes für die folgenden Operationen:
- Zum schnellen Auffinden von Datensätzen, die der WHERE-Klausel entsprechen.
- Zum Ignorieren bestimmter Datensätze. Wenn mehrere Indizes vorhanden sind, verwendet MySQL normalerweise denjenigen, der die kleinste Anzahl von Datensätzen findet.
- Zum Abrufen von Datensätzen aus anderen Tabellen bei der Durchführung von Joins.
- Zum Auffinden des MIN()- oder MAX()-Werts für eine bestimmte indizierte Spalte key_col.
- Zum Sortieren oder Gruppieren einer Tabelle, sofern das Sortieren bzw. Gruppieren auf der Basis des linken Präfixes eines verwendbaren Schlüssels erfolgt (z. B. ORDER BY key_part1, key_part2). Wenn auf alle Schlüsselteile DESC folgt, wird der Schlüssel in umgekehrter Reihenfolge gelesen.
|
da du lediglich einen schlichtes SELECT aufrufst... ich tippe (immer noch) auf eine unglückliche kombination aus SELECT * und ggfs. unwirksamen indizies.
cx
|
09.12.2008, 17:59:48
|
Junior Member
|
|
Registriert seit: Oct 2008
Alter: 47
Beiträge: 274
|
|
AW: Tabelle-Sortierung dauert sehr lang
Zitat:
wenn ich SELECT a, b ausführe, brauche ich auch einen index, der die spalten a und b umfasst (?) stichwort mehrspaltiger index.
|
Einen Index braucht man bei:
ORDER BY id DESC/ASC
WHERE id = 123
JOIN ... ON a.id = b.id
Was im SELECT-Bereich geschieht (Mit Ausnahme von MIN() und MAX()), ist in Bezug auf vorhandene Indexe unerheblich. Übrigens Danke für den Auszug aus dem Manual - dass ein Index auch bei MIN/MAX greift, wusste ich noch nicht. In MySQL können Funktionen nämlich nicht auf Indexe zurückgreifen, aber offensichtlich gilt das nicht für MIN/MAX.
Der von dir angesprochene mehrspaltige Index, kommt bei MySQL zum Einsatz, wenn z.B. eine solche Abfrage ausgeführt wird:
SELECT id FROM tb WHERE a = 1 AND b = 2;
Da MySQL nur einen Index pro Query (bzw. pro Query/Tabelle) verwenden kann, sollte man für diese Query einen mehrspaltigen (Composite oder Covered - wie man ihn auch immer nennen will) Index anlegen. Ein Index nur auf "a" würde auch nur einen Index auf dieser Spalte verwenden. Bei der Suche von "2" in "b" würde MySQL wieder alle Reihen von "b" durchsuchen - Deshalb der mehrspaltige Index auf a und b für solche Queries.
Aber um zum eigentlichen Thema zurückzukommen: Ich glaube bei der Abfrage von > 1.000.000 Datensätzen auf einmal, muss man wohl auf jeden Fall mit Performanceeinbußen rechnen. Indexe helfen in diesem Fall nichts, da ja auch schon der PRIMARY KEY in der ORDER BY verwendet wird.
Geändert von Crisps (09.12.2008 um 18:15:50 Uhr)
|
09.12.2008, 18:23:53
|
Anfänger
|
|
Registriert seit: Dec 2008
Alter: 43
Beiträge: 16
|
|
AW: Tabelle-Sortierung dauert sehr lang
Zitat:
Zitat von Crisps
Der von dir angesprochene mehrspaltige Index, kommt bei MySQL zum Einsatz, wenn z.B. eine solche Abfrage ausgeführt wird:
SELECT id FROM tb WHERE a = 1 AND b = 2;
Da MySQL nur einen Index pro Query (bzw. pro Query/Tabelle) verwenden kann, sollte man für diese Query einen mehrspaltigen (Composite oder Covered - wie man ihn auch immer nennen will) Index anlegen. Ein Index nur auf "a" würde auch nur einen Index auf dieser Spalte verwenden. Bei der Suche von "2" in "b" würde MySQL wieder alle Reihen von "b" durchsuchen - Deshalb der mehrspaltige Index auf a und b für solche Queries.
|
Ich habe das nicht gewusst. Aber gleich bei mir entsteht die folgende Frage.
Z.b. ich habe spalten: a,b,c,d,e. Die spalte a und c sind enzeln indiziert. In abfragen können verschiedene kombinationen dieser spalten vorkommen, z.B. a=1 and b=3 and c=4 oder a=3 and e=3. Wie in diesem Fall, wenn ich weiss nicht, welche spalten zusammenkommen, diesen mehrspaltige Index zu erstellen. Oder reicht es, mindestens ein Index pro Abfrage?
|
09.12.2008, 18:28:40
|
Anfänger
|
|
Registriert seit: Dec 2008
Alter: 43
Beiträge: 16
|
|
AW: Tabelle-Sortierung dauert sehr lang
Zitat:
Zitat von cortex
da du lediglich einen schlichtes SELECT aufrufst... ich tippe (immer noch) auf eine unglückliche kombination aus SELECT *
|
Ja, stimmt. Ich habe im SELECT * um die Spaltennamen ersetzt und jetzt läuft es schneller.
Vielen Dank
|
09.12.2008, 18:52:31
|
Junior Member
|
|
Registriert seit: Oct 2008
Alter: 47
Beiträge: 274
|
|
AW: Tabelle-Sortierung dauert sehr lang
Zitat:
a,b,c,d,e
Die spalte a und c sind enzeln indiziert.
In abfragen können verschiedene kombinationen dieser spalten vorkommen, z.B. a=1 and b=3 and c=4 oder a=3 and e=3.
|
Der Index auf a würde dann nur bei diesen Abfragen genutzt:
Code:
SELECT irgendwass FROM die_tabelle WHERE a=1;
SELECT irgendwass FROM die_tabelle WHERE a=1 and b=3;
SELECT irgendwass FROM die_tabelle WHERE a=1 and b=3 and c=4;
Zwar würde bei den letzen zwei Abfragen der Index auf "a" genutzt um Einträge mit "1" auf "a" zu finden, aber bei "b=3" und/oder "c=4" würde der Optimizer wieder ohne Index auf den Spalten b und/oder c suchen. Für die zweite Query würde sich deshalb ein Composite Index auf a und b anbieten:
Code:
ALTER TABLE die_tabelle ADD INDEX ix_ab (a, b);
Wie sollte dann ein mehrspaltiger Index für die dritte Query aussehen? Genau - so:
Code:
ALTER TABLE die_tabelle ADD INDEX ix_abc (a, b, c);
Aber halt, heißt das jetzt, dass man drei verschiedene Indexe für eben diese drei Abfrage braucht? Nein, zum Glück nicht! Denn der MySQL-Optimizer liest solche mehrspaltigen Indexe von Links nach Rechts. Also wird der letztere, der dreispaltige, Index auch bei allen drei Abfragen verwendet.
Hier hast du dann die Qual der Wahl. Entweder reicht dir hier der dreispaltige Index aus meinem Beispiel (a=3 wirkt ja auch hier, auch wenn e ignoriert wird), oder du erstellst einen zweiten mehrspaltigen Index:
Code:
ALTER TABLE die_tabelle ADD INDEX ix_ae (a, e);
Es kommt halt auch auf die Verschiedenheit der Daten an.
Ich hoffe, meine Erklärung macht Sinn - Frag einfach noch einmal nach wenn ich etwas zu kompliziert erklärt habe. :)
Geändert von Crisps (09.12.2008 um 19:28:36 Uhr)
|
Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Gäste: 1)
|
|
Forumregeln
|
Es ist Ihnen nicht erlaubt, neue Themen zu verfassen.
Es ist Ihnen nicht erlaubt, auf Beiträge zu antworten.
Es ist Ihnen nicht erlaubt, Anhänge hochzuladen.
Es ist Ihnen nicht erlaubt, Ihre Beiträge zu bearbeiten.
HTML-Code ist aus.
|
|
|
Alle Zeitangaben in WEZ +2. Es ist jetzt 10:03:53 Uhr.
|