MariaDB announced their 5.3 GA and 5.5 alpha releases.
Oracle will be at DrupalCon in Denver, CO from Monday, March 19th through Friday, March 23rd.
Percona's XtraDB cluster announcement
XtraDB Cluster at the San Francisco MySQL Meetup
on Wednesday, March 21st
I have been working with Peter in preparation for the talk comparing the optimizer enhancements in MySQL 5.6 and MariaDB 5.5. We are taking a look at and benchmarking optimizer enhancements one by one. So in the same way this blog post is aimed at a new optimizer enhancement Index Condition Pushdown (ICP). Its available in both MySQL 5.6 and MariaDB 5.5
The post Index Condition Pushdown in MySQL 5.6 and MariaDB 5.5 and its performance impact appeared first on ovais.tariq.
This week we present the how's and why's of benchmarking MySQL.
News/Feedback:
MySQL Cluster 7.2 can do one billion queries per
minute, what does that actually mean?
Percona's XtraDB cluster announcement
XtraDB Cluster at the San Francisco MySQL Meetup
on Wednesday, March 21st
XtraDB Webinar on Wednesday April 4th
In the latest episode of our “Meet The MySQL Experts” podcast, Dimitri Kravtchuk talks to us about MySQL Performance. He reviews at a high level improvements made over the past few years, including in MySQL 5.5, as well as MySQL Enterprise Scalability, some of the new MySQL 5.6 features improving performance and more.
Enjoy the podcast!
Last weekend Vadim from Percona published his MariaDB 5.3.4 benchmark results. As the new benchmark guy at Monty Program I take this oportunity to add some more results of my own.
One question in the comments to Vadim was if it is fair to compare MariaDB-5.3 with MySQL-5.5. Or if this comparison should be done with MySQL-5.1. The answer is: it does not matter much. MySQL-5.5 and MySQL-5.1 show very similar results in the Sysbench OLTP benchmark.
So I created a Sysbench environment pretty much like Vadims and tested the following versions of the MySQL Server:
Turn on the Slow Query Log (if it is not already turned on) and
monitor what goes into it. Statements that are logged there are
candidates for tuning. Note, however, that statements will only
be logged there if they take longer than long_query_time seconds
to run, so statements triggering full scans of small tables that
execute very quickly may not show up. Once you have found tuning
candidates, use the EXPLAIN statement on the queries to see which
tables should have indexes added to them.
If you are using MySQL 4.1 or later you can use the
--log-queries-not-using-indexes option to log all statements that
do a full table scan, even if they would not otherwise qualify
for the slow query log.
Note that full table scans are not necessarily bad, as long as
they are confined to very small tables, so be sure to take table
size into account as you review your queries and their EXPLAIN
plans.
I published an SQLite3 storage back-end to NIST::NVD on the CPAN. It’s pretty quick. About as fast as the DB_File one, but without the down side of being tied to DB_File. It shouldn’t be too difficult to re-factor this code to any DBI-based database. MariaDB anyone?
I know it works on Debian. The nightly CPAN test results should come back shortly and I’ll find out how well it works on other platforms.
MySQL, like a lot of other software, has many knobs you can tweak. Most of these knobs may affect behaviour, but more importantly most affect the memory usage of the server, so getting these settings right is very important.
Most of MySQL’s memory is really used just as a cache, in one form or another, information that otherwise is on disk. So ensuring you have as large a cache as possible is important. However, making these memory sizes too large will trigger the server to start swapping and possibly can cause it to crash or cause the kernel to kill the process when it runs out of memory. So that’s something we want to avoid.
Certain settings affect memory allocation on a per connection/thread basis, being bounded by thread_cache_size and max_connections. If you configure for the worst behaviour (max_connections) you may end up not actually using all the memory you have available, memory which normally could be …
[Read more]MySQL has two confusingly identical by the first look variables myisam_sort_buffer_size and sort_buffer_size. Thing is that those two confusingly similar variables has absolutely different meanings.
sort_buffer_size is a per-connection variable and do not belongs to any specific storage engine. It doesn’t matter do you use MyISAM or InnoDB – MySQL will allocate sort_buffer_size for every sort (required most of the times for ORDER BY and GROUP BY queries) so increasing it’s value might help speeding up those queries however I would not recommend to change it from the default value unless you are absolutely sure about all the drawbacks. Value for out-of-the-box MySQL-5.1.41 installation on Ubuntu is 2Mb and it’s recommended to keep it that way.
On …
[Read more]TokuDB® v5.2, the latest version of Tokutek’s flagship storage engine for MySQL and MariaDB, is now available.
This version offers performance enhancements over previous releases, especially for multi-client scale up and point queries, and extends the cases where ALTER TABLE is non-blocking, in particular adding Hot Column Rename.
TokuDB v5.2 maintains all our established advantages: fast trickle load, fast bulk load, fast range queries through clustering indexes, hot schema changes, great compression, no fragmentation, and full MySQL compatibility for ease of installation. See our benchmark page for details.
Multi-client workloads
In TokuDB v5.2, we have reworked our locking scheme to better support multi-client workloads, and as always, we have focused on large databases. How did we do? Let’s check out some …
[Read more]