In MySQL 5.1, all triggers are FOR EACH ROW - that is, the trigger is activated for each row that is inserted, updated, or deleted. MySQL 5.1 does not support triggers using FOR EACH STATEMENT.

No. However, MySQL has an AUTO_INCREMENT system, which in MySQL 5.1 can also handle inserts in a multi-master replication setup. With the --auto-increment-increment and --auto-increment-offset startup options, you can set each server to generate auto-increment values that don't conflict with other servers. The --auto-increment-increment value should be greater than the number of servers, and each server should have a unique offset.

No. This is on the MySQL roadmap as a "rolling feature". This means that it is not a flagship feature, but will be implemented, development time permitting. Specific customer demand may change this scheduling. However, MySQL does parse time strings with a fractional component. See Section 11.3.2, "The TIME Type". Yes. MySQL is fully multi-threaded, and will make use of multiple CPUs, provided that the operating system supports them.

Most 5.1 binaries have support for SSL connections between the client and server. We can't currently build with the new YaSSL library everywhere, as it's still quite new and does not compile on all platforms yet. See Section 5.9.7, "Using Secure Connections". You can also tunnel a connection via SSH, if (for instance) if the client application doesn't support SSL connections. For an example, see Section 5.9.7.5, "Connecting to MySQL Remotely from Windows with SSH".

No. Support for external authentication methods is on the MySQL roadmap as a "rolling feature", which means that we plan to implement it in the future, but we have not yet determined when this will be done. No. Support for roles is on the MySQL roadmap as a "rolling feature", which means that we plan to implement it in the future, but we have not yet determined when this will be done.

In MySQL 5.1, triggers can be created using the CREATE TRIGGER statement, and dropped using DROP TRIGGER. See Section 19.1, "CREATE TRIGGER Syntax", and Section 19.2, "DROP TRIGGER Syntax", for more about these statements. Information about triggers can be obtained by querying the INFORMATION_SCHEMA.TRIGGERS table. See Section 22.16, "The INFORMATION_SCHEMA TRIGGERS Table".

Yes. The Query Cache operates on the server level, caching complete result sets matched with the original query string. If an exactly identical query is made (which often happens, particularly in web applications), no parsing or execution is necessary; the result is sent directly from the cache. Various tuning options are available. See Section 5.14, "The MySQL Query Cache".

For detailed upgrade information, see Section 2.11, "Upgrading MySQL". We recommend that you do not skip a major version when upgrading, but rather complete the process in steps, upgrading from one major version to the next in each step. This may seem more complicated, but it will you save time and trouble - if you encounter problems during the upgrade, their origin will be easier to identify, either by you or - if you have a MySQL Network subscription - by MySQL support.

MySQL 5.0.15 was released for production use on 19 October 2005. We are now working on MySQL 5.1, which is currently in beta.

Yes. All current MySQL versions support transactions. The InnoDB storage engine offers full ACID transactions with row-level locking, multi-versioning, non-locking repeatable reads, and all four SQL standard isolation levels.

Falcon support is not available in the standard MySQL 5.1 release. Falcon is available only in a specially forked release of MySQL 5.1. Information is provided here for evaluation purposes only. There have also been significant improvements in existing storage engines, in particular for the NDB storage engine that forms the basis for MySQL Cluster.

Yes. MySQL 5.1 no longer supports the BDB storage engine. Any existing BDB tables should be converted to another storage engine before upgrading to MySQL 5.1.

Yes. For the syntax required to perform multi-table updates, see Section 13.2.10, "UPDATE Syntax"; for that required to perform multi-table deletes, see Section 13.2.1, "DELETE Syntax". A multi-table insert can be accomplished using a trigger whose FOR EACH ROW clause contains multiple INSERT statements within a BEGIN ... END block. See Section 19.3, "Using Triggers".

See Chapter 14, Storage Engines and Table Types. That chapter contains information about all MySQL storage engines except for the NDB storage engine used for MySQL Cluster; NDB is covered in Chapter 15, MySQL Cluster.

Stored procedures can, but stored functions cannot. If you perform an ordinary SELECT inside a stored procedure, the result set is returned directly to the client. You need to use the MySQL 4.1 (or above) client-server protocol for this to work. This means that - for instance - in PHP, you need to use the mysqli extension rather than the old mysql extension.

Yes, standard actions carried out in stored procedures and functions are replicated from a master MySQL server to a slave server. There are a few limitations that are described in detail in Section 18.4, "Binary Logging of Stored Routines and Triggers".

Yes. For the syntax required to perform multiple-table updates, see Section 11.2.10, "UPDATE Syntax"; for that required to perform multiple-table deletes, see Section 11.2.1, "DELETE Syntax". A multiple-table insert can be accomplished using a trigger whose FOR EACH ROW clause contains multiple INSERT statements within a BEGIN ... END block. See Section 19.3, "Using Triggers".