对频繁insert,update的表设计上要如何考虑

zg_ljc

各位大侠
应用中一个当日明细表，记录当日的流水交易。
在日终时会drop后重建，在联机处理中会有大量的数据insert和update。
这个表在设计上要如何考虑，esql程序要如何设计。

zg_ljc

做Update Statistics时这个表里没有数据。日间时会有大量的数据insert进来。也有不少的数据要update。跟踪了一下，sql语句并没有用到索引，而是全表扫描。
类似这样的表，如何进行优化？？

zg_ljc

执行update statistics会优化。
各位在应用中应该是类似 当日明细的表吧。
大量交易发生在8：00到18：00之间，这之间定时地执行 "update statistics for 当日流水表"吗？
有谁有类似处理方案呢？

herl

具体应用具体分析，数据量、并发程度.....

chenau

原帖由 czw1413_cn 于 2008-7-14 13:38 发表
extend控制到大小合适就可以了

需要经常做update statistics

赞同！个人建议：

1）改锁模式为行锁。alter table XXXX lock mode (row)

2)extend值控制合理（考虑数据量）。

3）做update statistics

wenlq

跟踪了一下，sql语句并没有用到索引，而是全表扫描。
类似这样的表，如何进行优化？？

用能装一天最多的数据的extent size 建表。建合适的索引，优化你的SQL。

wwtoxfh

如果表在运行过程中存在大量的insert和update操作的话，那么需要注意以下几个方面：
1、表的锁级别一定要为行锁，千万不能采用默认的锁级别（页锁）

2、如果表的并发操作非常多且频繁的话，建议将此表创建为分段表

3、如果表的数据量非常大的话，那么在创建表是要注意extent大小的指定，千万不要使用默认值32K，这样的话，随着数据量的增大会引发操作性能问题。

4、注意索引的创建，避免无效索引的引入。

5、在运行过程中定期对表做统计更新，一般做中优就可以了。


另外你贴子中提到的，在对表做查询时，未使用到索引，不一定是索引问题，有可能是当时表中数据量不大且onconfig中配置项OPTCOMPIND值为2，数据库自动采用了最佳查询路径导致的，这是正常的。

happer_xc

sql语句如果不是按照索引写的，执行时就是全表检索。建议把表改为行锁，sql语句依照索引写，哪怕在检索的结果再做清理。
如果update的字段不是索引中的字段，且日常没有大量的delete的话，update statistics不做也可以。

sqlnet

原帖由 wwtoxfh 于 2008-7-24 11:15 发表
如果表在运行过程中存在大量的insert和update操作的话，那么需要注意以下几个方面：
1、表的锁级别一定要为行锁，千万不能采用默认的锁级别（页锁）

2、如果表的并发操作非常多且频繁的话，建议将此表创建为 ...

非常赞同你的观点