- Response time at 1 thread for 5.7.5 is between 1.55X and 1.67X worse than 5.0.85
- Response time at 32 threads for 5.7.5 is between 1.19X and 1.49X worse than 5.0.85
- In all cases it is worse in 5.7 than in
Installing, configuring, deploying databases and performing repetitive administrative tasks are all part of a DBA’s or sysadmin’s job. This can get pretty repetitive and overwhelming if you are part of a centralized IT team, running multiple databases for your organization’s different departments, or a managed hosting provider responsible for setting up and operating databases for external clients. One way to get out of this ‘manual, repetitive task’ business is through a Database as a Service (DBaaS).
DBaaS is a way of delivering database functionality as a service to one or more consumers. A DBaaS platform would provide automated procedures for database deployment, monitoring,[Read more...]
The MySQL Server 5.7.5 Development Milestone Release, which was published recently, contains some significant changes to the metadata locking (MDL) subsystem and to the usage of the THR_LOCK manager for InnoDB tables. This post provides more information about these changes, which resulted in nice improvements in both scalability and performance.
Sometime during the development cycle of MySQL 5.6 we realized that locks used in the metadata locking subsystem (MDL) implementation can become a scalability bottleneck when many short statements were executed in @autocommit=1 mode against InnoDB tables.
Bug #66473 is a good example (8-table Sysbench[Read more...]
Following my previous post, I got some excellent feedback in the forms of comments, tweets and other chat. In no particular order:
EXPLAIN command is one of MySQL’s most useful tools for understanding query performance. When you
EXPLAIN a query, MySQL will return the plan created by the query optimizer. It also shows you how that query will be indexed and an estimate of how many rows are processed by that query. From this information, it is easy to see if your queries are taking advantage of table indexes or if you can change them for some extra performance. VividCortex provides a lot of information on query performance, including samples of the queries that are run against your database. Now, those samples will have
EXPLAIN data for them too!
So what does the
EXPLAIN feature look like in VividCortex? Here’s a screenshot to illustrate:
Those who are[Read more...]
This week we did some migrations from MariaDB 10.0 to Percona Server 5.6 at the IT department of a big German bank.
We were perfectly aware that since version 10.0 the MariaDB code base started to diverge slightly away from the MySQL and Percona Server code base which are still pretty close to each other.
Because of the Percona Server[Read more...]
Last week I blogged about getting sysbench working with libAttachSQL. This was not only an exercise in performance but also the first real test for libAttachSQL.
Before I had done this testing the most the early Alpha and Beta releases of libAttachSQL had gone through is a few basic queries. So, the first thing I did when I got the sysbench driver working was slap it with 1,000,000 queries. It pretty much exploded instantly on that. Over the course of this release I have probably hit it with over 100,000,000 queries and things run a lot smoother.
This has led to today's release of libAttachSQL 0.5.0. As far as changes go this release has the[Read more...]
Since I recently wrote about both MySQL error 1071 and error 1070 I decided to continue the pattern with a quick note on MySQL error 1069. In case you've never seen it before, this is MySQL error 1069:
ERROR 1069 (42000): Too many keys specified; max 64 keys allowed
I can't think of a valid use case that requires more than 64 indexes on a MySQL table, but it's possible to get this error by inadvertantly adding lots of duplicate indexes to a table. This can happen if you don't explicitly name your indexes.
Read on for[Read more...]
This is the next part of the stories about MySQL 5.7 Performance..
So far, the previous story was about reaching 645K QPS with SQL queries, while in reality it's only a half of the full story ;-) -- because when last year we've reached 500K QPS due a huge improvement on the TRX-list code, the same improvement made a negative impact on the all single-table test workloads..
What happened finally :
As I mentioned on my last post, where I compared the default configurations options in 5.6 and 5.7, I have been doing some testing for a particular load in several versions of MySQL. What I have been checking is different ways to load a CSV file (the same file I used for testing the compression tools) into MySQL. For those seasoned MySQL DBAs and programmers, you probably know the answer, so you can jump over to my 5.6 versus 5.7 results. However, the first part of this post is dedicated for developers and MySQL beginners that want to know the answer to the title question, in a step-by-step fashion. I must say I[Read more...]