Percona's MySQL & InnoDB performance and scalability blog
One of the most common causes of a poor Sphinx search performance I find our customers face is misuse of search filters. In this article I will cover how Sphinx attributes (which are normally used for filtering) work, when they are a good idea to use and what to do when they are not, but [...]
While we do have many blog posts on replication on our blog, such as on replication being single-threaded, on semi-synchronous replication or on estimating replication capacity, I don’t think we have one that covers the very basics of how MySQL replication really works on the high level. Or it’s been so long ago I can’t [...]
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 [...]
There are number of people recently blogging about MySQL automated failover, based on production incident which GitHub disclosed. Here is my take on it. When we look at systems providing high availability we can identify 2 cases of system breaking down. First is when the system itself has a bug or limitations which does not [...]
I continue my benchmarks of Intel SSD 910, previous time I compared it with Fusion-io ioDrive http://www.mysqlperformanceblog.com/2012/09/07/intel-ssd-910-in-tpcc-mysql-benchmark/. Now I want to test this card against RAID over spinning disks.
While doing a performance audit for a customer a few weeks ago, I tried to improve the response time of their top slow query according to pt-query-digest‘s report. This query was run very frequently and had very unstable performance: during the time data was collected, response time varied from 50µs to 1s. When I ran [...]
As you may know, flushing in MySQL is an area of my interest, I wrote about it several times, i.e. http://www.mysqlperformanceblog.com/2011/09/18/disaster-mysql-5-5-flushing/ http://www.mysqlperformanceblog.com/2011/03/31/innodb-flushing-a-lot-of-memory-and-slow-disk/ http://www.mysqlperformanceblog.com/2011/01/03/mysql-5-5-8-in-search-of-stability/ In MySQL 5.6 there was implemented a new flushing logic, so I decided to check what do we have now.
Spoiler alert: If your boss does not need an elephant, he is definitely NOT going to buy one from you. If he will, he will regret it and eventually you will too. I must appologize to the reader who was expecting to find an advice on selling useless goods to his boss. While I do [...]
I presented a webinar this week to give an overview of several Full Text Search solutions and compare their performance. Even if you missed the webinar, you can register for it, and you’ll be emailed a link to the recording. During my webinar, a number of attendees asked some good questions. Here are their questions and my [...]
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 [...]
Copyright © Percona LLC • Contact Us • MySQL and InnoDB are trademarks of Oracle Corp.