[Mysql8.0 new features study notes] - Chapter V InnoDB enhanced

Five, InnoDB enhance Overview

5.1, integrated data dictionary

5.2 atomic DDL operation

5.2.1, examples of the operation atoms

In the test operation MySQL5.7, it is seen from the figure, when we delete the two tables, although the error, but still deleted t1 table.

Tests on MySQL8.0; see drop statement being given, in view of the database table and finds t1 has not been removed; drop operation is atomic;

5.3, auto-increment persistence

5.3.1, reproduce by self-duplication in the MySQL5.7

Create a test table t, and add three test data;

and then we delete the data id 3, in which case the counter should be 4, which is the id of the next generation data be 4; and then we quit MySQL service, and then restart MySQL services;

re landing MySQL, insert a data again, you can find id of newly inserted data is 3; in other words MySQL5.7 when the service restarts when the value of the counter will be set to auto-increment fields in the current table the maximum value of +1;

the value of the primary key to modify the sensory data: (PS; at this time, if the c1 field after a value of the id to 5, for the case where if we insert operation, it will appear primary key violation the scenario has not happened in the actual project too)

5.3.2 In MySQL8.0 of handling auto-incremented

When the previous operation is repeated in MySQL8.0, after deleting the data id 3, after restart MySQL service, then the insertion operation, data generated id is 4;

update a value of c1 id = 5 data

found no longer MySQL5.7 as given in, but data generated id = 6;

fixes MySQL5.7 Bug for the increment primary key;

5.3.3、innodb_autoinc_lock_mode

The values MySQL5.7

MySQL8.0 the value

2 represents the cross mode, a continuous mode is represented, that is to say the lock is then cross MySQL8.0 generated.
When the statement-based replication can lead to auto-increment value is not continuous.

5.4 Deadlock checking control

5.4.1 deadlock examples demonstrate

5.4.1.1, in innodb_deadlock_detect default open mode

Create a table in MySQL8.0 in, and this data query i = 1 in the case of open transactions;

-- 会获取一个共享锁
select xxxx for share

Also opened a window in the second transaction; and delete data operations i = 1, can be seen, since the data id = 1 for the first window there is a shared lock, so there need to wait for the shared release the lock;

back to the first window delete data operation i = 1 is performed successfully;

switch to the second window, found deadlock;

5.4.1.2, in the closed mode by default innodb_deadlock_detect

Close inspection deadlock provided, in order to facilitate testing, the waiting time from the deadlock 50 seconds to 5 seconds;

continue on an experiment, we can see the emergence of a rollback lock wait timeout and the second window;

the first after the delete operation performed because the window did not wait to lock timeout, lock wait timeout second window is rolled back, where the delete operation be carried out smoothly.

5.5, option to lock statement

5.5.1 Examples of presentation

Open a transaction, and a data update, it will not submit;

5.5.1.1, nowait examples demonstrate

Open a transaction in another window, using nowait, return an error message immediately after execution;

5.5.1.2, skip locked examples demonstrate

As shown below, added after the implementation of the statement will skip skip plus lock data; for example 2 to this data in the booking system has been locked, other customers at the time of the query is not being queried.

5.5.2, Notes

Both are for row-level locking. Due to bring these two parameters uncertainties, we are doing time data replication. May be different from the primary database nodes running environment, it will cause the backup may be skipped rows. Causes the main data from the database inconsistent.

5.6, other improvements