It is important to know and understand that while indexing columns in MySQL will generally improve performance, using the appropriate type of index can make a greater impact on performance.

There are four general index types to consider when creating an appropriate index to optimize SQL queries.

• Column Index
• Concatenated Index
• Covering Index
• Partial Index

For the purpose of this discussion I am excluding other specialized index types such as fulltext, spatial and hash in memory engine.

Example Table

For the following examples, I will use this test table structure.

DROP TABLE IF EXISTS t1;
CREATE TABLE t1(
  id INT UNSIGNED NOT NULL AUTO_INCREMENT,
  user_name VARCHAR(20) NOT NULL,
  first_name VARCHAR(30) NOT NULL,
  last_name VARCHAR(30) NOT NULL,
  external_id INT UNSIGNED NOT NULL,
  country_id SMALLINT UNSIGNED NOT NULL,
  PRIMARY KEY(id)
) …

There was small delay in our releases, part of this time we worked on features I mentioned before:
- Moving InnoDB tables between servers
- Improve InnoDB recovery time
and rest time we played with performance trying to align XtraDB performance with MySQL 5.4 ® and also port all performance fixes to 5.0 tree.

So basically we made: new split-buffer-mutex patch, which separate global buffer pool mutex into several small mutexes, and ported some Google IO fixes.
Here are results what we have so far. As usually for benchmarks I used our workhorse Dell PowerEdge R900 with 16 cores and 32GB of RAM and RAID 10 on 8 SAS disks. And again as usually our tpcc-mysql scripts with 100W …

Note This Article was actually written back in May after the UC at the request of Linux Magazine, through a series of events It went unpublished. Between then and now Jeremy ended up doing a great job covering most of the topics, so in the end it was unneeded. Now I had this completed article and thought, what should I do with it? In the I decided to publish them here. Also note I did update a few items.

As more companies move to MySQL and the demands for data increase, we push the bounds of the database further. The challenges large Web properties (who have pioneered many of the large MySQL deployments) faced when they stored 50GB of data and had 5,000 users were nothing like the challenges of storing 500GB of data supporting 100,000 users. Today, as we are seeing more and more 10+TB-sized datasets being …

Video for the presentation at the 2009 MySQL Camp:
Chasing Bottlenecks
by Morgan Tocker

Description:
The best way to performance tune a system is to find out what your bottlenecks are, and attacking those first. In the first part of this session, I'll be looking at some of the issues faced with common database workloads. From there, I'll then be showing how you can get more information out of MySQL and your Operating System to find out about your workload. This session is designed for beginner to intermediate MySQL users.

read more

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 …

Yves pointed this out to me:

http://www.internetnews.com/software/article.php/3825426/

“Moving beyond just providing Oracle compatibility, EnterpriseDB is adding new scalability features to their database. One of them is a feature called ‘”Infinite Cache,” which is based on the open source memcached application.

Mlodgenski commented that distributed memory caches are common, though management from a system management and a database perspective is often difficult.

“What we did is we took the distributed memory cache that was sitting in front of the database and put it behind the database,” Mlodgenski said. “This allows a simple SQL (define) interface for developers that allows access to the distributed memory cache and now the system management overhead is handed by the database itself.”

Mlodgenski added that Infinite Cache leads to a 10x to 20x performance gain for read application loads. …

Today marks the official launch of Percona.tv. We'll be uploading technical screencasts, conference video, and anything else cool we can think up. If you've got ideas or requests, let us know and we'll do our best to accommodate!

Entry posted by Ryan Lowe | 7 comments

Add to: | | | …

Hi again!

Just a moment ago, I read this post by Peter Gulutzan. In this post, Peter explains a little trick that allows you to capture the SQL state in a variable whenever an error occurs in your MySQL stored routine code.MySQL CONDITIONs and HANDLERsFor the uninitiated: in MySQL stored routines, you can declare HANDLERs which are pieces of code that are executed only in case a particular CONDITION occurs. This device serves the same purpose …

There has been a significant increase in interest in the Memcached, the open source distributed memory object-caching system, in recent months, as a number of vendors look to exploit its popularity in Web 2.0 and social networking environments.

Like Hadoop, which has become the focus of a number of commercial plays, it would appear that the time is right for commercialization of Memcached. But what is it, here did it come from, and what are the chances for vendors to rake in serious cash? Here are the details.

What is it?
Pronounced mem-cash-dee, Memcached was originally created by Danga Interactive (the developer of LiveJournal, which was acquired by Six Apart in 2005) to speed up the performance of dynamic Web applications by alleviating database load. Memcached has become an industry standard for improving the performance of dynamic websites.

The code is available from the …

Executive Summary: A query like TPC-H Query 17 can be sped up by large factors by using straight_joins and clustering indexes.  (This entry posted by Dave.)

In a previous post, we wrote about queries like TPC-H query 2, and the use of straight_join to improve performance. 
This week, we consider Query 17, described by the TPC-H documentation as

“The Small-Quantity-Order Revenue Query considers parts of a given brand and with a given container type and determines the average lineitem quantity of such parts ordered for all orders (past and pending) in the 7-year database.  What would the average yearly gross (undiscounted) loss in revenue if orders for these parts with a quantity of this average were no longer taken?”

Our initial run on Q17 (same hardware as before) timed out …