怎么重置mysql的自增列AUTO_INCREMENT初时值_Mysql

重置 MySQL 自增列 AUTO_INCREMENT 初时值
注意, 使用以下任意方法都会将现有数据删除.

方法一:
delete from tb1;
ALTER TABLE tbl AUTO_INCREMENT = 100;
(好处, 可以设置 AUTO_INCREMENT 为任意值开始)
提示:如果表列和数据很多, 速度会很慢, 如90多万条, 会在10分钟以上.

方法二:
truncate tb1;
(好处, 简单, AUTO_INCREMENT 值重新开始计数.)

怎么重置mysql的自增列

1. 支持设置自增列的值

ALTER TABLE table_name AUTO_INCREMENT = 1;
不过这种方式自能设置大于当前使用的值,不能设置小于等于当前已经使用的自增列的值。myisam如果设置小于等于,则自增列的值会自动设置为
当前最大值加1。innodb则不会改变。

2.通过TRUNCATE把自增列设置为0,从MySQL 5.0.13开始TRUNCATE就能重置自增列为0.myisam和innode都是如此。

TRUNCATE TABLE table_name;
3.drop和create重建表方式重置自增列为0

DROP TABLE table_name;
CREATE TABLE table_name { ... };

时间: 2025-01-23 23:24:49

怎么重置mysql的自增列AUTO_INCREMENT初时值_Mysql的相关文章

MySQL自增列插入0值的解决方案_Mysql

在将数据库从MSSQL迁移到MySQL的过程中,基于业务逻辑的要求,需要在MySQL的自增列插入0值.在MSSQL中是这样完成的: 复制代码 代码如下: string sql;sql = " set identity_insert dbo.AppUsers on " + " insert dbo.AppUsers (Id, IsLocked, IsMustChangeLocalPassword, IsAvailable, Name, Sequence, CreatedBy,

与MSSQL对比学习MYSQL的心得(一)--基本语法_Mysql

这一期主要是学习MYSQL的基本语法,陆续还会有续期的文章,敬请期待 语法的差异 我这里主要说语法的不同 1.默认约束 区别:mysql里面DEFAULT关键字后面是不用加括号的 复制代码 代码如下: --sqlserverCREATE TABLE emp(id INT DEFAULT(12))--mysqlCREATE TABLE emp(id INT DEFAULT 12) 2.设置自增列 区别很大,不过好像mysql的自增列不能设置步长的 MYSQL的自增列一定也要是主键列,不是主键列会报

深入探寻mysql自增列导致主键重复问题的原因_Mysql

废话少说,进入正题.      拿到问题后,首先查看现场,发现问题表的中记录的最大值比自增列的值要大,那么很明显,当有记录进行插入时,自增列产生的值就有可能与已有的记录主键冲突,导致出错.首先想办法解决问题,通过人工调大自增列的值,保证大于表内已有的主键即可,调整后,导数据正常.问题是解决了,接下来要搞清楚问题原因,什么操作导致了这种现象的发生呢?       这里有一种可能,即业务逻辑包含更新自增主键的代码,由于mysql的update动作不会同时更新自增列值,若更新主键值比自增列大,也会导致

SqlServer Mysql数据库修改自增列的值及相应问题的解决方案_MsSql

SQL Server 平台修改自增列值 由于之前处理过sql server数据库的迁移工作,尝试过其自增列值的变更,但是通过SQL 语句修改自增列值,是严格不允许的,直接报错(无法更新标识列 '自增列名称').sql server我测试是2008.2012和2014,都不允许变更自增列值,我相信SQL Server 2005+的环境均不允许变更字段列值. 如果非要在SQL Server 平台修改自增列值的,那就手动需要自增列属性,然后修改该列值,修改成功后再手动添加自增列属性.如果在生成环境修改

MySQL · 8.0.0新特性 · 持久化自增列值

Worklog: WL#6204 这是MySQL8.0修复的上古bug之一,在2003年由Percona的CEO(当时应该还没Percona吧)提出的bug#199,光看这bug号就扑面而来一股上古时代的沧桑气息. 问题的本质在于InnoDB初始化AUTO_INCREMENT的方式,在每次重启时,总是算出表上最大的自增值作为最大值,下一次分配从该值开始.这意味着如果在btree右侧叶节点大量删除记录,重启后,自增值可能被重用.这在很多场景下可能导致问题,包括但不限于:主备切换.历史数据迁移等场景

MySQL内核月报 2015.01-MySQL · 捉虫动态· InnoDB自增列重复值问题

问题重现 先从问题入手,重现下这个bug 这里我们关闭mysql,再启动mysql,然后再插入一条数据 我们看到插入了(2,2),而如果我没有重启,插入同样数据我们得到的应该是(4,2). 上面的测试反映了mysqld重启后,InnoDB存储引擎的表自增id可能出现重复利用的情况. 自增id重复利用在某些场景下会出现问题.依然用上面的例子,假设t1有个历史表t1_history用来存t1表的历史数据,那么mysqld重启前,ti_history中可能已经有了(2,2)这条数据,而重启后我们又插入

MySQL中GTID和自增列的数据测试(r12笔记第38天)

  昨天的一篇文章,今天有不少网友向我确认一些细节,我想最近正好在看GTID的东西,可以揉在一起来说说.    GTID这个概念看似简单,实际上还是有不少的门道. 我们来从架构的设计角度来看看存在哪些场景需要考虑GTID的变化.   一主两从的架构模式下GTID的变化   我们就以一主两从的架构为基准进行阐述.在这个架构模式下我们会用到MHA的方案.    如果这个时候Master节点宕机了,MHA就会开启检查机制. 这个时候Slave 1节点就会变为新的Master,Slave 2会从Slav

MySQL自增列主从不一致的测试(r12笔记第37天)

    MySQL里面有一个问题尤其值得注意,那就是自增列的重复值问题,之前也简单分析过一篇,但是在后续我想了下,还有很多地方需要解释,一个就是从库的自增列是如何维护的,是否重启从库,自增列会受到影响.    我们继续来测试一下.首先复现这个问题.    创建表t1,插入3行数据. use test; [test]> drop table if exists t1; Query OK, 0 rows affected, 1 warning (0.01 sec) > create table t

SqlServer Mysql数据库修改自增列的值及相应问题的解决方案

SQL Server 平台修改自增列值 由于之前处理过sql server数据库的迁移工作,尝试过其自增列值的变更,但是通过SQL 语句修改自增列值,是严格不允许的,直接报错(无法更新标识列 '自增列名称').sql server我测试是2008.2012和2014,都不允许变更自增列值,我相信SQL Server 2005+的环境均不允许变更字段列值. 如果非要在SQL Server 平台修改自增列值的,那就手动需要自增列属性,然后修改该列值,修改成功后再手动添加自增列属性.如果在生成环境修改