Why MySQL BEGIN Statement Shows 5‑Second exec_time: Binlog Timestamp Experiments

Problem

A binlog snapshot shows that a BEGIN event appears to take 5 seconds, raising the question of whether the database is stalled or the statistics are inaccurate.

Experiment

1. A test database is created.

2. The MySQL prompt is modified to display the current time.

3. Binlog format is switched to STATEMENT .

4. An experiment table is created.

5. A transaction containing a SLEEP(5) is executed.

6. The resulting binlog is decoded, revealing three groups of timestamps:

Yellow part: Each binlog event carries a timestamp that matches the start time of the statement (minor 1‑second offsets may appear due to manual typing).

Red part: exec_time reflects the actual execution duration of each statement; for BEGIN , the exec_time equals that of the first following statement because BEGIN is written to the binlog together with the first statement.

Each event also includes a SET TIMESTAMP which influences time‑based functions like NOW() .

7. A second experiment changes the session SET TIMESTAMP manually and repeats the transaction. The binlog now shows that:

The event timestamps follow the manually set value, no longer representing the real start time.

exec_time becomes inaccurate, no longer matching the true execution duration.

Conclusions

exec_time measures statement runtime but can be distorted by a manually set timestamp.

The binlog event timestamp records the statement’s start time, yet it loses its original meaning when SET TIMESTAMP is overridden.

Next Issue Preview

The upcoming article will discuss the other two timing metrics in MySQL slow logs: query_time and lock_time , explaining their meanings and differences.

Related Articles

MySQL Replication Heartbeat Issue

SIP Drift and Its Impact on Database Connections

Why Queries on information_schema.columns Are Slow