I just made a snapshot of the development branch of the innotop MySQL and InnoDB monitor, and released it as version 1.3.0. This code will eventually become version 1.4. Here's what's new.

This article explains how to create a fixed-size FIFO (first-in, first-out) queue in SQL, where rows added after a threshold will cause the oldest row to be deleted. There are several ways to do this, but MERGE on Oracle and DB2, and MySQL's non-standard extensions to SQL, make an elegant solution easy.

Sometimes you need to think backwards.

Here was the problem. I needed to match up some IP address ranges to the company that owns them. Looking for a simple solution to the problem I came up with storing the IP address block patterns in the database as follows:

ip_pattern
----------------
127.%.%.%
192.168.%.%
10.%.%.%

Any idea why I choose % as the wildcard?

That's right - it's the wildcard operator in SQL for the LIKE statement.

So now when I have have an IP address 192.168.1.1, I can do what I like to call a backwards LIKE query:

SELECT company, ip_pattern
FROM company_blocks
WHERE '192.168.1.1' LIKE ip_pattern

This works on SQL Server and MySQL, and I would think it should work fine on any database server.

I've made the 1.0 release I promised yesterday. I am very happy to declare innotop production-ready and stable. In this article I talk a little bit about my plans for the future, and look back to the project's humble beginnings as a script I ran inside watch. Check out the screenshot! OMG!

A couple of weeks ago I submitted a request to open a new project on Sourceforge for the innotop MySQL and InnoDB monitor. I want to make it easier for others to collaborate, especially package maintainers. Yesterday I got word of its approval. I have done a quick-and-dirty import of the source code into its new home, and I'm now continuing work on the next major version, which I've been working on for about six weeks. This post is about Sourceforge, what I've gotten done, and also to ask for your help.

I recently read O'Reilly's SQL Hacks book. It's an interesting and rewarding mixture of tips and tricks for novice to expert users. I give it 3 out of 5 stars. Here's why.

Brian Aker recently wrote about a "skeleton project" for quickly bootstrapping a development environment for a new software project. I do something similar for Perl programs that I want to connect to MySQL.

I sometimes see advice to do SQL date operations with the + and - operators on platforms where they are overloaded for date types. I try to avoid that, because it can give unexpected results. I prefer to explicitly use the built-in date/time functions. I'll show you an example where the operators cause problems, but the functions do the right thing.

MySQL's user variables have interesting properties that enable the useful techniques I wrote about in recent articles. One property is that you can read from and assign to a user variable simultaneously, because an assignment can be an r-value (the result of the assignment is the final value of the variable). Another property, which sometimes causes confusing behavior, is un-intuitive evaluation time. In this post I'll show you how to make sure your variables get updated at the time they're used, instead of potentially reading and updating them at different stages of query execution. This technique enables a whole new range of applications for user variables. As a bonus, it also avoids extra columns of output created by variable manipulations.

It's been a while since I released an update to innotop, but I have not been idle. I'm currently working hard to add major new features and functionality. Here's a quick list of what's coming.