The utf8 spec says that a utf8 character can take up to 4 bytes, mySQL currently only supports up to 3 bytes. So, in essence if your application allowed 255 characters to be inserted into a field, when in utf8 land ie a utf8 column these 255 characters can take up to 765 bytes.

Here is a breakdown from
dev.mysql.com

• 
  
• Basic Latin letters, digits, and punctuation signs use one byte.
  
• Most European and Middle East script letters fit into a two-byte sequence: extended Latin letters (with tilde, macron, acute, grave and other accents), Cyrillic, Greek, Armenian, Hebrew, Arabic, Syriac, and others.
  
• Korean, Chinese, and Japanese ideographs use three-byte sequences.
  

While implementing the first test version of SQLbusRT, I faced a problem on how to communicate SQL requests and query results using ORTE as a medium.

Usually when doing an SQL request, a connection is set up between a client and an SQL server. The client sends its SQL request over this connection, and as an answer it receives the query results over the same channel. Unfortunately, in the bus architecture I have in mind things aren't that simple...

Remind the fact that SQLbusRT is built on top of a publish/subscribe model. Ideally speaking clients should be subscribers, and the database server should be a publisher. However, this introduces a problem for both instances:

• How does the publisher know what to publish?
• What should the subscriber subscribe to?

I already thought of a solution before I started implementing. This solution was even visible in my diagrams (see my …

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.