full table scan

I kan evt. se fejlen på www.milestones.nu. den kommer på alle undersider, da det er en standardside, der bare hiver data ind fra databasen

"full tabelscan" betyder at der ikke er et pssende index som kan bruges til at afgrænse dine data - men at alle data i tabellen skal læses.

ok, hvad skal jeg så tilføje for at komme udenom fejlen?

Du skal tilføje et index, som dækker de kolonner du filtrerer på i dit SQL-statement.

Her er min meget simple sql: $strSQL="SELECT xpos, ypos, div_name, display FROM text  WHERE page_id='$page_id'"; hvad skal der helt præcist gøres ved den? jeg har ikke lige arbejdet med indexering før

Opret et index med feltet page_id

For det første bør du nok slå den php-option til der ignorerer warnings fra mysql, da det er rimelig forvirrende for brugerne.

For det andet bør du muligvis lave et index på page_id i text tabellen.
  ALTER TABLE `text` ADD INDEX `page_id_ix` ( `page_id` );

skulle ha' været et svar

Hvad er primærnøglen i tabellen 'text'?

primærnøglen er text_id. Er det så text_id og ikke page_id jeg skal oprette indexet på? for at slå warnings i mysql fra, skal jeg have fat i dem der hoster min side, så der kan blive ændret i php.ini ikke?

For at løse problemet med den viste query, så er det page_id du skal have index på.

Det er dog altid en god ide også at have et index på den primære nøgle (er iøvrigt et krav hvis man vil bruge autogenerede nøgler).

Alle søgninger hvor du ønsker at optimere søgetiden på, kan du tilføje index på de relevante tabeller udfra flg.:
* alle felter hvor der søges på præcis match (med = og ingen wildcards!) skal felterne placeres først i indexet.
* hvis du har order by på andre felter, kan du evt tilføje dem i indexet i samme rækkefølge som i order by.

Det er dog altid en afvejning med index, da jo flere index du tilføjer til en database, jo hurtigere kan den søge ting frem, men jo længere tid tager det at tilføje/opdatere records.

Nu har jeg oprettet indexet på page_id og får nu fejlen: PHP has encountered an Access Violation at 02030AFD. Kan det være mit webhotel der har lavet om i konfiguraionen?

Jeg har lige snakket med Azero og det er hos dem der er sket en fejl med deres MySQL server. Men tak for inputs, og jeg fik da lige lært lidt om index ;-)