Syntax:
SYSDATE()

Returns the current date and time as a value in 'YYYY-MM-DD HH:MM:SS'
or YYYYMMDDHHMMSS.uuuuuu format, depending on whether the function is
used in a string or numeric context.

SYSDATE() returns the time at which it executes. This differs from the
behavior for NOW(), which returns a constant time that indicates the
time at which the statement began to execute. (Within a stored function
or trigger, NOW() returns the time at which the function or triggering
statement began to execute.)

MariaDB> SELECT NOW(), SLEEP(2), NOW();
+---------------------+----------+---------------------+
| NOW()               | SLEEP(2) | NOW()               |
+---------------------+----------+---------------------+
| 2006-04-12 13:47:36 |        0 | 2006-04-12 13:47:36 |
+---------------------+----------+---------------------+

MariaDB> SELECT SYSDATE(), SLEEP(2), SYSDATE();
+---------------------+----------+---------------------+
| SYSDATE()           | SLEEP(2) | SYSDATE()           |
+---------------------+----------+---------------------+
| 2006-04-12 13:47:44 |        0 | 2006-04-12 13:47:46 |
+---------------------+----------+---------------------+

In addition, the SET TIMESTAMP statement affects the value returned by
NOW() but not by SYSDATE(). This means that timestamp settings in the
binary log have no effect on invocations of SYSDATE().

Because SYSDATE() can return different values even within the same
statement, and is not affected by SET TIMESTAMP, it is nondeterministic
and therefore unsafe for replication if statement-based binary logging
is used. If that is a problem, you can use row-based logging.

Alternatively, you can use the --sysdate-is-now option to cause
SYSDATE() to be an alias for NOW(). This works if the option is used on
both the master and the slave.

The nondeterministic nature of SYSDATE() also means that indexes cannot
be used for evaluating expressions that refer to it.

URL: https://mariadb.com/kb/en/sysdate/

