Replication Considerations CREATE PROCEDURE p (i INT) BEGIN DECLARE i INT DEFAULT 0; SELECT i FROM t; BEGIN DECLARE i INT DEFAULT 1; SELECT i FROM t; END; END; In such cases, the identifier is ambiguous and the following precedence rules apply: •A local variable takes precedence over a routine parameter or table column. •A routine parameter takes precedence over a table column. •A local variable in an inner block takes precedence over a local variable in an outer block. The behavior that variables take precedence over table columns is nonstandard. Replication Considerations Use of stored routines can cause replication problems. This issue is discussed further in Section 25.7, “Stored Program Binary Logging” . The  --replicate-wild-do-table= db_name.tbl_name  option applies to tables, views, and triggers. It does not apply to stored procedures and functions, or events. To filter statements operating on the latter objects, use one or more of the  --replicate-*-db  options. Debugging Considerations Unsupported Syntax from the SQL:2003 Standard There are no stored routine debugging facilities. The MySQL stored routine syntax is based on the SQL:2003 standard. The following items from that standard are not currently supported: • UNDO  handlers • FOR  loops Stored Routine Concurrency Considerations To prevent problems of interaction between sessions, when a client issues a statement, the server uses a snapshot of routines and triggers available for execution of the statement. That is, the server calculates a list of procedures, functions, and triggers that may be used during execution of the statement, loads them, and then proceeds to execute the statement. While the statement executes, it does not see changes to routines performed by other sessions. For maximum concurrency, stored functions should minimize their side-effects; in particular, updating a table within a stored function can reduce concurrent operations on that table. A stored function acquires table locks before executing, to avoid inconsistency in the binary log due to mismatch of the order in which statements execute and when they appear in the log. When statement-based binary logging is used, statements that invoke a function are recorded rather than the statements executed within the function. Consequently, stored functions that update the same underlying tables do not execute in parallel. In contrast, stored procedures do not acquire table-level locks. All statements executed within stored 4763