See Also .NET, GAC. asynchronous I/O atomic atomic DDL atomic instruction auto-increment auto-increment locking 6133  The convenience of an  auto-increment  primary key involves some tradeoff with concurrency. In the simplest case, if one transaction is inserting values into the table, any other transactions must wait to do their own Consecutive lock mode ( innodb_autoinc_lock_mode=1 ) is the default setting prior to MySQL 8.0.3. As of MySQL 8.0.3, interleaved lock mode ( innodb_autoinc_lock_mode=2 ) is the default, which reflects the change from statement-based to row-based replication as the default replication type. See Also auto-increment locking, innodb_autoinc_lock_mode, primary key, row-based replication, statement- based replication. Auto-increment columns can be problematic with statement-based replication, because replaying the statements on a replica might not produce the same set of column values as on the source, due to timing issues. When you have an auto-incrementing primary key, you can use statement-based replication only with the setting innodb_autoinc_lock_mode=1 . If you have  innodb_autoinc_lock_mode=2 , which allows higher concurrency for insert operations, use  row-based replication  rather than  statement-based replication . The setting  innodb_autoinc_lock_mode=0  should not be used except for compatibility purposes. It saves work for the developer, not to have to produce new unique values when inserting new rows. It provides useful information for the query optimizer, because the column is known to be not null and with unique values. The values from such a column can be used as lookup keys in various contexts, and because they are auto- generated there is no reason to ever change them; for this reason, primary key columns are often specified as auto-incrementing.  A property of a table column (specified by the  AUTO_INCREMENT  keyword) that automatically adds an ascending sequence of values in the column.  Special instructions provided by the CPU, to ensure that critical low-level operations cannot be interrupted.  An atomic  DDL  statement is one that combines the  data dictionary  updates,  storage engine  operations, and binary log  writes associated with a DDL operation into a single, atomic transaction. The transaction is either fully committed or rolled back, even if the server halts during the operation. Atomic DDL support was added in MySQL 8.0. For more information, see Section 13.1.1, “Atomic Data Definition Statement Support” . See Also binary log, data dictionary, DDL, storage engine.  In the SQL context,  transactions  are units of work that either succeed entirely (when  committed ) or have no effect at all (when  rolled back ). The indivisible ("atomic") property of transactions is the “A”  in the acronym  ACID . See Also ACID, commit, rollback, transaction.  A type of I/O operation that allows other processing to proceed before the I/O is completed. Also known as nonblocking I/O  and abbreviated as  AIO .  InnoDB  uses this type of I/O for certain operations that can run in parallel without affecting the reliability of the database, such as reading pages into the  buffer pool  that have not actually been requested, but might be needed soon. Historically,  InnoDB  used asynchronous I/O on Windows systems only. Starting with the InnoDB Plugin 1.1 and MySQL 5.5,  InnoDB  uses asynchronous I/O on Linux systems. This change introduces a dependency on libaio . Asynchronous I/O on Linux systems is configured using the  innodb_use_native_aio  option, which is enabled by default. On other Unix-like systems, InnoDB uses synchronous I/O only. See Also buffer pool, nonblocking I/O.