transaction - read-only transaction

No transactions : guarantees read consistency at the SQL statement level.
That is, during the execution of an SQL statement, it only sees the data state at the point before execution, and does not see the state of data changed by other SQL during execution.
Existing problems: For example, when you do a report query, when the first SQL is executed, the second query SQL is executed, and the data has been changed between them, and the second data query may be inconsistent.

Read-only transaction : Ensures read consistency
at the transaction level. Multiple SQLs executed within the scope of the transaction will only see the data state at the point before execution, and will not see any state changed by other SQL during the transaction.

Read-only transactions can solve the consistency problems caused by no transactions.

Example:
Create a table:

CREATE TABLE `t_pai` (
   `id` bigint(20) NOT NULL AUTO_INCREMENT,
   `name` varchar(10) NOT NULL,
   `update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
   PRIMARY KEY (`id`),
   KEY `idx_update_time` (`update_time`)
 ) ENGINE=InnoDB AUTO_INCREMENT=46 DEFAULT CHARSET=utf8

Client 1:

SET autocommit =1;

INSERT INTO t_pai(NAME,update_time) VALUES ("1",NOW());

SELECT SLEEP(10) FROM DUAL;

INSERT INTO t_pai(NAME,update_time) VALUES ("2",NOW());

SELECT SLEEP(5) FROM DUAL;

INSERT INTO t_pai(NAME,update_time) VALUES ("3",NOW());

SELECT SLEEP(2) FROM DUAL;
INSERT INTO t_pai(NAME,update_time) VALUES ("4",NOW());


SELECT SLEEP(2) FROM DUAL;

INSERT INTO t_pai(NAME,update_time) VALUES ("5",NOW());

SELECT SLEEP(2) FROM DUAL;

COMMIT;

Client 2:
First execute:

START TRANSACTION READ ONLY;
SELECT * FROM t_pai;

Repeatedly execute:

SELECT * FROM t_pai;

Output:
No data is queried.

Client 3:

SELECT * FROM t_pai;

Repeated execution, you can see that the data is inserted one by one, and the data consistency is destroyed

transaction - read-only transaction

Guess you like