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

使用 MIXED 模式时，USER() 和 CURRENT_USER() 会自动使用基于行的复制进行复制，并在 STATEMENT 模式下生成警告。（另请参见 第 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。出于这个原因，如果您在刚刚显示的 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同时用于源和副本，就可以安全地忽略它。

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

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

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

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