php-resource



Zurück   PHP-Scripte PHP-Tutorials PHP-Jobs und vieles mehr > Scripts > BRAINSTORMING PHP/SQL/HTML/JS/CSS
 

Login

 
eingeloggt bleiben
star Jetzt registrieren   star Passwort vergessen
 

 

 


BRAINSTORMING PHP/SQL/HTML/JS/CSS Ihr habt eine Idee, aber keinen genauen Ansatz? Diskutiert mit anderen Usern des Forums über eure Gedankengänge um evtl. hilfreiche Ideen zu bekommen!
Normale Fragen bitte weiterhin in die entsprechenden Foren!

Antwort
 
LinkBack Themen-Optionen Thema bewerten
  #1 (permalink)  
Alt 29-12-2008, 03:09
Blackgreetz
 PHP Junior
Links : Onlinestatus : Blackgreetz ist offline
Registriert seit: Oct 2005
Beiträge: 901
Blackgreetz ist zur Zeit noch ein unbeschriebenes Blatt
Standard MySQL-Server schonen?

Hallo,

ich brauch mal eure Hilfe.
Bin mir nicht sicher, ob es eher hier hin, oder ins SQL Forum gehört, aber da es kein Syntaxproblem oder so ist, denk ich, dass es hier besser passt.

Es geht um folgendes:

Es war Weihnachten und die Internetseite hatte statt den üblichen Besuchern nun knapp 10k-15000.
Dabei hat es laut Aussage des Webhosters den MySQL-Server in die Knie gezwungen, sodass es teilweise einen Totalausfall gab.

Dies möchte ich beim nächsten Mal möglichst verhindern.

Letztes Jahr gab es einen ähnlichen Ansturm, allerdings hielt da der gemietete Webspace (kein Server) den Besuchern stand. In der Zwischenzeit hab ich da einige Joinabfragen eingefügt und ich denke, dass es vlt daran liegt.

In den Laufzeitinformationen(PMA) hab ich folgende Infos gefunden:

Zitat:
Select_full_join 5,920 k Anzahl der Joins ohne Schlüssel. Wenn dieser Wert nicht 0 ist sollten die Indizes der Tabellen sorgfältig überprüft werden.
Select_range_check 9,825 Anzahl der Joins ohne Schlüssel, bei denen nach jeder Zeile auf Schlüsselbenutzung geprüft wurde. Wenn dieser Wert nicht 0 ist sollten die Indizes der Tabellen sorgfältig überprüft werden.
Da auf dem Server ja mehrere Kunden sind, weiß ich nun nicht, ob diese Angaben von mir sind, oder eventuell von einem anderen.

Kann ich irgendwie nachgucken, ob meine Joins da zutreffen?
Würde zwar denken, dass ich die Tabellen normalisiert habe, aber nunja.

Würde es sonst eventuell Helfen statt mysql_query() oder so dauernt zu schreiben, das Ganze in eine DB Klasse umzuschreiben?
Die ganze Seite ist atm so gecodet und basiert auf keinem CMS oder Framework.

Ich hoffe, dass man mit der Frage was anfangen kann, bzw. mit dem Problem.

Vlt waren es auch einfach zuviele Besucher für das Webhosting-paket, aber ich möchte zumindest alle Ursachen meinerseits ausschließen.

mfg
Mit Zitat antworten
  #2 (permalink)  
Alt 29-12-2008, 10:57
pekka
 PHP Master
Links : Onlinestatus : pekka ist offline
Registriert seit: Jun 2001
Ort: Köln
Beiträge: 6.608
pekka befindet sich auf einem aufstrebenden Ast
Standard

Hast Du denn Indexe gesetzt für jede Spalte der von den Joins betroffenen Tabellen, wie mySQL es empfiehlt? Das reduziert die Last für die Datenbank nämlich erheblich.

Wenn Du viele Seiten mit sich selten ändernden Inhalten auslieferst, kann eventuell eine Template-Engine wie Smarty helfen, die Datenbanklast zu schonen.

Ansonsten hilft nur das Aufspüren der Laststellen mittels ordentlichem Profiling. Da müssen wir alle durch
Mit Zitat antworten
  #3 (permalink)  
Alt 29-12-2008, 11:38
combie
 PHP Expert
Links : Onlinestatus : combie ist offline
Registriert seit: May 2006
Beiträge: 3.296
combie wird schon bald berühmt werden
Standard

EXPLAIN SELECT ....
Kann dabei ungemein hilfreich sein.
__________________
Wir werden alle sterben
Mit Zitat antworten
  #4 (permalink)  
Alt 29-12-2008, 17:22
Blackgreetz
 PHP Junior
Links : Onlinestatus : Blackgreetz ist offline
Registriert seit: Oct 2005
Beiträge: 901
Blackgreetz ist zur Zeit noch ein unbeschriebenes Blatt
Standard

Zitat:
Original geschrieben von pekka
Hast Du denn Indexe gesetzt für jede Spalte der von den Joins betroffenen Tabellen, wie mySQL es empfiehlt? Das reduziert die Last für die Datenbank nämlich erheblich.
Bis jetzt wohl eher nicht:

PHP-Code:
"SELECT * FROM images LEFT JOIN favcards ON ( id = BildID AND UserID =".$userid." ) WHERE category = ".$cat
Wäre es viel schneller, wenn ich statt images.* auch noch images.[Spalten] schreiben würde?

@combie: Guck ich mir gleich mal an

mfg
Mit Zitat antworten
  #5 (permalink)  
Alt 29-12-2008, 17:31
TobiaZ
  Moderator
Links : Onlinestatus : TobiaZ ist offline
Registriert seit: Jan 2001
Ort: MUC und MGL, Germany
Beiträge: 34.421
Blog-Einträge: 1
TobiaZ befindet sich auf einem aufstrebenden Ast
Standard

Wie kannst du an dieser Query erkennen, ob die Tabellen nen entsprechenden Index haben oder nicht?

Das aufzählen den Spalten ist zwar generell zu empfehlen, dürfte aber im Normalfall nur wenig in Richtung Performance bringen.
__________________
ERST LESEN: Unsere Regeln. | Ich hab schon Pferde kotzen sehn!

READ THIS: Strings richtig trennen/verbinden | JOINs, das leidige Thema | Wegwerf E-Mail Adressen

Ich werde keinen privaten 1:1 Support leisten, außer ich biete ihn ausdrücklich an.

Wenn man sich selbst als "Noob" bezeichnet, sollte man die Finger davon lassen.
Wenn man gewillt ist daran etwas zu ändern, lernt man Grundlagen!
Mit Zitat antworten
  #6 (permalink)  
Alt 29-12-2008, 18:09
combie
 PHP Expert
Links : Onlinestatus : combie ist offline
Registriert seit: May 2006
Beiträge: 3.296
combie wird schon bald berühmt werden
Standard

Zitat:
Das aufzählen den Spalten ist zwar generell zu empfehlen, dürfte aber im Normalfall nur wenig in Richtung Performance bringen.
Sehe ich auch so!
Zumindest wenn dort keine/wenige BLOB und TEXT bei sind.
__________________
Wir werden alle sterben
Mit Zitat antworten
  #7 (permalink)  
Alt 29-12-2008, 18:26
Blackgreetz
 PHP Junior
Links : Onlinestatus : Blackgreetz ist offline
Registriert seit: Oct 2005
Beiträge: 901
Blackgreetz ist zur Zeit noch ein unbeschriebenes Blatt
Standard

Okay.

Zum Thema Index: Ich hab den Begriff wohl falsch interpretiert.

Ihr wolltet auf Primary Key usw. raus?

Wenn ich einfach mal bei deim JOIN da bleibe:

Tabelle images:
ID = Primary Key ... somit ein Index..

Die Tabelle favcards hat keinen Index. Zumindest keinen so explizit definierten Index.

Sie setzt sich nur aus der BildID & UserID zusammen.
BildID = ID der Tabelle images
UserID = ID der Tabelle user (dort auch Primary key)

Nun kann ich weder BildID, noch UserID die Eigenschaft Primary Key oder unique geben. Bleibt also theoretisch nur INDEX.

Dann müsste ich aber theoretisch beiden Feldern den INDEX geben, oder nicht? - wäre das nicht widersprüchlich bzw. uneffektiv?

mfg
Mit Zitat antworten
  #8 (permalink)  
Alt 29-12-2008, 18:30
combie
 PHP Expert
Links : Onlinestatus : combie ist offline
Registriert seit: May 2006
Beiträge: 3.296
combie wird schon bald berühmt werden
Standard

Du könntest auch einen kombinierten Index auf BEIDE Spalten legen.
Das ist ab und an besser als immer nur einzelne Spalten mit einem Index zu versehen.

Aber wie gesagt:
Experimentiere mit EXPLAIN ...
Dessen Ausgabe ist das Maß aller Dinge!
__________________
Wir werden alle sterben

Geändert von combie (29-12-2008 um 18:34 Uhr)
Mit Zitat antworten
  #9 (permalink)  
Alt 11-12-2009, 20:41
Blackgreetz
 PHP Junior
Links : Onlinestatus : Blackgreetz ist offline
Registriert seit: Oct 2005
Beiträge: 901
Blackgreetz ist zur Zeit noch ein unbeschriebenes Blatt
Standard

Hi,

lange ists her, aber nun ist ja bald wieder Weihnachten, .. da stellt sich wieder dieses Problem.

Ich hab nun mit Explain da experimentiert. Für den oben angegebenen Join stand ALL, ALL da. Also -> super mies.

Darauf hin habe ich in der Tabelle favcards einen kombinierten PK auf beide Spalten gelegt, sodass es von ALL auf eq_ref geändert wurde und bei rows nur noch 1 steht, statt der Anzahl der Einträge in der Tabelle.

Kann ich somit davon ausgehen, dass solch ein kombi- PK bei der Zusatztabelle der n:n-Beziehung Standard ist? (also man es immer so macht?)

Ich hab dann allerdings noch ein Problem.

Tabelle: Kategorie
ID Primary Key,
name varchar(50)

Tabelle: Images
ID Primary Key,
category INT

Nun ist ja zwischen Images und Kat. noch eine 1:n - Beziehung (category - Kat.ID). Somit ist category ja der Fremdschlüssel im Ref. auf den PK bei Kategorie. In MySQL funktionieren aber Foreign Keys - Angaben ja nur unter InnoDB, richtig?
Meine DB nutzt zwar dieses Format, aber soll man sich dann auch darauf festlegen? Wenn ja, was ist, wenn man einen Serverwechsel hat und dort nutzt man statt InnoDB ->MyISAM. Dann müsste man ja theoreitsch die Tabellen wieder ändern, wenn man "FK-Angaben" nutzt.

Frage: Soll man nun angeben, dass es sich um einen FK handelt und sich somit festlegen auf InnoDB, oder nicht?
PHPMyAdmin hat mir vorgeschlagen, als ich einen Index in 'images' hinzufügen wollte, PK, Unique, FullText und Index.
PK geht ja nicht, ist ja bereits ID. Unique wäre unsinnig, weil ja mehrere Bilder in ein und die selbe Kategorie fallen können und FullText auf den INT-Schlüssel..., naja. Bleibt also nur noch ein ein Index auf "category" legen zu können.

Bleibt am ende: Index oder FK?

Wenn ich einen FK auf category lege, bleiben nur die effected rows statt aller Einträge übrig. und ALL -> ref.

Hoffe ich hab mich halbwegs verständlich ausgedrückt und mich nicht zu doof angestellt.

mfg
Edit: Vlt wäre das Thema jetzt in nem anderen Forum als Brainstorming besser aufgehoben.

Geändert von Blackgreetz (11-12-2009 um 21:00 Uhr)
Mit Zitat antworten
Antwort

Lesezeichen


Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Gäste: 1)
 

Themen-Optionen
Thema bewerten
Thema bewerten:

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.

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


PHP News

ebiz-trader 7.5.0 mit PHP7 Unterstützung veröffentlicht
ebiz-trader 7.5.0 mit PHP7 Unterstützung veröffentlichtDie bekannte Marktplatzsoftware ebiz-trader ist in der Version 7.5.0 veröffentlicht worden.

28.05.2018 | Berni

Wissensbestand in Unternehmen
Wissensbestand in UnternehmenLebenslanges Lernen und Weiterbilden sichert Wissensbestand in Unternehmen

25.05.2018 | Berni


 

Aktuelle PHP Scripte

PHP Server Monitor

PHP Server Monitor ist ein Skript, das prüft, ob Ihre Websites und Server betriebsbereit sind.

11.09.2018 Berni | Kategorie: PHP/ Security
PHP WEB STATISTIK ansehen PHP WEB STATISTIK

Die PHP Web Statistik bietet Ihnen ein einfach zu konfigurierendes Script zur Aufzeichnung und grafischen und textuellen Auswertung der Besuchern Ihrer Webseite. Folgende zeitlichen Module sind verfügbar: Jahr, Monat, Tag, Wochentag, Stunde Folgende son

28.08.2018 phpwebstat | Kategorie: PHP/ Counter
Affilinator - Affilinet XML Produktlisten Skript

Die Affilinator Affilinet XML Edition ist ein vollautomatisches Skript zum einlesen und darstellen der Affili.net (Partnerprogramm Netzwerk) Produktlisten und Produktdaten. Im Grunde gibt der Webmaster seine Affilinet PartnerID ein und hat dann unmittelb

27.08.2018 freefrank@ | Kategorie: PHP/ Partnerprogramme
 Alle PHP Scripte anzeigen

Alle Zeitangaben in WEZ +2. Es ist jetzt 05:29 Uhr.