I have rehashed a list of useful reporting queries from my blog which I hope people would find useful for their business or clients. These are not MySQL specific, by any means.

Orders

• What is the total revenue (by segments)? - You are looking for 'peaks and troughs'. For example, found a peak season? you can plan better for it next year. Found an off-season? perhaps offer some deals for that period.
• What is the total placed orders, completed orders and abandoned/uncompleted orders?
• What is the total paid revenue vs outstanding orders? 
• What is the total number of returned/cancelled orders and lost revenue from them?

Products (Best Sellers)

• Which are the top 20% best selling products? (businesses love 80/20 comparisons and if you look at reports a lot, you will too)
• Which are the products that our best customers keep …

I’m happy to announce that the recording for my recent webinar “5 Proactive Measures to Minimize MySQL Downtime” is now available, along with the slides. They can both be found here.

My webinar focused on the top 5 operational measures that prevent or reduce downtime — along with the related business impact in a significant number of customer emergency scenarios.

As a senior consultant on Percona’s 24×7 Emergency Consulting team, I’ve helped resolve a …

Looking at the committers/authors of patches in the bzr tree for MariaDB 5.5.31.

Non Oracle Contributors:

1. Alexander Barkov
2. Alexey Botchkov
3. Elena Stepanova
4. Igor Babaev
5. knielsen
6. Michael Widenius
7. sanja
8. Sergei Golubchik
9. Sergey Petrunya
10. timour
11. Vladislav Vaintroub

Oracle (as they pull Oracle changes):

1. Aditya A
2. Akhila Maddukuri
3. Alexander Nozdrin
4. Anirudh Mangipudi
5. Annamalai Gurusami
6. Astha Pareek
7. Balasubramanian Kandasamy
8. Chaithra Gopalareddy
9. Daniel Fischer
10. Gleb Shchepa
11. Harin Vadodaria
12. Hery Ramilison
13. Igor Solodovnikov
14. Inaam Rana
15. Jon Olav Hauglid
16. kevin.lewis
17. Krunal …

I grabbed all the tests introduced in MariaDB 5.5.32 (i.e. “bzr diff -rtag:mariadb-5.5.31..mariadb-5.5.32 mysql-test/” and some foo) and threw them in their own test file. I only kept tests for crashing bugs and ignored those that required plugins (there were two or three, but nothing major). So now I have a test file that should crash MariaDB 5.5.31 and probably before. But, the question is: does this crash Percona Server or MySQL?

While it is excellent to see the MariaDB guys including tests for their crashing bugs, are these MariaDB specific or do they affect other MySQL flavours?

I built a release build of top of trunk Percona Server and ran the test against it. I got no crashes. In a debug build, I got two. One was to do with REPAIR on an ARCHIVE table and the other was “SELECT UNIX_TIMESTAMP(STR_TO_DATE(’2020′,’%Y’));”. I found the same thing for a debug build of top of tree MySQL.

All the other tests …

To only slightly misquote one of the greatest movies of all times:

You keep using that option.  I do not think it means what you think it means.

Perhaps like many users, I had certain assumptions about what max_connect_errors really does – but in looking closely as part of investigating the new PERFORMANCE_SCHEMA.HOST_CACHE table in MySQL 5.6, I learned that some very fundamental elements had escaped my notice.  I’m writing this blog post to help others who hold similar misconceptions of what this option does.

Many, if not most, MySQL DBAs are familiar with “host blocked” errors:

C:\mysql-5.5.27-winx64>bin\mysql -utest_mce -P3307 -h192.168.2.8
ERROR 1129 (HY000): Host …

The much-improved PERFORMANCE_SCHEMA in MySQL 5.6 provides visibility into MySQL’s host cache, including the ability to monitor for impending blocked hosts.  You can do this with the following query:

mysql> SELECT
    ->  ip,
    ->  host,
    ->  host_validated,
    ->  sum_connect_errors
    -> FROM performance_schema.host_cache\G
*************************** 1. row ***************************
                ip: 192.168.2.4
              host: TFARMER-MYSQL.wh.oracle.com
    host_validated: YES
sum_connect_errors: 3
1 row in set (0.02 sec)

That’s helpful information, and allows DBAs to identify problematic hosts before they are blocked.  Due to Bug#69807, it’s also something MySQL 5.6 users will want to do.  This bug causes the counter maintained in the host …

More and more blogs are springing up to cover database technologies. This ethereal Log Buffer Edition yet again cherishes this spectacular growth and offers a few links from the Oracle, SQL Server, and MySQL arenas.

Oracle:

Are Oracle enqueue rules leading to deadlock changes again in 12.1? Charles Hooper asks.

James Morle writes about optimal Oracle configuration for efficient table scanning.

Richard Foote writes a quick post on the reuse of empty leaf blocks in index.

…

MySQL Tech Tour

Please join us for our Tech Tour event hosted by Oracle MySQL experts and learn more about Oracle’s strategy for MySQL, including continued investment in the world’s most popular open source database.

Houston August 27th

Austin August 28th

Dallas August 29th

Mississauga, Canada August 14th …

How can this be? I am shocked. I have looked at query plans, confirmed indexes, checked handler status variables after query execution to figure out what MySQL is up to, and I don’t think there is anything wrong with it. MySQL is using the right index, using ICP, Batched Key Access. Basically, everything that we can throw at it. I even tried MariaDB and it used the new Batched Hash Join. Same result. Postgres is done in 150ms and MySQL 5.6 takes 3s!

We had a customer who was migrating from Postgres to MySQL approach us about a slow running query. Here’s the situation. They have a fleet of cars, which are loaned out to customers for short periods of time. The cars have sensors that report mileage periodically. They want to figure out which customer drove how many miles during a certain time period. Easy enough, right?

The cust_car table (25K rows) captures which customer had which car and what was the odometer reading when it was …

If in October you're around in Paris area, don't miss the following event which we're preparing in collaboration with French MySQL User Group. The event is fully technical (trust me ;-)), and all the stuff will be presented by my good friends from different MySQL Dev Teams at Oracle. I'm pretty sure this event will be really great! And I'm also expecting to have such Tech Days delivered on a more regular basis - we become better and better organized, and, of course, we have always a lot of things to tell you ;-)

So, open your agenda, and follow our official announce :

MySQL Tech Day @Paris
We're happy to announce you that MySQL Tech Day will take place in Paris on Oct 10, 2013 in Oracle main office. It'll be a full day event giving you an occasion to listen directly from Oracle developers about most of the improvements made recently within MySQL 5.6 and 5.7 development.

…