MySQL/InnoDB处理AUTO_INCREMENT_1

http://dev.mysql.com/doc/refman/5.6/en/innodb-auto-increment-handling.html

AUTO_INCREMENT Handling in InnoDB

下面所使用的表

CREATE TABLE people  (
    person_id BIGINT NOT NULL AUTO_INCREMENT,
    first_name VARCHAR(20),
    last_name VARCHAR(20),
    PRIMARY KEY (person_id)
);

Traditional InnoDB Auto-Increment Locking

the initialization of auto-increment counter:

auto-increment counter的初始化据我的分析存在于三个节点:

  • 数据库服务器启动后表的第一次插入前
  • 通过show table status命令查询表的状态信息,如果auto-increment counter没有初始化,就要在show table status之前初始化。
  • 表新建后,要初始化auto-increment counter。

下面是mysql官方文档的描述:http://dev.mysql.com/doc/refman/5.6/en/innodb-auto-increment-traditional.html

If you specify an AUTO_INCREMENT column for an InnoDB table, the table handle in the InnoDB data dictionary contains ????a special counter called the auto-increment counter that is used in assigning new values for the column. This counter is stored only in main memory, not on disk.????

InnoDB uses the following algorithm to initialize the auto-increment counter for a table t that contains an AUTO_INCREMENT column named ai_col: After a server startup(在服务器启动后,counter的值由于存在内存中,会消失), for the first insert into a table t(对于第一次插入), InnoDB executes the equivalent(等价的,等效的) of this statement:

SELECT MAX(ai_col) FROM t FOR UPDATE;

InnoDB increments the value retrieved(取回,恢复) by the statement and assigns it to the column and to the auto-increment counter for the table. By default, the value is incremented by one(默认的这个值会增加one). This default can be overridden by the auto_increment_increment configuration setting.

If the table is empty, InnoDB uses the value 1. This default can be overridden by the auto_increment_offset configuration setting.

If a SHOW TABLE STATUS statement examines(调查) the table t before the auto-increment counter is initialized, InnoDB initializes but does not increment the value and stores it for use by later inserts. ?This initialization uses a normal exclusive-locking read on the table and the lock lasts to the end of the transaction.?

如下所示,通过truncate将一张表初始化,通过show table status可以看到Auto_increment为1,这只是存储到counter中以供下次插入使用的。。。这个初始化过程会加一个排它锁把表锁住,这个锁会一直持续到事务结束。。。。。

mysql> truncate people;
Query OK, 0 rows affected (0.54 sec)

mysql> show table status from local_database like ‘people‘\G
*************************** 1. row ***************************
           Name: people
         Engine: InnoDB
        Version: 10
     Row_format: Compact
           Rows: 0
 Avg_row_length: 0
    Data_length: 16384
Max_data_length: 0
   Index_length: 0
      Data_free: 0
 Auto_increment: 1
    Create_time: 2014-11-04 15:36:51
    Update_time: NULL
     Check_time: NULL
      Collation: latin1_swedish_ci
       Checksum: NULL
 Create_options:
        Comment:
1 row in set (0.00 sec)

mysql> select max(person_id) from people;
+----------------+
| max(person_id) |
+----------------+
|           NULL |
+----------------+
1 row in set (0.00 sec)

InnoDB follows the same procedure(相同的过程) for initializing the auto-increment counter for a freshly created table(初始化新建立的表的auto-increment counter).


accessing the auto-increment counter

最重要的一个概念:table-level AUTO-INC lock,作用就是当执行一个insert语句时,这个锁会把表锁住,知道这个insert语句执行完成,然后表解锁,而不是等到这个事务结束。

When accessing the auto-increment counter, InnoDB uses a special table-level AUTO-INC lock that it keeps to the end of the current SQL statement, not to the end of the transaction. The special lock release strategy was introduced to improve concurrency for inserts into a table containing an AUTO_INCREMENT column. Nevertheless(然而,尽管如此), two transactions cannot have the AUTO-INC lock on the same table simultaneously(同时,一起,一齐), which can have a performance(性能) impact(影响) if the AUTO-INC lock is held for a long time. That might be the case for a statement such as INSERT INTO t1 ... SELECT ... FROM t2 that inserts all rows from one table into another.

auto_increment_increment&&auto_increment_offset

auto_increment_increment:自增值的自增量

auto_increment_offset: 自增值的偏移量

设置了两个值之后,改服务器的自增字段值限定为:

auto_increment_offset + auto_increment_increment*N  的值,其中N>=0,但是上限还是要受定义字段的类型限制。

比如:

auto_increment_offset=1

auto_increment_increment=2

那么ID则是所有的奇数[1,3,5,7,.....]

如果:

auto_increment_offset=5

auto_increment_increment=10

那么ID则是所有的奇数[5,15,25,35,.....]

============END============

时间: 2024-10-04 02:56:42

MySQL/InnoDB处理AUTO_INCREMENT_1的相关文章

使用mysql innodb 使用5.7的json类型遇到的坑和解决办法

---------------------------------------------- #查询JSON的某个字段 select data -> '$.Host' from temp #创建虚拟列 ALTER TABLE temp ADD host varchar(128) GENERATED ALWAYS AS (json_extract(data,'$.Host')) VIRTUAL; #给虚拟列创建索引 ALTER TABLE temp ADD INDEX index_temp_hos

巧用MySQL InnoDB引擎锁机制解决死锁问题(转)

该文会通过一个实际例子中的死锁问题的解决过程,进一步解释innodb的行锁机制 最近,在项目开发过程中,碰到了数据库死锁问题,在解决问题的过程中,笔者对MySQL InnoDB引擎锁机制的理解逐步加深. 案例如下: 在使用Show innodb status检查引擎状态时,发现了死锁问题: *** (1) TRANSACTION: TRANSACTION 0 677833455, ACTIVE 0 sec, process no 11393, OS thread id 278546 starti

优化导入数据到MariaDB、Mysql(InnoDB)的速度

关键配置:关闭binlog 环境:8G的sql文件,300多个InnoDB数据表,(用MysqlWorkbench导出的数据,用HeidiSql导入,因为正式环境是mysql,可以用MysqlWorkbench,而MariaDB用不了导出,要用HeidiSql,直接用mysqldump.source命令也可以).导出耗时6分钟,导入耗时55分钟(有待提高,跟进中) 版本:MariaDB 10 1.注释"log-bin=mysql-bin"."binlog_format=mix

MYSQL INNODB PAGE一督

MYSQL INNODB PAGE一督 MYSQL INNODB PAGE一督,布布扣,bubuko.com

mysql innodb存储引擎的聚集索引

InnoDB聚集索引 MySQL有没有支持聚集索引,取决于采用哪种存储引擎. MySQL InnoDB一定会建立聚集索引,所谓聚集,指实际数据行和相关的键值保存在一块,这也决定了一个表只能有一个聚集索引,即MySQL不会一次把数据行保存在二个地方.InnoDB通常根据主键值(primary key)进行聚集,但是当一个表没有PK怎么办?InnoDB选取聚集索引参照列的顺序是: 1.如果声明了主键(primary key),则这个列会被做为聚集索引2.如果没有声明主键,则会用一个唯一且不为空的索引

MySQL InnoDB内存压力判断以及存在的疑问

本文出处:http://www.cnblogs.com/wy123/p/7259866.html(保留出处并非什么原创作品权利,本人拙作还远远达不到,仅仅是为了链接到原文,因为后续对可能存在的一些错误进行修正或补充,无他) 与其他数据一样,内存对数据库的性能有着至关重要的影响,MySQL InnoDB也一样通过内存来缓存数据,在访问数据的时候通过访问内存中缓存的数据来提高数据的访问效率.MySQL中通过show variables like 'Innodb_buffer_pool%'命令或者直接

浅谈mysql innodb缓存策略

浅谈mysql innodb缓存策略: The InnoDB Buffer Pool Innodb 持有一个存储区域叫做buffer pool是为了在内存中缓存数据和索引,知道innodb bufferpool怎么工作,和利用它读取频繁访问的数据,是mysql优化重要的方面. 理想状况下,把bufferpool的大小调整到足够大,留下足够的内存空间给其他该服务器上的进程(使其无缺页即可).bufferpool越大,innodb 月表现为内存型数据库,从硬盘上一次读取数据,之后并成了从内存中读取数

mysql innodb 性能优化

默认情况下,innodb的参数设置的非常小,在生产环境中远远不够用比如最重要的两个参数innodb_buffer_pool_size 默认是8Minnodb_flush_logs_at_trx_commit 默认设置的是1 也就是同步刷新log(可以这么理解) innodb_buffer_pool_size: 这是InnoDB最重要的设置,对InnoDB性能有决定性的影响.默认的设置只有8M,所以默认的数据库设置下面InnoDB性能很差.在只有 InnoDB存储引擎的数据库服务器上面,可以设置6

MySQL Innodb 架构学习

一.MySQL后台线程   1.Master Thread 核心后台线程,主要负责将缓冲池的数据异步刷新到磁盘.例如脏页的刷新,插入缓冲的合并,undo 页的回收等. 1)每秒一次的操作: 日志缓冲刷新到磁盘,即使该事务还没有提交.该操作总是会发生,这个就是为了再大的事务,提交时间都很短. 当IO压力很小时(1s内发生的IO次数小于5% innodb_io_capacity)合并5% innodb_io_capacity 的插入缓冲. 当脏页比例大于 innodb_max_dirty_pages