Here is what the programmers see.

mysql> select 1+1;
+-----+
| 1+1 |
+-----+
|   2 |
+-----+
1 row in set (0.00 sec)

mysql> select "1"+"1";
+---------+
| "1"+"1" |
+---------+
|       2 |
+---------+
1 row in set (0.00 sec)

Benchmark

What if we do a thousand simple loops?  How long does the looping itself take?

The BENCHMARK() function executes the expression expr repeatedly count times. It may be used to time how quickly MySQL processes the expression. The result value is always 0.

mysql> select benchmark(1000000000, 1);
+--------------------------+
| benchmark(1000000000, 1) |
+--------------------------+
|                        0 |
+--------------------------+
1 row in set (5.42 sec)

mysql> select benchmark(1000000000, "1" );
+-----------------------------+
| benchmark(1000000000, "1" ) |
+-----------------------------+
|                           0 |
+-----------------------------+
1 row in set (5.40 sec)

So maybe type doesn’t matter? About five seconds just to loop but the type didn’t change it.   What if we add 1+”1″?

mysql> select benchmark(1000000000, 1+1);
+----------------------------+
| benchmark(1000000000, 1+1) |
+----------------------------+
|                          0 |
+----------------------------+
1 row in set (12.65 sec)

mysql> select benchmark(1000000000, 1+"1");
+------------------------------+
| benchmark(1000000000, 1+"1") |
+------------------------------+
|                            0 |
+------------------------------+
1 row in set (35.58 sec)
mysql> select benchmark(1000000000, "1"+"1");
+--------------------------------+
| benchmark(1000000000, "1"+"1") |
+--------------------------------+
|                              0 |
+--------------------------------+
1 row in set (51.59 sec)
It looks like type does matter.  But does it always matter?
mysql> select benchmark(1000000000, sum(1+1));
+---------------------------------+
| benchmark(1000000000, sum(1+1)) |
+---------------------------------+
|                               0 |
+---------------------------------+
1 row in set (9.69 sec)

mysql> select benchmark(1000000000, sum("1"+"1"));
+-------------------------------------+
| benchmark(1000000000, sum("1"+"1")) |
+-------------------------------------+
|                                   0 |
+-------------------------------------+
1 row in set (9.94 sec)

mysql> select benchmark(1000000000, sum("1.23456789"+"1.23456789"));
+-------------------------------------------------------+
| benchmark(1000000000, sum("1.23456789"+"1.23456789")) |
+-------------------------------------------------------+
|                                                     0 |
+-------------------------------------------------------+
1 row in set (10.32 sec)
So, not all functions are the same.  But it looks like size might matter!
mysql> select benchmark(1000000000, 1.1+1.1);
+--------------------------------+
| benchmark(1000000000, 1.1+1.1) |
+--------------------------------+
|                              0 |
+--------------------------------+
1 row in set (34.90 sec)

mysql> select benchmark(1000000000, "1.1"+"1.1");
+------------------------------------+
| benchmark(1000000000, "1.1"+"1.1") |
+------------------------------------+
|                                  0 |
+------------------------------------+
1 row in set (1 min 15.32 sec)

mysql> select  benchmark(1000000000, "1.123456789"+"1.123456789");
+----------------------------------------------------+
| benchmark(1000000000, "1.123456789"+"1.123456789") |
+----------------------------------------------------+
|                                                  0 |
+----------------------------------------------------+
1 row in set (1 min 53.32 sec)
Sorry.  Looks like size does matter.

This doesn't seem logical.
mysql> select benchmark(1000000000, 1=1);
+----------------------------+
| benchmark(1000000000, 1=1) |
+----------------------------+
|                          0 |
+----------------------------+
1 row in set (12.75 sec)

mysql> select benchmark(1000000000, 1="1");
+------------------------------+
| benchmark(1000000000, 1="1") |
+------------------------------+
|                            0 |
+------------------------------+
1 row in set (40.78 sec)
mysql> select benchmark(1000000000, 1=true);
+-------------------------------+
| benchmark(1000000000, 1=true) |
+-------------------------------+
|                             0 |
+-------------------------------+
1 row in set (12.73 sec)

mysql> select benchmark(1000000000, 1="true");
+---------------------------------+
| benchmark(1000000000, 1="true") |
+---------------------------------+
|                               0 |
+---------------------------------+
1 row in set, 65535 warnings (3 min 5.72 sec)
mysql> select benchmark(1000000000, "true"="true");
+--------------------------------------+
| benchmark(1000000000, "true"="true") |
+--------------------------------------+
|                                    0 |
+--------------------------------------+
1 row in set (57.25 sec)
Maybe we should CAST our work?
mysql> select benchmark(1000000000, cast("1" as unsigned));
+----------------------------------------------+
| benchmark(1000000000, cast("1" as unsigned)) |
+----------------------------------------------+
|                                            0 |
+----------------------------------------------+
1 row in set (32.27 sec)

mysql> select benchmark(1000000000, cast("1" as unsigned) + cast("1" as unsigned));
+----------------------------------------------------------------------+
| benchmark(1000000000, cast("1" as unsigned) + cast("1" as unsigned)) |
+----------------------------------------------------------------------+
|                                                                    0 |
+----------------------------------------------------------------------+
1 row in set (1 min 7.24 sec)

Maybe not!
Conclusion:  Be careful with your data types.  If you are taking user input, do the type conversion ONCE in your program.  Don’t let MySQL do the type conversions for you.
query = “SELECT * FROM table where $INPUT = 1″;   could be doing your wrong.

References:

http://dev.mysql.com/doc/refman/5.0/en/information-functions.html#function_benchmark

http://dev.mysql.com/doc/refman/5.0/en/numeric-type-overview.html

http://dev.mysql.com/doc/refman/5.0/en/cast-functions.html

If you are building new applications make these changes now.  Developer expectations are hard to change.  My example below will break your application if  developers open a database connections and then spend ten minutes playing with their play doe before making a query.  If you have working applications make changes slowly.

Middleware provides database connections pooling. This allows database connections to be used by multiple applications. Any program that runs as a deamon or service can use database pooling using libdbi. Applications written in PHP or CGI code don’t pool DB connections. They open and closes the connection each time a user hit a page.

The Apache module mod_dbd can manages database connections. On non-threaded platforms, it provides a persistent connection. On threaded platform, it provides an altogether more scalable and efficient connection pool, as described in this article at ApacheTutor. Note that mod_dbd supersedes the modules presented in that article.

PHP provides mysql_pconnect. It first tries to find a (persistent) link that’s already open with the same host, username and password (NOT PORT). If one is found, an identifier for it will be returned instead of opening a new connection.  Second, the connection to the SQL server will not be closed when the execution of the script ends. Instead, the link will remain open for future use (mysql_close() will not close links established by mysql_pconnect()).

Back to MySQL.

Max Connections has a default of 100 (<= 5.1.14) to 151 (>= 5.1.15).  If you exceed this number you will receive a “Too many connections error”.  This is often the first setting people find they have to changed as their usage grows.

Max User Connections controls the maximum number of simultaneous connections allowed per MySQL user account. By default this is set to unlimited (zero).  The default is fine. Your system will not run out of connections or memory if you have set Max Connections correctly.  Except a bad applications can “steel” all the connections from all the others.  Hopefully you have assigned a different user for each application.  Set this to the maximum number of connections any given user (application) will make.

Wait timeout is the number of seconds the server waits for activity on a non-interactive connection before closing it. The default is eight hours. (28800 seconds)  This is a crazy amount of time.  How long would you stay on the phone if no one was speaking?  Fifteen seconds is a good place to start. If it gives you problems increase it by fifteen until your good. Applications that open a connections and then process their data for minutes before making a request will be effected by a short time setting.

Interactive timeout is the number of seconds the server waits for activity on an interactive connection before closing it. This is only used by applications using the  mysql_real_connect() function of the MySQL API. I set this to 600. My idea is to give more sophisticated users more grace.  (Think connection pools have to reconnect.)

Connect timeout is the number of seconds that the MySQL server waits for a connect packet before responding with Bad handshake. The default is ten seconds.  Five would be better.

Max connections errors is a strange setting. IO stops after this number of bad connections is made from a host. You can unblock blocked hosts with the FLUSH HOSTS statement.  The default for this is ten (10). On a “good” network this shouldn’t have to be changed.  Because “the dabase should never stop” most DBAs make this a very large number. If you have a over loaded network you should put your database on a network of its own.  Or, you can try increasing this value.

max_allowed_packet controls the size of your BLOBs.  If you are storing pictures in your database, you may need to set this.  The default is one megabyte (1M). The protocol limit for max_allowed_packet is 1GB.  Set it to the biggest BLOB you need to store. The value should be a multiple of 1024 bytes.

Here are my my.cnf settings for a server with over 200 PHP and Perl applications and peeking at 4,000 connections per second.

# Network management
port                    = 3306
max_connections         = 5000  # number of simultaneous client connections allowed
max_user_connections    = 200   # number of connections a user can make, 0 = Unlimited
wait_timeout            = 15    # seconds to waits for activity on non interactive connection
interactive_timeout     = 600   # seconds to waits for activity on interactive connection
connect_timeout         = 5     # on connect seconds to waits for a connect packet
max_connect_errors      = 1000000 # IO stops after this number of bad connections one good connect reset
max_allowed_packet      = 10M   # How big is your BLOB?

MySQL replication support for the Pacemaker cluster manager (the stuff that we explained in this webinar) has made it into the Linux-HA resource agents default branch. If you are interested in testing — and you should! — please read the extended announcement. Feedback is extremely welcome on the linux-ha-dev mailing list.

We are expecting to release this as part of resource-agents 1.0.4, in late May/early June.

mysql > set profiling=1;
mysql> SELECT * FROM country WHERE city like ‘okla’  order by name;
mysql> SHOW PROFILES;

You should now see a table with a single row, with the number 1 to the left of your query.

mysql> SHOW PROFILE FOR QUERY 1;

There is more and you can read about it at

You’ll see a table summarizing how long each stage of executing the query took:

+--------------------------------+----------+
| Status                         | Duration |
+--------------------------------+----------+
| starting                       | 0.000050 |
| checking query cache for query | 0.000102 |
| Opening tables                 | 0.018733 |
| System lock                    | 0.000010 |
| Table lock                     | 0.000006 |
| init                           | 0.007367 |
| optimizing                     | 0.000004 |
| statistics                     | 0.000006 |
| preparing                      | 0.000005 |
| executing                      | 0.000002 |
| Sorting result                 | 0.027435 |
| Sending data                   | 0.000023 |
| end                            | 0.000002 |
| query end                      | 0.000002 |
| freeing items                  | 0.000031 |
| logging slow query             | 0.000002 |
| cleaning up                    | 0.000001 |
+--------------------------------+----------+
16 rows in set (0.00 sec)

To turn profiling off

mysql> set profiling=0;

There is more and you can read about it at http://dev.mysql.com/tech-resources/articles/using-new-query-profiler.htm.

I have had a lot of people asking me about MySQL lately so I thought is was time to share something I learned.  Too much caching space in MySQL can be a bad thing.

You would thing the more you can stuff your entire database into memory the better off you would be and the faster your system would work.  That is not completely true. I have made mprovements by lowering table_cache variable on every version my MySQL 5. From what I have read this seems to be due to overhead managing file descriptors and caching tables.  Like most things there is a point of diminishing returns when dealing with cache tables.  At some point your hit rate is overtaken by the management threads.

This seems to work best.  The read_rnd should be four times the sort and join buffer and they are four times the read buffer.  Something like this;

sort_buffer_size = 16M
read_buffer_size = 4M
read_rnd_buffer_size = 64M
join_buffer_size = 16M

Send me feedback at Mark at Grennan.com