php og mysql ydelse

Ja, selvfølgelig skal du gøre det.

Eller måske skal du lade være.


Spørgsmålet er nok nærmere, hvordan du bruger dine data samt hvordan dit php-kode ser ud. Det er måske ikke engang muligt for dig, at samle dine to tabeller.
Har du indekseret dine tabeller?
Har du set på ydelsen af din php-kode kontra udførelsestiden for dine SQL-statements?

Du skal normalisere din database så langt som det går. Du skal f ex ikke have samme data i flere rækker. Læs lidt om normalisering. Som det ser ud skal du nok snarere bryde users tabellen ud til flere tabeller. Men som mrgumble siger: check indexering og php kode. Tvivler på at du har så meget data så du kan knække en MySQL base ;o)

Hej igen

php koden er presset, men på ingen måde så presset som mysql.
Jeg har været nødsaget til at benytte memcache da databasen simpelthen ikke kan følge med. Jeg har ca 300 sidevisninger i sekundtet, og der er select/insert/update på langt de fleste af siderne.
Med hensyn til insert,select så er det optimeret så meget som muligt.
Nu skal jeg så finde ud af om en tabel arbejder langsommere hvis der er flere felter i den.
I mine selects bruger jeg kun SELECT x,x,x og altså ikke SELECT *

Håber i forstår :)

Er det en delt eller egen server du kører på ?

Har du overvejet at cache dine sider ? Det er vel ikke alle sider som ændre sig hele tiden.

Det er egen server, dog ikke min, men en jeg lejer mig ind på.

Lige nu cacher jeg det dynamiske i headeren, altså det som går igen på alle sider.

Da det er et spil ligger der naturligvis en "account" osv i toppen på alle sider, og da det er dynamisk, er det et problem (så vidt jeg ved) at cache siderne. Så min bedste løsning indtil nu har været at cache mysql i headeren.

Jeg tror ærligt talt ikke det gør den store forskel. Spørgsmålet er nok nærmere hvilke og hvor mange opslag du laver.

Eksempelvis så trækker rekursive opslag tungt på databasen, især hvis opslagene udføres enkeltvis i modsætning til en stored procedure:
http://dev.mysql.com/tech-resources/articles/mysql-storedprocedures.html

En anden ting du kan skære ned på så vidt muligt er hvor meget du skriver til databasen. Kan du undgå at skrive så meget data til databasen? Kan du i øvrigt skære ned på antallet af forespørgsler der laves på hver side? Kan du eksempelvis tjekke en session efter login, i stedet for et databaseopslag, på hver side?

Brug i øvrigt aldrig WHERE felt LIKE '%noget%' på tabeller med over cirka 8000-10000 rækker, da metoden er enormt langsom. Brug så vidt muligt aldrig WHERE LIKE. Skal du søge tekster igennem så kik på noget fulltext search:
http://dev.mysql.com/doc/refman/5.0/en/fulltext-search.html

Sidst men ikke mindst så sørg for at alle dine tabeller er korrekt indekseret; for lidt indexes gør at et opslag kan tage meget langt tid (hvis Mysql skal udføre et "full table scan"). For mange indexes kan have den konsekvens at det tager langt tid at skrive til databasen. Put et index på alle felter du søger på.

Jeg valgte at smide det over i users. Om det var godt eller skidt ved jeg ikke :( Optimering af database er en jungle :(

Takker mange gange. Svar?

Jeg lukker.. Skriv endelig hvis der er brok