mysql> check table noneofyourbusiness quick ;

Table                            Op     Msg_type  Msg_text 
 noneofyourbusiness   check status          OK  
1 row in set (56 min 26.29 sec)

You know you want to go. Its going to be in Tokyo, Japan. Having passed by the Narita airport quite some number of times, I’ve always wondered what was beyond those walls.

MySQL UC-J: September 11-12 2007

I would sincerely encourage all folk in the Asia-Pacific region, using or dabbling in MySQL to attempt to be there. Thats right, I’m calling on you folk from Singapore, Malaysia, China, Korea, Thailand, and how can we forget our beloved Australia & New Zealand (though I’m not sure if flying to Tokyo is any less harrowing an experience than flying to San Francisco).

Flights are going to be shorter, they are going to be cheaper, and you’re going to get to see Tokyo. More importantly, if you pre-register, rumor has it, you will not be paying an attendance fee. Seats will be snapped up fast. Session lineups are amazing. What more can I say besides its going to be a great & fun experience for all.

…

MySQL AB will hold its first ever MySQL users conference in Asia this September. Over the course of two days, the 'MySQL Users Conference Japan 2007' will feature a special executive keynote presentation, more than 15 business and technical sessions, and exhibition booths. About half of the sessions are presented in English with English-Japanese simultaneous translation.

This is a review of Webyog's MONyog MySQL monitoring tool. The product is still in beta and has some rough edges, but holds promise. Its design includes some interesting architectural decisions I think will help distinguish it from MySQL's own Monitoring and Advisory Service. MONyog overview MONyog starts an HTTP listener on your machine. After you start the program, you point your Web browser at localhost:9999. Your browser talks to MONyog, which talks to one or many MySQL servers.

Just an observation:
eBay now supports sending notifications to various IM networks... the usual list. Except Skype. Now that's curious, since eBay owns Skype, right? I would expect it to be the first offered, or at the very least be on the list....

I had this question asked many times during last week, and there is really no easy answer. There are just way too many variables to consider especially while loading large schemas with a lot of different table structures. So which variables affect the load speed:

Table Structure This one is tricky. The shorter rows you have the faster load will normally be, if you measure rows, but if you measure in amount of loaded data longer rows are faster.

Indexes The more indexes you have the longer load would take. Details depend on storage engines, for example MyISAM can build non-unique indexes by sort which is very fast and Innodb can use insert buffer for them.

Data Insert Order It is well known it is important to load data in primary key order into Innodb tables for optimal performance, but effect does not end here. If indexes are built by inserts in Btree order in which …

I will now and then blog in English as sometimes there is a need for people to comment in English. To get things started I asked several questions from Ignacio Correas of Warp , one of the leading Open Source companies out of Spain.

1. How did you get started?

The idea of founding a consultancy company specialized on open source technologies came from six guys which were probable the best Linux experts and most active open source advocates in the region. A year before, I had left a good job in Finland to try to start the same kind of company in Zaragoza, so when they asked me to join in as the non-geek member of the team I could not resist.

Before founding Warp we applied to become a part of CEEI, which is a incubator for innovative companies funded by the regional government and which gives some grants and support for its members. On the other hand, …

When we tried to clean up a rather large (4.500.000 rows, 20GB) InnoDB table some days ago, we were astonished by the time MySQL took to complete the task. We had already LIMITed the transaction size, but every single chunk still took minutes to execute. The table itself contains some number columns, including a numeric primary key, and a blob. The delete condition was mainly based on the primary key (being smaller than a predefined value) and status field. After some mails between the support crew and us an optimizer bug was identified: MySQL Bug #28554.

The problem is that in some cases the optimizer makes a bad choice concerning which index to use. It will pick a secondary index that can be used to cover a WHERE indexed_column=<constant> condition, even though it will cause way more data to be scanned than necessary. The primary key for …

When we tried to clean up a rather large (4.500.000 rows, 20GB) InnoDB table some days ago, we were astonished by the time MySQL took to complete the task. We had already LIMITed the transaction size, but every single chunk still took minutes to execute. The table itself contains some number columns, including a numeric primary key, and a blob. The delete condition was mainly based on the primary key (being smaller than a predefined value) and status field. After some mails between the support crew and us an optimizer bug was identified: MySQL Bug #28554.

The problem is that in some cases the optimizer makes a bad choice concerning which index to use. It will pick a secondary index that can be used to cover a WHERE indexed_column=<constant> condition, even though it will cause way more data to be scanned than necessary. The primary key for …

As I wrote we had been recovering corrupted Innodb Tablespace and it is finally done now.

As this was over than 1TB worth of data we really tried to avoid dumping the data and find some other way to recovery.
Examining Innodb page content and crash information we figured out it should be page of insert buffer itself, rather than page belonging to some of the pages touched by insert buffer.

If that would be just the table it should have been easy - dropping the table with corrupted page would remove all appropriate insert buffer records and be able just to load that table back. Unfortunately we were not that lucky.

If the page corrupted in insert buffer itself there seems to be no way to make Innodb avoid touching it. Even when we dropped all Innodb tables (for test purposes) Innodb still was crashing if we …