If interested in contributing code to MySQL, you should attend the MySQL University session on contributing code to MySQL.

(Live broadcast with Q&A will be held on Thursday, June 25, 2009. You can still have access to rebroadcasts afterwards.)

Summary: An alternate approach, offered in response to our original post, provides excellent improvements for smaller databases, but clustered indexes offer better performance as database size increases.  (This posting is by Dave.)

Jay Pipes suggested an alternate approach to improving MySQL performance of Query 17 on a TPC-H-like database.

1. 
   
2. Add the index (l_partkey, l_quantity) to the lineitem table.
   
3. Re-write the query as:
   

   select 
      sum(li.l_extendedprice) / 7.0 as avg_yearly 
   from lineitem li 
      inner join part p on li.l_partkey = p.p_partkey 
      inner join ( select 
                      l_partkey, 0.2 * avg(l_quantity) as quantity 
                   from lineitem 
                   group by l_partkey 
                 ) as quantities 
         on …

This post doesn’t contain a tip, I’m asking the q and I don’t know the answer yet. Could just be a logic error on my part, in which case it was just a personal mystery and I thank you for helping!

MySQL error 1449 “There is no ‘username’@'host’ registered”

You can get a replication fail with this error if you have triggers, views or stored routines that run as their creator (which is usual) but the slave does not have that user. So far so good.

We just encountered a replication fail on multiple slaves (i.e. not a single isolated mishap) with this error on an UPDATE statement accessing a single base table (i.e. no view), and no triggers defined or routines called in the query. Indeed the slave did not have the reported user (intentionally), but that shouldn’t have mattered. Creating the user allowed replication to continue successfully – that’s no surprise either.

The question …

Peter Lieverdink (also known as cafuego on IRC/identi.ca, engineer on OurDelta builds and for Open Query) has co-authored a book that’s available since Monday. The title is Pro Linux System Administration published by Apress.

These days some people don’t want to bother with system administration, and either hire or outsource. Others want to find out more and do things themselves (home and small office use), and that’s the intended audience for this book.

If interested in contributing code to MySQL, you should attend the MySQL University session on contributing code to MySQL.

(Live broadcast with Q&A will be held on Thursday, June 25, 2009. You can still have access to rebroadcasts afterwards.)

If interested in contributing code to MySQL, you should attend the MySQL University session on contributing code to MySQL.

(Live broadcast with Q&A will be held on Thursday, June 25, 2009. You can still have access to rebroadcasts afterwards.)

When you write your create table statements, always make sure that you make them non-ambiguous. That way even though other servers might have different configurations, you make sure your table will be created in the same way.
Imagine for instance you are developing an application on a development server, nicely storing all the scripts you need to create the same database on your production server. If the same script creates a table differently on both servers, that might cause you a lot of headache later on. At Open Query, we strive to minimise (or preferrably eliminate) headaches.

One of the parts of the create table statement that has the largest impact is the storage engine specification. When you omit the storage engine from the create table statement, your table is automatically created with the default storage engine type configured for the server. Since the storage engine is a very important choice when designing your tables, …

A couple of weeks ago, Baron Schwartz wrote an interesting post describing a rule of thumb he sometimes uses to choose the order of columns in an index. In a nutshell, he recommends putting highly selective columns first. This is a very good rule of thumb.

I would like to add another rule of thumb: columns that are used for equality comparisons are better than columns that are used for range queries.

If one has a query “select count(*) from foo where a BETWEEN 10 and 20 and b=5”, an index of (b,a) will always be as good, and likely better, than an index of (a,b), regardless of the selectivity of “a” or “b”.

This is because of how MySQL performs range queries. For an index of (a,b), a range query will be done from (10,5) to (20,5). This will require many rows to be processed where …

After four years, this blog has a new home. We've just upgraded www.opensourcestrategies.com to use WordPress. We hope you'll continue to follow opentaps Open Source ERP + CRM and our life as an open source software company there.