函数 USER()、CURRENT_USER()(或CURRENT_USER)、UUID()、VERSION() 和 LOAD_FILE() 在复制时不进行更改，因此除非启用基于行的复制，否则它们在副本上不可靠地工作。（见第 19.2.1 节，“复制格式”。）

USER() 和 CURRENT_USER() 在使用 MIXED 模式时自动使用基于行的复制，并在 STATEMENT 模式下生成警告。（见 also 第 19.5.1.8 节，“CURRENT_USER() 的复制”。）这也适用于 VERSION() 和 RAND()。

对于 NOW()，二进制日志包含时间戳。这意味着该函数在源服务器上的调用结果将被复制到副本上。为了避免在不同时区之间复制 MySQL 服务器时出现意外结果，请在源服务器和副本上设置时区。有关更多信息，请参阅 第 19.5.1.33 节，“复制和时区”。

为了解释在不同时区之间复制服务器时可能出现的问题，假设源服务器位于纽约，副本位于斯德哥尔摩，两台服务器都使用本地时间。假设在源服务器上创建一个表 mytable，然后在该表上执行 INSERT 语句，然后从表中选择，如下所示：

mysql> CREATE TABLE mytable (mycol TEXT);
Query OK, 0 rows affected (0.06 sec)

mysql> INSERT INTO mytable VALUES ( NOW() );
Query OK, 1 row affected (0.00 sec)

mysql> SELECT * FROM mytable;
+---------------------+
| mycol               |
+---------------------+
| 2009-09-01 12:00:00 |
+---------------------+
1 row in set (0.00 sec)

斯德哥尔摩的本地时间比纽约晚 6 小时；因此，如果您在副本上在同一瞬间执行 SELECT NOW()，则返回值为 2009-09-01 18:00:00。因此，如果您在副本的 mytable 副本上执行选择语句，可能期望 mycol 包含值 2009-09-01 18:00:00。然而，这不是情况；当您从副本的 mytable 副本上选择时，您将获得与源服务器相同的结果：

mysql> SELECT * FROM mytable;
+---------------------+
| mycol               |
+---------------------+
| 2009-09-01 12:00:00 |
+---------------------+
1 row in set (0.00 sec)

与 NOW() 不同，SYSDATE() 函数不是复制安全的，因为它不受二进制日志中的 SET TIMESTAMP 语句的影响，并且在使用基于语句的日志记录时是非确定性的。这不是问题，如果使用基于行的日志记录。

一种替代方法是使用 --sysdate-is-now 选项，使 SYSDATE() 成为 NOW() 的别名。这必须在源服务器和副本上都进行，以便正确工作。在这种情况下，该函数仍然会发出警告，但只要在源服务器和副本上都使用 --sysdate-is-now，就可以安全地忽略该警告。

SYSDATE() 在使用 MIXED 模式时自动使用基于行的复制，并在 STATEMENT 模式下生成警告。

另请参阅 第 19.5.1.33 节，“复制和时区”。

以下限制仅适用于基于语句的复制，不适用于基于行的复制。 GET_LOCK()、RELEASE_LOCK()、IS_FREE_LOCK() 和 IS_USED_LOCK() 函数处理用户级锁，复制时不知道源的并发上下文。因此，这些函数不应该用于插入源表，因为复制的内容将不同。例如，不要发出以下语句：INSERT INTO mytable VALUES(GET_LOCK(...))。

这些函数在使用 MIXED 模式时自动使用基于行的复制，并在 STATEMENT 模式下生成警告。