Todd Farmer’s MySQL 5.7 talk can been seen at http://www.youtube.com/user/sfmysql. For those few of you who did not stay up to watch Todd live, you get TWO slide decks in just over ninety minutes — it is almost the next best as being at the San Francisco Users Group in person.

I’ve covered some strange default behavior around nulls in MySQL. There’s another nuance to this issue: you can still insert rows without specifying values for not null columns. MySQL will helpfully give you a default value (this is not really helpful – true help would be a quick failure with a descriptive error message). Let’s walk through this example.

mysql> Create Table NullTable (a Int Not Null, b Int Not Null);
Query OK, 0 rows affected (0.01 sec)

Here’s a table with two not null columns.

mysql> Insert Into NullTable (a) Values (1);
Query OK, 1 row affected, 1 warning (0.01 sec)

We can totally insert, even though we didn’t specify a value for b and b is not null.

mysql> Show Warnings;
+---------+------+----------------------------------------+
| Level   | Code | Message …

In my previous post I wrote about how I achived a >40% speedup on sysbench read-only using profile-guided optimisation (PGO). While this is a preliminary result, I though it was so interesting that it deserved early mention. The fact that any benchmark can be improved that much shows clearly that PGO is something worth looking into. Even if we will probably not improve all workloads by 40%, it seems highly likely that we can obtain significant gains also for many real workloads.

I had one or two interesting comments on the post that raise valid concerns, so I wanted to write a follow-up here, explaining some of the points in more details and going deeper into the performance counter measurements. As I wrote before, actual observations and measurements are crucial to fully understand performance of complex code on modern CPUs. Intuition and …

This is the very first post in the series of Performance Schema Implementation Internals. This series is for MySQL Developers to understand implementation of Performance Schema. For user point of view of performance Schema, please refer to mysql documentation link : http://dev.mysql.com/doc/refman/5.7/en/performance-schema-quick-start.html

This post talks about the mechanism to register instruments in Performance Schema (referred as P_S from hereon) so that their statistics could be collected at runtime.

To understand this, lets first understand different instrument classes in P_S.

Instrument Classes in P_S:

An enum PFS_class_type is there to keep track of all possible classes of instruments.

enum PFS_class_type
{
…

FOSDEM is a free, yearly event that offers open source communities a place to meet, share ideas and collaborate. It takes place in Brussels, Belgium each February.

10 years ago now, the first MySQL devroom was organized there by David Axmark, marking the first time MySQL users got their own space to come together and discuss at the event. On this anniversary edition, Percona consultants will be present at the MySQL & Friends Community Booth, as well as giving talks in the devroom (full schedule):

* Frédéric Descamps at 12.35 with …

I confess I am a Galera fanboy. This post is going to present two slogans about Galera reminding you about Galera “limitations”. This is for the sake of user experience:)

Galera Phrases:

• One Cluster
• Replication

One Cluster

Think about Galera as One Cluster. As every transaction is committed virtually synchronously, the slowest node determines the (DML) speed of the cluster. This is true regarding the network too.

Replication

• Galera is still some kind of replication. So keep in mind to provide PK as for (ROW based) Replication. There is a Featurerequest of mine to have a PK option to enforce creating of Tables with a PK. Please vote for it:)

• With traditional MySQL Replication the slave might lag. This is …

I’m excited to be speaking at the Percona Live MySQL Conference again this year. I’ll present two sessions: Developing MySQL Applications with Go and Knowing the Unknowable: Per-Query Metrics. The first is a walk-through of everything I’ve learned over the last 18 months writing large-scale MySQL-backed applications with Google’s Go language. The second is about using statistical techniques to find out things you can’t even measure, such as how much CPU a query really causes MySQL to use. There are great reasons that this is both desirable to know, and impossible to do directly in the server …

I’m excited to be speaking at the Percona Live MySQL Conference again this year. I’ll present two sessions: Developing MySQL Applications with Go and Knowing the Unknowable: Per-Query Metrics. The first is a walk-through of everything I’ve learned over the last 18 months writing large-scale MySQL-backed applications with Google’s Go language. The second is about using statistical techniques to find out things you can’t even measure, such as how much CPU a query really causes MySQL to use.

Beware of bugs in the above code; I have only proved it correct, not tried it.
Donald Knuth

Bugs in software are a fact of life. MySQL, as part of Oracle, issues of Critical Patch Updates and Security Alerts notices. You may have seen Daniel van Eeden‘s blog on the January announcement.

Daniel’s summary:

For MySQL 5.6 you should upgrade to 5.6.15
For MySQL 5.5 you should upgrade to 5.5.35
For MySQL 5.1 you should upgrade to 5.1.73

But you probably missed the executive summary.

But how do YOU get this information when it become available? …

Devart is glad to release the new improved version of dbForge Studio for MySQL, v.6.1.