MySQL 5.6在运行查询或提交事务时，是否会设置插入/更新上的时间戳记值？

Question

I was just curious and I checked the documentation: https://dev.mysql.com/doc/refman/5.6/en/datetime.html

But it doesn't say specifically if the value of a timestamp is set in terms of when a query was ran or when the transaction it was a part of was committed:

CREATE TABLE some_schema.some_table (
    id int(11) UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
    some_field VARCHAR(50) DEFAULT NULL,
    last_changed_ts TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
);

START TRANSACTION;
INSERT INTO some_schema.some_table (some_field) VALUES ("Foo");
INSERT INTO some_schema.some_table (some_field) VALUES ("Bar");
COMMIT;

And while obviously this would be the same time because it would run so fast (and microseconds are stripped off from what i understand), imagine running 1 trillion or something inserts, would their last_changed_ts value be the same since they are all committed in one transaction, or would there be differences between them based on when the INSERT statement was ran?

-- actually, after writing this all, I realize it's trivial to just set up a simple python script that starts a transaction, inserts, sleeps, and inserts again and check myself. I already wrote this all out and couldn't find a quick answer when googling so i'm leaving it and maybe someone else wants to throw their interesting two-cents in but if not i'll post my findings of the simple test in the coming day.

Answer 1

The timestamp is the timestamp of when query execution began on each insert query. If you insert a large number of rows in a single insert statement, the timestamp will be the same for all rows, and will be the timestamp of when the query began executing.

Committing a transaction doesn't change the values, as should be obvious from the fact that the inserted rows can be read back before commit, and it would not make sense if their values subsequently changed because you committed the insert.