[*the_rob*]

Und im PHP-Code wo sich also die Abfrage dann befindet muss nichts geändert werden?

EDIT:
Das Feld in dem die Namen stehen an wen der Eintrag gerichtet ist hat jetzt einen Index. Typ: INDEX...

Außerdem hat das Feld ID noch einen Index... Typ: PRIMARY...

Bringt jedoch immernoch nichts... Es lädt genauso langsam wie auch zuvor..

[Waq]

Zitat von Lars

`content` LIKE '%suchwort%'
;
 

wäre es sinnvoll, einen Index auf die Spalte "content"

Leider daneben, denn auf Indizes können nur head-matches gemacht werden.

LIKE 'suchwort%' ginge, aber für Volltextsuchen braucht man nen Volltext-Index.

PS: Fürs Gästebuch sehe ich spontan Bedarf für einen Multi-Column-Index auf `an` und `id`. Einzelne Indizes bringen bei MySQL hier nichts.
Dann macht man mal ein EXPLAIN auf die SQL-Queries des Gästebuches, und wenn brav überall der Index verwendet wird und nirgendwo "ALL" steht ist das meiste gut.

[*the_rob*]

Wie erstelle ich einen Multi-Column-Index?
Ich kann in meinem MySQLAdmin folgende Typen auswählen:
INDEX
UNIQUE
FULLTEXT

Bin ich hier auf dem falschen Weg?

Sorry aber wie gesagt habe ich einfach keine Ahnung denn ich habe mit Indizes noch nicht gearbeitet...

[Waq]

http://www.google.de/search?hl=de&ie...mn+index+mysql

Du hast 7 Bedingunge in diesem kleinen Codeabschnitt. Bedingungen brauchen sehr sehr lange, deshalb solltest du dir evtl deinen Quellcode überdenken. Außerdem kann ein Cache Wunder bewirken. Es reicht ein simpler in PHP geschriebener Filecache, allerdings wäre natürlich der APC Cache perfekt. Damit kannst du nämlich zB auch Konfigurationsvariablen cachen.
Falls du CAPTCHAS generierst, solltest du vielleich ein paar tausend erstellen und nach Zufall ausgeben anstatt jedes mal ein neues Image zu generieren.
...

Poste mal einen Link oder erzähl mal was so alles auf der Seite ist.

MfG Jay

[Lars]

Leider daneben, denn auf Indizes können nur head-matches gemacht werden.

LIKE 'suchwort%' ginge, aber für Volltextsuchen braucht man nen Volltext-Index.

Ah, danke. So kann auch ich mein Wissen auffüllen

[*the_rob*]

Zitat von Jay

Du hast 7 Bedingunge in diesem kleinen Codeabschnitt. Bedingungen brauchen sehr sehr lange, deshalb solltest du dir evtl deinen Quellcode überdenken. Außerdem kann ein Cache Wunder bewirken. Es reicht ein simpler in PHP geschriebener Filecache, allerdings wäre natürlich der APC Cache perfekt. Damit kannst du nämlich zB auch Konfigurationsvariablen cachen.
Falls du CAPTCHAS generierst, solltest du vielleich ein paar tausend erstellen und nach Zufall ausgeben anstatt jedes mal ein neues Image zu generieren.
...

Poste mal einen Link oder erzähl mal was so alles auf der Seite ist.

MfG Jay

Die Website ist unter der URL http://www.nb-treff.com zu erreichen...
Das was du sagst hört sich sehr gut an... Allerdings hab ich keine Ahnung das umzusetzen...
Wärst du so freundlich und könntest mit mir vielleicher per ICQ kontakt aufnehmen?
Ich bin echt am verzweifeln...

führ doch mal bitte

SHOW CREATE TABLE gbeintraege;

in phpmyadmin aus und poste das ergebnis hier.

selbst bei hundert millionen einträgen und hunderten von gleichzeitigen verbindungen kommt mysql normalerweise nicht mal ins schwitzen. es sind die besch*ssen gesetzten indexe und der stümperhafte code eindeutig schuld.

grüße
axo

Wärst du so freundlich und könntest mit mir vielleicher per ICQ kontakt aufnehmen?

Nein

PHP-Code:

$db->query("SELECT * FROM `gbeintraege` WHERE `an`='" . addslashes($username) . "' ORDER BY `id` DESC");
$Gesamt=$db->num_rows(); 


Du selektierst hier alle Eintrag damit du weißt wieviele es in der DB gibt?
SELECT COUNT (*) ... wäre wesentlich schneller. Ich meine du selektierst alle und lässt sie dann zählen. Es ist wesentlich schneller alle zu zählen und die Daten in der DB zu lasssen.
Wenn du die Einträge im GB nie löscht könntest du auch MAX (primaryKeyId) verwenden. Somit bekommst du auch die Anzahl. Das ist schneller als COUNT funktioniert aber nur wenn keine Einträge gelöscht werden.

[*the_rob*]

Zitat von axo

führ doch mal bitte

SHOW CREATE TABLE gbeintraege;

in phpmyadmin aus und poste das ergebnis hier.

CREATE TABLE `gbeintraege` (\n `ID` int(11) NOT NULL auto_increment,\n `an` varchar(100) NOT NULL default '',\n `name` varchar(100) NOT NULL,\n `eintrag` text NOT NULL,\n `date` varchar(50) NOT NULL,\n `fontcolor` varchar(7) NOT NULL,\n PRIMARY KEY (`ID`),\n KEY `an` (`an`)\n) ENGINE=MyISAM DEFAULT CHARSET=latin1

[Waq]

Und es fehlt immer noch der Multi-Column-Index...

[$traight-$hoota]

Zitat von Jay

SELECT COUNT (*) ... wäre wesentlich schneller. Ich meine du selektierst alle und lässt sie dann zählen. Es ist wesentlich schneller alle zu zählen und die Daten in der DB zu lasssen.
Wenn du die Einträge im GB nie löscht könntest du auch MAX (primaryKeyId) verwenden. Somit bekommst du auch die Anzahl. Das ist schneller als COUNT funktioniert aber nur wenn keine Einträge gelöscht werden.

MAX bringt hier wohl nix, da nur alle einträge, die an einen user gesendet worden sind, gezählt werden sollen. sonst hätte ja jeder 700.000 gb einträge...

aber selbst bei den 1000 beiträgen die manche leute drinne haben, würde ich mir doch mal überlegen, ob die nicht irgendwann ma gelöscht werden. die braucht vermutlich doch eh keiner mehr.

als optimierung der db könntest du die tabelle auch von namen-bezeichner auf ids (foreign key) umstellen, so dass du eine extra tabelle mit allen benutzern hast (die ja vermutlich eh schon existiert) und die db tabelle enthält dann nur noch eine eintrag-id, eine sender-id und eine empfänger-id sowie den inhalt.
dadurch wird die tabelle kleiner, schneller zu durchsuchen und unnötige redundanz wird vermieden.

btw: hab mir grad mal deine page angeguckt und im öffentlichen guestbook crahst das design bei einem eintrag von heute, 15:45 weil da jemand nur punkte aneinandergereiht hat.