I dette særtema ser vi på, hvordan cloud og AI bliver fundamentet for virksomhedernes digitale forretning, og hvordan de nye muligheder for automatisering og forretningsværdi kan udnyttes uden at miste overblik, sikkerhed og menneskelig kontrol.
Den med * er altid god, kun tag de felter du bruger. Hvis du nogen steder bruger paging, så sørg for i stedet for at lave en SELECT COUNT() og så en SELECT bagefter, så brug SELECT SQL_FOUND_ROWS og SELECT FOUND_ROWS() - Det er blidere mod serveren. Fyr de mest almindelige queries af i en mysql console, med EXPLAIN (altså EXPLAIN SELECT felt, felt2 FROM tabel osv) og se om de er optimale - temp tables, full table scans osv er ikke godt, ej heller filesorts... Hvis sådanne optræder skal man nok finde nogle bedre indexes eller dele queries op... Brug LigHTTPD i stedet for apache...? Kan ikke lige komme på flere :)
Den burde være hurtig nok ;) Specielt hvis du laver et index på feltet time :) Vi kan godt dele pointene hvis det er :) Jeg ville have skrevet det sådan:
$sql = "SELECT tekst, fra FROM admin_txt WHERE `time` = $tid-4"; $postZ2Z = mysql_query($sql);
Du kan muligvis også gøre det med phpMyAdmin hvis du ikke har adgang til en console (måske har PMA endda værktøjer til det?) - En explain ser sådan ud:
mysql> explain select article.headline, user.username from article inner join user on article.byuser = user.userid where article.byuser = 1; +---------+-------+---------------+---------+---------+-------+------+-------------+ | table | type | possible_keys | key | key_len | ref | rows | Extra | +---------+-------+---------------+---------+---------+-------+------+-------------+ | user | const | PRIMARY | PRIMARY | 4 | const | 1 | | | article | ALL | NULL | NULL | NULL | NULL | 4 | Using where | +---------+-------+---------------+---------+---------+-------+------+-------------+ 2 rows in set (0.00 sec)
Her kan du se hvordan MySQL serveren behandler query'en - Du kan se "key" er NULL begge steder her, hvilket betyder at den er nødt til at kigge på alle rækker (se "rows") i tabellen - Hvis jeg så tilføjer et index på byuser ser den sådan ud:
mysql> alter table article add index (byuser); Query OK, 4 rows affected (0.01 sec) Records: 4 Duplicates: 0 Warnings: 0
mysql> explain select article.headline, user.username from article inner join user on article.byuser = user.userid where article.byuser = 1; +---------+-------+---------------+---------+---------+-------+------+-------------+ | table | type | possible_keys | key | key_len | ref | rows | Extra | +---------+-------+---------------+---------+---------+-------+------+-------------+ | user | const | PRIMARY | PRIMARY | 4 | const | 1 | | | article | ref | byuser | byuser | 4 | const | 2 | Using where | +---------+-------+---------------+---------+---------+-------+------+-------------+ 2 rows in set (0.00 sec)
Her kan du se at den nu benytter indexet og det gør query'en væsentligt hurtigere! "Faretegn" i en explain er hvis "Extra" indeholder "filesort" eller "temporary table" eller hvis den ikke bruger nogen "key"...
"Hvis du nogen steder bruger paging, så sørg for i stedet for at lave en SELECT COUNT() og så en SELECT bagefter, så brug SELECT SQL_FOUND_ROWS og SELECT FOUND_ROWS() - Det er blidere mod serveren."
Well ja, men det her er jo ikke paging ;) En typisk paging query (med sidetal 1 2 3 osv) bruger LIMIT i SQL'en - og så kan man ikke få det totale antal rækker, så skal du enten bruge SELECT COUNT() først (dårligt) eller bruge SQL_FOUND_ROWS (godt) :)
Hmnææh ikke lige i hovedet nu - Du kan eksperimentere med at bruge ob_start/ob_gzhandler: http://dk2.php.net/ob_gzhandler - Eller hvis du har en server med apache, så mod_gzip eller bedre adgang til php.ini og bruge zlib.output_compression det kan man af og til vinde en del ved ;) (Det sparer også båndbredde)
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.