, (or ), USER(), , 和 函数被复制而没有变化，因此除非启用基于行的复制，否则不能在副本上可靠地工作。（请参阅 第 16.2.1 节，“复制格式”。） CURRENT_USER()CURRENT_USERUUID()VERSION()LOAD_FILE()

USER()并 在使用模式CURRENT_USER()时使用基于行的复制自动复制MIXED，并在模式中生成警告STATEMENT。（另见 第 16.4.1.8 节，“CURRENT_USER() 的复制”VERSION() 。）对于 和也是如此RAND()。

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

为了解释在不同时区的服务器之间进行复制时的潜在问题，假设源位于纽约，副本位于斯德哥尔摩，并且两台服务器都使用本地时间。进一步假设，在源上，您创建一个表 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则会返回该值。出于这个原因，如果您在刚刚显示 的and 语句被复制mytable之后 从副本的副本中进行选择 ，您可能希望包含值 。然而，这种情况并非如此; 当您从 的副本副本中进行选择时 ，您会获得与源上完全相同的结果： CREATE TABLEINSERTmycol2009-09-01 18:00:00mytable

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。

另见第 16.4.1.31 节，“复制和时区”。

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

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