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

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

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

为了解释在不同时区之间复制时可能出现的问题，假设源位于纽约，副本位于斯德哥尔摩，并且两台服务器都使用本地时间。进一步假设，在源上，您创建了一个名为 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。因此，如果您在复制了上面显示的 CREATE TABLE 和 INSERT 语句之后从副本的 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.34 节，“复制和时区”。

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

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