Has anyone ever told you that SELECT * FROM table is bad, and did they give you a reason?
Let me give you two;

1. 
   
2. If someone were to add column level privileges and then lock you out of a column, your query will start failing.
   
3. There are certain cases where MySQL can satisfy all of your query just by reading an index. This is much faster than reading the index, then the data.
   

An example:

CREATE TABLE index_test_no_data (
 id INT NOT NULL PRIMARY KEY auto_increment,
 a char(32),
 b char(255),
 c char(255),
 d char(255),
 e char(255),
 f char(255),
 g char(255),
 h char(255),
 i char(255),
 j char(255),
 k char(255),
 l char(255),
 m char(255),
 n char(255),
 o char(255),
 p char(255),
 q char(255),
 r char(255),
 s char(255),
 t char(255),
 u char(255),
 v char(255),
 w char(255),
 x char(255),
 y char(255),
 z char(255),
empty tinyint, …

You may have read Jo's blog entry Methods to reduce the load of your webserver by caching content: using lighttpd, MySQL UDF, LUA and speed everything up. He explained there how to use lighttpd and its mod_cml together with MySQL to provide a caching system directly at the webserver, and not at the PHP level.

Now, our good ol' friend Jan Kneschke, author of god's own webserver lighttpd (called "lighty"), mentioned in his blog ("mod_cml is dead, long live mod_cml!") that the name and functionality of mod_cml is subject to change. Why? mod_cml is not about caching only, it's about deciding how to handle a request.

"Any status code can …

A

This is one in a series of articles on how to use the innotop MySQL and InnoDB monitor. In this article I show how innotop can display locks that are causing a transaction to wait.

Pre-requisites

This tutorial is aimed at Linux installations that has the standard development tools already installed. The INSTALL file in the source archives provides good details of the software required (e.g. gunzip, gcc 2.95.2+,make).

Create a separate user for this development work.

su -
useradd mysqldev
su - mysqldev

Get an appropiate Snapshot

You can view recent snapshots at http://downloads.mysql.com/snapshots/mysql-5.1/.

The official statement on snapshots from MySQL AB.
Daily snapshot sources are only published, if they compiled successfully (using the BUILD/compile-pentium-debug-max script) and passed the test suite (using make test). If the source tree snapshot fails to compile or does not pass the test suite, the source tarball will not be published.

At the time of producing …

One of the tackiest things about SQL syntax is that stored procedures use the same delimiter for statements in stored procedures as in other statements, and that the syntax doesn't make it easy to distinguish the scope of the stored procedure. The “solution” (which I'd consider a poor workaround) is the DELIMITER keyword, which changes the character (sequence) that the client recognizes to represent the end-of-statement delimiter. From the manual, a typical stored procedure definition might be:

DELIMITER //

CREATE PROCEDURE simpleproc (OUT param1 INT)
  BEGIN
  SELECT COUNT(*) INTO param1 FROM t;
  END;
//
DELIMITER ;

The problem in BUG#11312 is that we try to replicate this stuff. But the DELIMITER kludge^Wcommand is a client-side thing which never makes it to the …

Just as Jay writes about an upcoming MySQL Barcamp, I’m all stoked to head to the 2006 inagural WordCamp. After that, I’ll be at Apple’s WWDC 2006.

There’s one thing there that interests me greatly is the My Agenda tool - you can pre-plan what you’re going for, have it printed or subscribed to in the webcal (iCal) format.

So, anyone want to catch up in San Francisco? I’ll be around from the 4th right till the 12th (though I leave later in the evening then). Drop me an email or just comment here…

In this article I’ll introduce deadlocks, analyze and explain a real example, and show how to cause and avoid deadlocks.

Depending on the ratio of READs/WRITEs in your database, removing indexes (not adding them!) will give you better performance. Indexes hurt on UPDATE and INSERT, but by how much and when?

CREATE TABLE index_test (id INT NOT NULL PRIMARY KEY auto_increment,
 a char(50), 
 b char(50)) ENGINE=MyISAM;

Insert some dummy rows:

insert into index_test (a,b) values (REPEAT('a', 50), REPEAT('b', 50));
insert into index_test (a,b) SELECT a,b FROM index_test;
insert into index_test (a,b) SELECT a,b FROM index_test;
insert into index_test (a,b) SELECT a,b FROM index_test;
insert into index_test (a,b) SELECT a,b FROM index_test;
insert into index_test (a,b) SELECT a,b FROM index_test;
insert into index_test (a,b) SELECT a,b FROM index_test;
insert into index_test (a,b) SELECT a,b FROM index_test;
insert into index_test (a,b) SELECT a,b FROM index_test;
insert into index_test (a,b) SELECT a,b FROM …

If you care about archiving best performance in your application using MySQL you should learn about prepared statements. These do not neccesary provide performance beneft but they may, they also have other benefits.

As a quick introduction - before MySQL 4.1 there were only textual statements and textual protocol for data transfer - query was sent as text and result returned back as text. For example number 123 would be sent as string "123". Such protocol had serious performance implication - queries had to be parsed fully each time, all return values had to be converted to the strings on server side and back on the client side, which is pretty expensive especially for certain data types. Furthermore BLOBs require escaping as not all characters could be used in textual protocol, which not only consumed time but also required extra memory consumption both on server and client.

So in MySQL 4.1 Prepared statement came. Do not mix these …