请教一个关于主键自增长列的问题我们在创建表的时候一般习惯这样。CREATE TABLE tablename(tid INT PRIMARY
请教一个关于主键自增长列的问题
我们在创建表的时候一般习惯这样。
CREATE TABLE tablename
(
tid INT PRIMARY KEY IDENTITY(1,1)
)
但最近我看到一个项目里面是用另一种方式管理自增列的：
1.创建一个管理自增列的表
CREATE TABLE table2
(
tablename NVARCHAR(99),
currentval BIGINT
)
然后有个存储过程来更新这个管理表的数据.
请问这样做的目的是什么？有啥好处？跟传统的IDENTITY(1,1)有啥区别？
[解决办法]我觉得还是identity的方法更好，当然，前提是identity能满足需求的。
sql server提供的identity的性能肯定是更好。
而通过创建一个表，里面存储了表名这个表中的当前id值，当有多个表，而每个表有多个线程，都需要取currentval，可能会导致性能问题
[解决办法]identity 简单方便，而自己维护sequence也是可以的，事实上不少项目就采用后者。。
[解决办法]性能来说，自增列好，但是管理层面来说，第二种方法好点。
因为如果自增列表中的数据如果删除，就会出现数据空缺。
个人还是推荐自增列。
[解决办法]看你怎么管理了。
[解决办法]第二种方法是通过代码来维护数据库的自增性，因为同一时刻获取的最大id是同一个，所以并发下面可能比较好，单纯的Identity的自增方法满足不了高并发下的ID维护
[解决办法]这个确实有可能，在并发插入大量数据，可能会有热点块的问题，会有闩锁。这个可以考虑通过其他字段来建立聚集索引，这样可以避免热点块的问题。
但是第二个表，我觉得，在并发插入大量数据的时候，也会有性能问题，比如同时有1000个同时插入，应该也会有热点块问题，甚至阻塞问题
[解决办法]对于第二种方式，个人的感觉：
1、有可能是因为可移植性考虑吧，因为其他数据库不一定有自增长列。
2、我见过几个系统用这种方式管理的，并不是管理的自增长列，而是管理类似单号这样的列，因为这样的列不单是自动增长的，有可能是前面有字母，后几位才是自动增长的。
[解决办法]第2中方法有以下好处：
1、可以防止由于删除数据导致原有ID资源的浪费，为空掉很多ID
2、可以提高并发性，例如如果批量插入数据，那么可以在ID表中也采用批量插入的方式插入ID
3、ID类型的选择也多样化，不像自增长只能是整型
