高手请进! 高频率,CRUD操作的问题.

Question

系统中有1个计算需求,用到了1个临时表,做中间过度表.
即运算开始时候,在过度表插入需要运算的数据,运算完毕后,清除所有数据.
这个中间表,我目前用的是真实的TABAL.====我的问题!======
1.这种中间过度表,@TABLE(表变量),#TABLE(临时表),TABLE(真实表)哪个好?
2.因中间表运算数据量很大,日志涨的很快,请问怎样避免?每天4G.
3.大量这种操作,给数据库带来其他什么危害么?

Answer 1

1.这种中间过度表,@TABLE(表变量),#TABLE(临时表),TABLE(真实表)哪个好?基于问题2 的数据量大条件，如果实际运行环境，建议使用真实表，如果可在外侧数据库处理，而且临时表增长没特别限制的话，可使用临时表。
2.因中间表运算数据量很大,日志涨的很快,请问怎样避免?每天4G.
3.大量这种操作,给数据库带来其他什么危害么?大量此操作，第一个造成的问题就是日志过大，（当然可以通过压缩，简单模式等方式减小），另外，如果使用临时表或表变量的话，可能造成缓存的压力。这个需要实测环境。 

Answer 2

1.这种中间过度表,@TABLE(表变量),#TABLE(临时表),TABLE(真实表)哪个好?
数据量如果大，建议时候后面两种，而后面两种的区别主要在一个是在tempdb，一个是在用户db，从性能上来说，实体表更好。但是要注意回收。注意表变量没有非聚集索引
2.因中间表运算数据量很大,日志涨的很快,请问怎样避免?每天4G.
日志快，可以加大日志备份的频率，切换大容量日志或者简单模式。
3.大量这种操作,给数据库带来其他什么危害么?
CRUD对存储过程可能造成频繁的重编译，因为基础表频繁改变，统计信息不准确。然后就是如果表特别是实体表，其信息存放到用户DB的系统表中，频繁更改不建的是一个好事。根据上面的原因，我建议使用局部临时表。

Answer 3

以上两位能说得都说完了，
我就补充一个，，数据库是拿来读取的，不是拿来运算的，若高频率
请先考虑是否能在APP端进行缓存，然后定时一起提交到数据库

Answer 4

1, 表变量，局部临时表都可以， 看具体情况。
实表，在某些情况下不得已使用。
2, 表变量操作是不记日志的， 另外，可以考滤建立一个库，用简单事务恢复模式，用实表代替临时表，会写相对较少的日志。
并且，使用完后，显式删除表， 在删除表前可以先truncate table.
3, 无所谓危害， 除非你不用， 但是你的工作也就完不成。个见。

Answer 5

如果临时表数据量很小，几笔或几十笔，用表变量
否则用临时表，至少对临时表产生的操作，不会记在数据库的LOG上对数据库来，有多少任务，就产生多少负荷不能说危害不危害
重点在于如何分派和有效率地完成任务。