Re[2]: [PHP-DB] Optimising LIMITs - alter table order by...

From: Date: Tue, 02 Mar 2004 12:46:54 +0000
Subject: Re[2]: [PHP-DB] Optimising LIMITs - alter table order by...
References: 1 2 3 4  Groups: php.db 
Request: Send a blank email to php-db+get-33253@lists.php.net to get a copy of this message
Hello Pavel, Tuesday, March 2, 2004, 12:33:17 PM, you wrote: PL> PL> http://www.mysql.com/documentation/mysql/bychapter/manual_SQL_Syntax.html#ALTER_TABLE PL> ORDER BY allows you to create the new table with the rows in a specific PL> order. Note that the table will not remain in this order after inserts PL> and deletes. In some cases, it might make sorting easier for MySQL if Figured as much, thanks for the reference. I hope one day MySQL will produce a manual that isn't one horrendous long document per section. PL> You need to split the table and move "post messages" to another table if PL> you want to get higher perfomance for (2). With regard to disk seeking, here is my table structure: CREATE TABLE thread ( threadid int(10) unsigned NOT NULL auto_increment, site_user_id varchar(32) NOT NULL default '', boardid tinyint(3) unsigned NOT NULL default '0', subject varchar(200) NOT NULL default '', modified timestamp(14) NOT NULL, created timestamp(14) NOT NULL, status enum('L','P','H','D') NOT NULL default 'L', PRIMARY KEY (threadid), FULLTEXT KEY subject (subject), KEY boardid (boardid), KEY site_user_id (site_user_id), KEY created (created), KEY status (status) ) TYPE=MyISAM; As well as moving the subject field to another table (because it's the only non-defined length field), would another way of speeding up the disk seek be to turn it from a varchar(200) into a char(200)? I know it means a larger table size, but MySQL should then be able to calculate exactly where to jump to in the file? PL> All MySQL functions should be very optimized, but there may be some PL> exceptions. BENCHMARK(loop_count,expression) is a great tool to find out PL> if this is a problem with your query. I will look at this now. I had been toying with the idea of creating a cache table that held the 200 most recent threads, pre-sequenced so I just bring back that instead of having to query the database unless they go beyond that 200 limit. Your comments (and MySQL manual posts) have been very useful, thank you. -- Best regards, Richard Davey http://www.phpcommunity.org/wiki/296.html

« previous php.db (#33253) next »