Questions tagged «auto-increment»

用于自动密钥创建的数字序列生成

2
MySql的LAST_INSERT_ID()函数是否保证正确?
当我对具有列INSERT的表进行单行处理时,AUTO_INCREMENT我想使用该LAST_INSERT_ID()函数返回AUTO_INCREMENT为该行存储的新的'ed值。 由于许多Microsoft SQL Server的开发者和管理员毫无疑问都知道在SQL Server(等效功能SCOPE_IDENTITY和@@IDENTITY)一直没有没有问题。 我知道MySQL文档状态: 生成的ID在每个连接的服务器中维护。这意味着函数返回给定客户端的AUTO_INCREMENT值是为该客户端影响AUTO_INCREMENT列的最新语句生成的第一个值。该值不会受到其他客户端的影响,即使它们生成AUTO_INCREMENT自己的值也是如此。此行为可确保每个客户端都可以检索自己的ID,而不必担心其他客户端的活动,也不需要锁或事务。 (资源) 甚至甚至说: 从多个客户端同时使用LAST_INSERT_ID()和AUTO_INCREMENT列是完全有效的。 (资源) 是否存在任何可能导致LAST_INSERT_ID()无法返回正确值的已知风险或情况? 我在CentOS 5.5 x64和Fedora 16 x64和InnoDB引擎上使用MySQL 5.5。

3
如何在phpMyAdmin中将mysql表自动递增重置为1?
我知道在MySQL的命令行中,我可以通过以下方式将表的自动增量字段重置为1: ALTER TABLE tablename AUTO_INCREMENT = 1 我很好奇是否有办法从phpMyAdmin中执行此操作。是像复选框一样重置自动增量的东西,还是类似这些东西的东西? 并不是说命令行方法有什么问题。我一直在思考的其中一项好奇心事...提前致谢!

8
避免使用较大ID值的原因
我们正在开发一个尚不为用户所用的Web应用程序。我的老板注意到,即使表中只有不到100条记录,新创建的记录的ID也超过10000。她认为Web界面出于某种原因会创建比实际记录多100倍的临时记录(并删除它们),并且这可能导致我们在发布后的几个月内超出范围。 我不认为她对身份证通货膨胀的原因是正确的(可以回答这个问题的同事正在休假,所以我们不确定),但是我们假设她是。她说,她不想使用bigint列,并且希望我们停止自动递增ID列,并编写选择第一个“未使用”整数并将其用作ID的服务器端代码。 我是计算机科学专业的研究生,几乎没有实践经验,担任初级开发人员。她在管理我们组织的所有数据库以及设计大多数数据库方面具有多年的经验。我认为她在这种情况下是不正确的,bigint ID不用担心,而且模仿DBMS功能的味道像是反模式。但是我不相信我的判断。 支持和反对每个立场的理由是什么?如果我们使用bigint会发生什么不好的事情,以及重新发明轮子自动递增功能的危险是什么?有没有比任何一个都更好的第三种解决方案?她为什么要避免身份证面值膨胀的原因是什么?我也有兴趣了解实用的原因-也许bigint ID在理论上起作用,但在实践中引起头痛? 该应用程序不应处理大量数据。我怀疑在未来几年内是否会达到10,000条实际记录。 如果有什么不同,我们正在使用Microsoft SQL Server。该应用程序用C#编写,并使用Linq进行SQL。 更新资料 谢谢,我发现现有的答案和评论很有趣。但恐怕您误解了我的问题,因此它们包含了我想知道的内容。 我并不真正担心ID高的真正原因。如果我们自己找不到它,我可以问一个不同的问题。我感兴趣的是了解这种情况下的决策过程。为此,请假定应用程序每天将写入1000条记录,然后删除其中的9999条。我几乎可以肯定不是这种情况,但这就是我老板在提出要求时所坚信的。因此,在这些假设的情况下,使用bigint或编写自己的将分配ID的代码(以重新使用已删除记录的ID以确保没有间隙的方式)的利弊是什么? 出于实际原因,我强烈怀疑这是因为我们曾经编写了从另一个数据库导入数据的代码,作为可以在以后进行一定程度迁移的概念证明。我认为我的同事实际上在导入过程中创建了数千条记录,后来又删除了它们。我必须确认是否确实如此,但如果确实如此,则甚至无需采取任何措施。

3
重设IDENTITY值
我有一个带有IDENTITY列的表。在开发时,我会不时删除这些行,然后再次添加它们。但是,当我再次添加IDENTITY值时,它们始终保持增加,并且不是从1开始。现在我的ID是从68-> 92,这使我的代码崩溃。 如何重置IDENTITY值?

1
修复表结构以避免出现“错误:重复的键值违反唯一约束”
我有这样创建的表: -- -- Table: #__content -- CREATE TABLE "jos_content" ( "id" serial NOT NULL, "asset_id" bigint DEFAULT 0 NOT NULL, ... "xreference" varchar(50) DEFAULT '' NOT NULL, PRIMARY KEY ("id") ); 稍后,插入一些指定ID的行: INSERT INTO "jos_content" VALUES (1,36,'About',...) 稍后,将插入一些没有id的记录,它们将失败并显示错误: Error: duplicate key value violates unique constraint。 显然,id被定义为一个序列: 每个失败的插入都会增加序列中的指针,直到它递增到不再存在的值并且查询成功为止。 SELECT nextval('jos_content_id_seq'::regclass) 表定义有什么问题?解决此问题的明智方法是什么?

4
向现有PK添加自动增量
我在另一个数据库中已经存在的数据库中创建了一个表。最初是用旧的DB数据填充的。该表的PK必须接收那些记录上已经存在的值,因此它不能是自动递增的。 现在,我需要新表将其PK作为自动增量。但是,在PK已经存在并且有数据之后,我该怎么办?


2
如何在INSERT中处理auto_increment键(SELECT * FROM…)
我table1和table2MySQL中。两者都有一个主auto_increment键id。 如果表模式匹配,并且INSERT INTO table1 (SELECT * FROM table2)对插入到其中的新行该table1怎么办?难道他们保留他们原来的id价值和产生冲突时,从行table1具有相同的id?auto_increment是否生成新值?它取决于存储引擎还是锁定?

1
在CREATE TABLE…AS SELECT中自动递增主键
我通过使用复杂的选择查询创建了表格CREATE TABLE ... AS SELECT...。如何在此查询中添加自动增量主键? 例如: create table `user_mv` select `user`.`firstname` as `firstname`, `user`.`lastname` as `lastname`, `user`.`lang` as `lang`, `user`.`name` as `user_name`, `group`.`name` as `group_name` from `user` inner join `user_groups` on (`user`.`user_id`=`user_groups`.`user_id`) left join `group` on (`group`.`group_id`=`user_groups`.`group_id`) where `user`.`lang`=`group`.`lang` 此查询创建一个包含表firstname,lastname,lang,username,group_name列。我希望它也具有id作为自动增量主键的列。 有什么办法可以通过更改此查询来做到这一点?我知道我可以通过在执行此查询后更改表来做到这一点,但是如果有任何直接在create table语句中执行此操作的方法,我想知道如何执行此操作。

4
标识栏重新设置种子:何时需要?
在大学的最后一课中(我是学生),讲师要求我们开发数据库(如果重要的话,请使用MySQL Server)和小型客户端应用程序,该应用程序会将数据库用作数据源。 要求之一是,身份列(每个表中的PK)必须是顺序的,因为这是一种好习惯(按照讲师的话)。也就是说,当删除表行时,必须在后续插入中重用它的PK。我对RDBMS,PK和标识列有一般的了解。据我了解,标识列只是让数据库在插入行时自动生成PK的一种方式。标识列值不得以任何方式与行属性相关(只要它不是自然键即可)。 这个要求(严格按照顺序标识列)对我来说是可疑的。我试图问讲师,如果身份不是顺序的(由于删除引起的空白),那又有什么问题,但是却得到了非常抽象的答案,例如“它对用户方便,对维护数据库的数据库管理员有用”。没有具体的例子。“方便用户”这一说法听起来很愚蠢,因为它在业务领域没有任何意义。 因此,我很好奇这些原因是否真实?我只想到一种情况,即需要重新分配标识列种子时–当标识空间用尽时。但是,当标识列类型选择不正确时,例如用“ simple” int代替,bigint或者uniqueidentifier表包含十亿行时,这将是更多的设计问题。假设身份列是聚集索引:身份列中的间隙会影响索引性能吗?也许还有其他现实原因导致我不知道的每次删除后重新自动标识列的种子? 提前致谢!

1
为什么自动增量跳跃的次数超过插入的行数?
auto_increment使用存储过程执行批量插入后,我在Bids表的bidID中记录的值中看到这种奇怪的行为,对此感到非常不安: INSERT INTO Bids (itemID, buyerID, bidPrice) SELECT itemID, rand_id(sellerID, user_last_id), FLOOR((1 + RAND())*askPrice) FROM Items WHERE closing BETWEEN NOW() AND NOW() + INTERVAL 1 WEEK ORDER BY RAND() LIMIT total_rows; 例如,如果开始时的auto_incrementbidID值为101,并且我插入了100行,则结束值将变为213,而不是201。但是,这些插入的行的bidID依次运行,最大为201。 检查以下内容后, SHOW VARIABLES LIKE 'auto_inc%'; +--------------------------+-------+ | Variable_name | Value | +--------------------------+-------+ | auto_increment_increment | 1 | | …


2
用主键创建一个“ INTO”表
也许对于这个社区来说,我的问题很容易,但是对我(一个简单的Java程序员)来说,这是一个大问题。 我有一个越来越多的数据的大数据库。因此,外部数据库管理员创建了一个作业,该作业在临时表中向我显示所需的数据。但是他创建的表没有主键,当我的java项目去读取该表时,出现错误。 我无法读取此表,因为主键不存在。 我可以在不更改此复杂过程结构的情况下在过程中插入创建自动增量主键的可能性吗? 这是存储过程代码的开头: USE [MYDB] GO SET ANSI_NULLS ON GO SET QUOTED_IDENTIFIER ON GO ALTER Procedure [dbo].[spSchedula_Scadenzario] as begin drop table MYDB.dbo.tmpTable select aa.* into MYDB.dbo.tmpTable from (...) 提前致谢

2
MySQL-如果删除了最后一行,则自动递增不会自动递增
我有一个表,其中包含一个自动递增的主键ID。如果我删除最后一行(最高ID,例如id = 6)并插入新行,则新ID从7开始。我必须更改哪个参数,使主键从6开始? CREATE TABLE animals ( id MEDIUMINT NOT NULL AUTO_INCREMENT, name CHAR(30) NOT NULL, PRIMARY KEY (id) ) ENGINE=MyISAM; INSERT INTO animals (name) VALUES ('dog'),('cat'),('penguin'), ('lax'),('whale'),('ostrich'); 结果: id名称 1狗 2猫 3企鹅 4松懈 5鲸鱼 6鸵鸟 DELETE FROM animals WHERE id = 6; INSERT INTO animals (name) VALUES ('x'); 结果: …

2
MySQL Auto_increment由2乘2
前几天,我安装了MySQL Workbench,访问了公司的数据库,并为自己创建了一个可使用的表。到目前为止,一切都很好。问题是,我注意到我的auto_increment由2递增2。例如: ID NAME 1 Paul 3 Jack 5 Louis 7 John ... 当我这样做时SHOW VARIABLES LIKE 'auto_inc%': 'auto_increment_increment', '2' 'auto_increment_offset', '1' 所以我尝试通过以下方式设置auto_increment_increment为1: SET @@auto_increment_increment=1 并再次验证后,SHOW VARIABLES LIKE 'auto_inc%'我确认结果“有效”: 'auto_increment_increment', '1' 'auto_increment_offset', '1' 但是我的ID 仍以2乘2递增。 第一次这样做,它运行良好,然后我关闭了MySQL Workbench,意识到再次打开它时,它又auto_increment_increment被设置为2。现在,我尝试再次执行此操作,但是它似乎不再起作用。 有人可以帮我吗? 谢谢你们。
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.