About a month ago, we held a bug raffle for Percona Toolkit 2.1.9. The turnout was good and the resulting release is worth upgrading to, especially if you were affected by the backwards-incompatible changes to pt-heartbeat in 2.1.8. Here are the release notes for Percona Toolkit 2.1.9 which highlight the bugs fixed: Percona Toolkit 2.1.9 has been released. [...]
Percona and the MariaDB Foundation
December 19, 2012 By 3 Comments
There have been several reports (1,2,3) describing Percona’s stance regarding the MariaDB Foundation that are not totally accurate so I though it would be worth it to describe where we stand on this and related matters. First, let me say the creation of theMariaDB Foundation is a good thing for the MariaDB Community and I’m [...]
The Optimization That (Often) Isn’t: Index Merge Intersection
December 14, 2012 By 6 Comments
Prior to version 5.0, MySQL could only use one index per table in a given query without any exceptions; folks that didn’t understand this limitation would often have tables with lots of single-column indexes on columns which commonly appeared in their WHERE clauses, and they’d wonder why the EXPLAIN plan for a given SELECT would [...]
Full table scan vs full index scan performance
November 23, 2012 By 15 Comments
Earlier this week, Cédric blogged about how easy we can get confused between a covering index and a full index scan in the EXPLAIN output. While a covering index (seen with EXPLAIN as Extra: Using index) is a very interesting performance optimization, a full index scan (type: index) is according to the documentation the 2nd [...]
Concatenating MyISAM files
November 19, 2012 By 5 Comments
Recently, I found myself involved in the migration of a large read-only InnoDB database to MyISAM (eventually packed). The only issue was that for one of the table, we were talking of 5 TB of data, 23B rows. Not small… I calculated that with something like insert into MyISAM_table… select * from Innodb_table… would take [...]
Recovering from a bad UPDATE statement
October 19, 2012 By 5 Comments
Did you just run an UPDATE against your 10 million row users table without a WHERE clause? Did you know that in MySQL 5.5 that sometimes you can recover from a bad UPDATE statement? This is possible if you are running in binlog_format=ROW ! Imagine this scenario:
1 2 3 4 5 6 | CREATE TABLE `t1` ( `c1` int(11) NOT NULL AUTO_INCREMENT, `c2` varchar(10) NOT NULL, PRIMARY KEY (`c1`) ) ENGINE=InnoDB; INSERT INTO `t1` (`c2`) VALUES ('michael'), ('peter'), ('aamina'); |
We run an accidental UPDATE statement that [...]
Tools and Techniques for Index Design Webinar Questions Followup
October 4, 2012 By 5 Comments
I presented a webinar this week to give an overview of Tools and Techniques for Index Design. Even if you missed the webinar, you can register for it, and you’ll be emailed a link to the recording. I’d like to invite folks who are interested in tools for query optimization to attend the new Percona [...]
Logging Deadlock errors
September 19, 2012 By 4 Comments
The principal source of information for InnoDB diagnostics is the output of SHOW ENGINE INNODB STATUS but there are some sections that are not very useful. For example, LATEST DETECTED DEADLOCK only shows, as the name implies, the latest error detected. If you have 100 deadlocks per minute you will be able to see only [...]
Wow. My 6 year old MySQL Bug is finally fixed in MySQL 5.6
August 30, 2012 By 2 Comments
I got the message in the morning today about the bug being fixed in MySQL 5.6.6…. which I reported in Early 2006 (while still being with MySQL) and running MySQL 4.1 I honestly thought this issue was fixed long ago as it was indeed pretty annoying. I must say I’m very impressed with Oracle team [...]
Recovery after DROP & CREATE
August 22, 2012 By 1 Comment
In a very popular data loss scenario a table is dropped and empty one is created with the same name. This is because mysqldump in many cases generates the “DROP TABLE” instruction before the “CREATE TABLE”:
1 2 3 4 5 6 7 8 9 10 11 12 | DROP TABLE IF EXISTS `actor`; /*!40101 SET @saved_cs_client = @@character_set_client */; /*!40101 SET character_set_client = utf8 */; CREATE TABLE `actor` ( `actor_id` smallint(5) unsigned NOT NULL AUTO_INCREMENT, `first_name` varchar(45) NOT NULL, `last_name` varchar(45) NOT NULL, `last_update` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`actor_id`), KEY `idx_actor_last_name` (`last_name`) ) ENGINE=InnoDB AUTO_INCREMENT=201 DEFAULT CHARSET=utf8; /*!40101 SET character_set_client = @saved_cs_client */; |
If there were no subsequent CREATE TABLE the recovery would be trivial. Index_id of the PRIMARY index of [...]
