Peter Zaitsev over at the excellent MySQL Performance Blog recently wrote an article on duplicated and redundant indexes -- any indexes which cover exactly the same columns as another index, or cover a leftmost prefix of another index. While there are subtleties, such as FULLTEXT indexes not being the same as non-FULLTEXT, for the most part this is sufficient criteria to raise possible duplicates to a DBA's attention. I opened my big mouth in the comments and said I could write a quick Perl script to discover possible offenders in just a few lines of code. Once I did that, I had to do it and give you the script. Here it is.

I've been writing a lot of articles about locks, deadlocks, and transactions recently, and it occurs to me I've neglected to mention the single most important thing to know. If you only learn one thing about transactions in database systems, you should learn this, and learn it thoroughly -- burn it into your brain permanently, if possible.

MySQL issues a cryptic error message, "Error on rename," when you try to alter a table in such a way that it would break a foreign key constraint.

I've released version 0.1.146 of the innotop MySQL and InnoDB monitor. You can download innotop from the original article.

I re-arranged some information to be more compact and readable in this version, but there isn't really much new functionality. This is mostly a bug-fix release to prevent crashes when innotop encounters unexpected information, or doesn't find some information it expects to exist. It's still very much beta software, so it may die unexpectedly. See this article about what information I need to debug and fix crashes.

Crashes should not cause any loss of information or other problems, by the way. It's completely safe to run, because it doesn't modify anything, it just reads status information. Up till now I've preferred …

This is my second article on how to build a role-based access control system in SQL. In the first article I gave a high-level overview of access control systems in general, especially in the web-application context, and talked about how some are implemented. I introduced the problems I designed my system to solve, and gave a roadmap for where this series of articles will end. I finished that article with a sketch of some basics to provide row-level read, write, and delete access control.

This article picks up where I left off. I want to revisit some things I swept under the rug in the first article, because I didn't want to throw all the complexity in at once. I'll explain my current system's full functionality, which includes roles, type checking, table-level and set-level privileges, and more. I will show you the design in great detail, and give working examples and ready-to-run SQL queries. I'll also explore ideas for extending or …

The posts I've been reading and writing recently have reminded me how Object-Relational Mapping (ORM) systems make it fun and convenient to interact with databases. For some of the reasons they're a developer's favorite, they can be a database administrator's nightmare (think surrogate keys). But designing tables with a consistent set of columns has its benefits. Just because the columns are meta-data that have no intrinsic meaning doesn't mean they have no value. In this series of articles I'll show you several ways to use such "meaningless" meta-data to enable powerful, efficient application-level role-based access control (RBAC) in the database, with a focus on web applications, though you could do this for any application.

The systems I've built are complex, so I'll split this into at least two articles. This first article will discuss other privilege systems I've seen in web applications, including …

I wrote an article a while back about how to order updates in MySQL so you don't violate a unique index. I said I'd write another article on how to swap numbers in a sequence with a unique index. This is that article, but I'm going to make it a little more generic: how to reverse a (possibly ordered) sequence.

I've been thinking about this for a while, wondering if there's a way I can do it in-place in one statement (I like to pile challenge upon difficulty). I've thought of a number of techniques, some using one statement, some using more, some that won't work on MySQL, some that will.

Quite a few people have chimed in on a recent discussion about PHP, MySQL, database abstraction layers, and performance. I think enough viewpoints have been covered that I don't need to comment, but one question I don't see answered is "what are the qualities of a good SQL abstraction layer?" I think it's a very interesting -- and complicated -- question. As it turns out, the term has several meanings, and I think it's important to understand them. In this article I explain one way to categorize different types of database abstraction layers, the goals for each, and some useful success criteria.

This is one in a series of articles on how to use innotop, a MySQL and InnoDB monitor. In this article I'll explain how innotop can make it much easier to collect useful information from SHOW STATUS and SHOW VARIABLES into one place. There are three modes in innotop that do this in different ways, so one of them may meet your needs.

I've released another version of the innotop MySQL and InnoDB monitor. As always, you can download innotop from the original article.

It's worth upgrading to this version not only because of the new features, but also because it should handle more special cases without crashing. Of course, if it does crash, I appreciate your help fixing it; see this article about what information I need.