如果可能的话，应该配置使用并行方式。这至少对执行非群聚性索引的哈斯（杂凑，即hashed）创建方法是必须的，但是如果可能的话，采用分区表和分区扫描将使系统得到更大的改进。
在选择进入和创建群聚性的索引之后，该任务将被设置检查点（checkpointed ）所以，如果有充分的硬件资源，通过允许在任何一个时间点上，检查点任务可以具有多于10个（系统缺省值）的异步I/O请求，利用dbcc进行调谐将能够带来有益的效果。(‘maxwritedes’, number)
进一步作为降低使用检查点成本的一种方法，在相关的高速缓冲池（cache pool）、大数据量的I/O操作中，采用对高淘汰程度进行标记的方法，并允许清洁程序（好象家庭主妇一样）保持特别活跃的状态，将为那些检查点需要从高速缓冲池中刷新较“脏”的页面的而增加的I/O操作次数，并因此花费了在检查点上的时间，都能够大大减少作出贡献。
如果预先进行了配置，则可以对并行的选择进入可以使用预先分配的盘区。所以，通过将sp_configure number of pre-allocated extents设置为16也将对系统性能有明显的积极的效果。
　　备注：在仅对数据加锁类型之间进行改变不需要对数据进行备份， 而且执行起来只需很短的一段时间。
[以上为摘自sybase公司站点上的资料]

据我个人使用经验，我觉得对于并行性较高的应用要充分考虑使用行级锁，这样对于提高并发性能至关重要！当然，事务都存在利弊两方面，使用行级锁，也会带来一些相应的弊端，比如使用的锁越多，占用的内存也越多，在使用行级锁的表上频繁的进行数据删除、插入操作久而久之会造成数据库碎片的大量生成，数据库性能会下降，这就需要定时进行reorg操作，但该操作比较耗时，且影响业务！

提问：(zxar )
几个疑问，盼指点
1。allpages-locks是不是就是表锁，我以前一直是这么理解的，但是现在有疑问的是，如果我的where从句里的条件是针对索引的，它是对所有满足条件的页加锁，还是不管条件，对