神奇的APL表

jarjar

最初由 beginner_bj 发布
[B]1、APL表的聚簇索引保证 数据的排列是按照索引的顺序来排列_
——APL表的聚簇索引只保证同一页上数据的排列是按照索引的顺序来排列，数据若分布在多个页上，是肯定不保证按顺序排列的。

APL表的组织就象一个链表，在表的多个页之间通过页链来连接，你所说的"数据若分布在多个页上，是肯定不保证按顺序排列的"，这个顺序是指什么顺序？如果是说物理磁盘的存储顺序，那肯定不是按顺序排列的(但是这个顺序和我们讨论的聚簇索引的顺序有关系吗？)，但是如果这个顺序是指聚簇索引的顺序，那肯定是按这个顺序排列的。

In clustered indexes on allpages-locked tables, leaf-level pages are also the
data pages, and all rows are kept in physical order by the keys.

Physical ordering means that:
• All entries on a data page are in index key order.
• By following the “next page” pointers on the data pages, Adaptive Server
reads the entire table in index key order.

[/COLOR]

2、DOL表上的聚簇索引不保证 数据的排列是按照索引的顺序来排列(不管是不是做了reorg)
——你可以看看reorg rebuild

reorg rebuild完成后的瞬间(在没有数据修改之前)，数据的确是按照索引顺序排列，这种状态在生产环境能保持多久？但是一旦有一条修改语句发生，DOL上的聚簇索引不保证数据的排列顺序是聚簇索引的顺序。 而APL表上的聚簇索引是严格保证这一顺序的，不管发生多少的数据修改(所以才会有也的分裂和合并，才会有insert/update/delete的效率问题)。

[/COLOR]

3、DOL表的查询IO次数为：1(index root page)+1(index Intermediate page)+1(index leaf page)+1000
——最后这个+1000，我不能肯定，不知道有没有方法可以监控到实际的IO次数？如果有办法，那就拿刚reorg过的DOL表测一下。


+1000这个数字，的确是在DOL表最混乱的极致下的数据，对于刚reorg之后的表，和APL之间的IO差距就在于index页面的几个IO，的确这个比较不太合适，我收回，在大多数情况下，不会有这么大的差异。
[/COLOR]
4、13楼
——还是reorg rebuild
请看我对reorg rebuild的描述[/COLOR]

5、dataonly-locked table are not necessarily maintained in exact order by the key.
——不必要（not necessarily）不表示不能
not necessarily在这里不是"不必要"的意思，而是"不一定"，这两者之间的差异大了。

[/COLOR]
另外，
只说APL表，SELECT语句用到聚簇索引和只用到非聚簇索引，其它条件类似，会不会差别真的很大？
还是APL表，举个极端的例子，如果页为2K，行长大于1024，即一个数据页只能放一行，IO次数的计算又会怎样？
上面只说了SELECT的情况，对于INSERT/DELETE等情况，APL表显然很有劣势。重申一下我的观点——SELECT时APL表优势不明显，INSERT/DELETE时APL表劣势很突出。（当然，SELECT时APL表优势明不明显，还需要用测试数据说话） [/B]

所以我的结论是：
1、APL表上的聚簇索引保证数据是按照该索引的顺序排列。为了保持这个顺序，所以在insert /update/delete的过程中有可能(这个和索引列的选择以及数据的组织相关)会造成额外的IO，这个IO也不是想象中的那么大。

2、由于APL表上的聚簇索引保证任何时候数据都是按照索引顺序排列，因此，APL表上的聚簇索引查询和其他的索引查询方式是不同的，在范围查询情况下，会有效率上的提升。

3、APL适用的场合：
    数据变动不大的表(大量的查询，insert/update/delete比较少)。
    大量的insert和select，update/delete少，这种情况下，可以有选择的创建聚簇索引，减少在insert情况下的页分裂。例如：创建聚簇索引的列只会增加，大量的明细表上都会有时间字段，在这种字段上创建聚簇索引，而插入的数据也是按照时间增加的，这样可以避免Insert带来的页的分裂情况。

4、APL不适合的场合：
    数据频繁变动的表，有大量并发的insert/delete/update。这会引起末页竞争和页的分裂及合并。

5、DOL适合的场合：
    APL不适合的场合也就是DOL适合的场合。

6、DOL的缺点：
    会带来锁数量的大量增加，会消耗更多的资源。
    需要定期的作reorg，而reorg会上排他的表级锁，需要停业务。

所以在不同的场合选择不同的锁模式以及索引，才是这场讨论的目的。

jarjar

第一次回个帖子写了这么多，累死我了。

1017of

一个数据页只放一行的APL表，实际上就是变相的DOL表了。
尽管在有clustered index的APL表中，相同键值的数据可能被页分裂到不同的数据页中去，但更多相同键值的数据会在相同页中。这一点，在DOL表的日常业务中是无法保证的。DOL表随着数据的累积，相同键值的数据可能离散度会更加大，在使用clustered index为条件进行范围查询时，一般APL表会比DOL表更少发生I/O动作。当然此处还没有考虑DOL表的行漂移等不利条件。
当然在插入或删除时，APL表需要整理数据，所以有可能在I/O方面有劣势；但DOL表定期也需要reorg来降低数据离散度，所以总的来说，很难说谁一定不好。
APL表主要是在封锁粒度上不如DOL表，所以在高并发的OLTP应用中，可能会性能不如人意，也许这就是DOL的诞生原因吧（这句是我猜的，嘿嘿）。但在查询方面，APL表会有点优势，当然也要看如何应用（个人看法，我也是来学习的，嘿嘿）

jarjar

一个数据页只放一行的APL表，实际上就是变相的DOL表了。

这个观点不赞同，就像你说的那样，DOL和APL的差别在于锁粒度的差异，而不是每页的纪录条数。

1017of

在这个机制下，封锁一页和封锁一行，对应用都是一样的。当然内部可能还是有差别的，这个我就不清楚了，嘿嘿，等待专家解答。

beginner_bj

如果SYBASE的reorg需要停业务，那的确是DOL表的一个劣势（DB2的reorg可以ONLINE做，上的是若干个行锁）。其它方面看不出DOL表的劣势，要么是APL表明显有劣势，要么是孰优孰劣不好说或差不多。

不知道还有什么数据库会有类似APL表的东西？

1017of

reorg好象会加表锁，DB2还不了解，不过我感觉仅从封锁效果上去判断不够全面，更需要从存储结构、整理效果、性能优化以及具体整理过程等方面去考虑，但很多内部信息，恐怕我们普通用户是得不到的，估计都被老美们封锁了，唉。
26楼传说是DB2的大牛啊，有机会求教一下，不许拒绝哦。嘿嘿。

beginner_bj

最初由 1017of 发布
[B]reorg好象会加表锁，DB2还不了解，不过我感觉仅从封锁效果上去判断不够全面，更需要从存储结构、整理效果、性能优化以及具体整理过程等方面去考虑，但很多内部信息，恐怕我们普通用户是得不到的，估计都被老美们封锁了，唉。
26楼传说是DB2的大牛啊，有机会求教一下，不许拒绝哦。嘿嘿。 [/B]

不敢当啊，我DB2最多就是中级水平。我发现DB2的高手基本都在ITPUB的DB2版出没。

jarjar

reorg rebuild会加表的排他锁，这个和要求停业务也没有什么区别了。

reorg的其他级别的操作要求没有这么严格。

bitiwyh

Sybase ASE: Performance benefits of DPL and DRL

http://www.sybasefan.com/smartsection-item.itemid-248.htm
-
看得稀里糊涂...

使用DOL会比较好的避免并发死锁,而代价最大的可能就是reorg?

目前应用(APL)在较大的并发下就是出现了insert/update的死锁.锁的竞争出现在数据页和索引页(同一个表).