MySQL user's Conference

Bradley Baetz bbaetz at acm.org
Fri Apr 18 07:10:46 UTC 2003


On Fri, Apr 18, 2003 at 02:50:31AM -0400, Daniel Berlin wrote:
> Well, if you are cpu bound, and are using 4.x, among other things, you  
> should turn on the query cache (It's disabled by default).

bmo is 3.23.x.

> I dunno if anyone ever tuned the mysql on b.m.o. If not, you probably  
> want to look at the my-(huge, large).cnf files that exist somewhere  
> (it's in /usr/share/mysql on my machine).
> They are generally the settings you should be using as a starting point  
> to tune from (huge is for 1G-2G mainly mysql running machines, large is  
> for 512M mainly mysql running machines)

I have this vague recollection that its a 4G machine, but I'm not
too sure.

> For GCC, our attachments are mainly huge preprocessed source files, so  
> it helps quite a bit.
> We get about a 70% reduction in attachment size.

Yeah, it would help with the size, but since its on a separate table
which we really don't look at that often I don't think it would save
anything apart from diskspace.

> It might, there were some problems in the range optimizer of 3.x with  
> InnoDB, i believe.
> 

It could be. I think the plans were teh same, though, but I can't really
remember.

> I'll also note that if I create a bug_id, who index, like so:
> 
> create index bug_id_who on longdescs(bug_id, who);
> 
> then both database types use the new index for the query, and the query  
> takes 0.1 on either MyISAM or InnoDB.

Well, thats a mysql limitation again. :)

> If this query is common, we should probably add this index.

Its not; it was just an example in a bug somewhere which was easy to set
up a simple test for. Thats the issue; buglist.cgi is basically
completely ad-hoc, so its hard to tune correctly.

Bradley



More information about the developers mailing list