有一张表 t_table,其有一个标识列 t_id,我设置t_id列的属性 [标识]=是 [标识种子]=1 [标识递增量]=1
用了几年后,发现该表t_id列已经增长到了538753,t_Table目前的总数居量是7万多。有个应用程序,每当插入一条数据成功后会根据用户选择运行下列其中一条语句:
select top 10 * from fei_Table order by fei_id desc
或者
select top 100 * from fei_Table order by fei_id desc原先很快的,插入一条数据成功后,马上就刷出最后输入的10条,但是现在发现有点慢了,
当操作员手工输入连续插入比较快时,必须停下来才能刷出上面语句的结果。原先表的总数据量达到10万以上都不会慢,现在清掉一些过期数据也没有什么效果。是否是这个自动增长的标识列导致表的索引性能下降?
请问有什么办法优化一下?
不行的话,就只能把表重建,然后再写程序把数据导回来,达到把sqlserver的自动标识列的值降下来。
用了几年后,发现该表t_id列已经增长到了538753,t_Table目前的总数居量是7万多。有个应用程序,每当插入一条数据成功后会根据用户选择运行下列其中一条语句:
select top 10 * from fei_Table order by fei_id desc
或者
select top 100 * from fei_Table order by fei_id desc原先很快的,插入一条数据成功后,马上就刷出最后输入的10条,但是现在发现有点慢了,
当操作员手工输入连续插入比较快时,必须停下来才能刷出上面语句的结果。原先表的总数据量达到10万以上都不会慢,现在清掉一些过期数据也没有什么效果。是否是这个自动增长的标识列导致表的索引性能下降?
请问有什么办法优化一下?
不行的话,就只能把表重建,然后再写程序把数据导回来,达到把sqlserver的自动标识列的值降下来。
t_id 就是 fei_id
重新建表导数据是容易,但说老实话,大批量改数据的事情最好还是别干。
select top 10 * from fei_Table order by fei_id desc
或者
select top 100 * from fei_Table order by fei_id desc
改为
declare @id bigint
select @id = @@identity
select * from fei_Table with(nolock) where fei_id > @id - 10 and @id <= @id
或
select * from fei_Table with(nolock) where fei_id > @id - 100 and @id <= @id 当然要判别一下是否符合业务要求