关于大数据量索引性能问题请教各位专家

yellowlee

测试下hash分区，
另外一亿的数据量如果按主键访问，也没多大问题，看你什么业务了，数据增长情况，还要看你机器了。

[ 本帖最后由 yellowlee 于 2010-7-27 20:12 编辑 ]

lfy_flying

多谢各位的回复，针对这个问题，目前我正在做实验来验证。
实验环境：
1.windows xp、双核1.7Ghz、内存3G、硬盘空间足够
2.Oracle10g
3.库表创建脚本请参考附件
4.所有的表空间数据文件放在同一磁盘分区中

由于造数据量很大，很费时间，我会分步来公布我的实验结果：
第一阶段：（110万条数据）
   不分区：
      插入平均用时2毫秒
      数据占用空间152M
      索引占用空间35M
      主键查询平均耗时14毫秒（30线程），2毫秒（3线程）
   分100个区：
      插入平均用时3毫秒
   数据占用空间200M
   索引占用空间43.8M
   主键查询平均耗时20毫秒（30线程），3毫秒（3线程）

lfy_flying

非常感谢你的回答，你的回答很有帮助，有了定量的分析。不过我有点疑问，你提到过1亿条数据索引的blevel是3，100万条数据索引的blevel是1，不知道是你随便举得例子还是有计算依据？请不吝赐教！

lfy_flying

原帖由 anlinew 于 2010-7-27 10:53 发表
从性能上来看分区至少有以下好处
1、Yong Huang已经提到，可以避免竞争从而提高性能
2、partitionning table 并使用partitioned index，减少blevle，从而减少index unique scan的io次数
   比如不做分区1亿个电话号码字段index 的Blevle至少会是3，而如果将每分区控制到10万数据的话可以将每个分区index的blevle减少到1，从而减少2次IO，而对于整个查询来说基本上降低了1半的成本

构造数据做测试吧，用实际结果来说话

非常感谢你的回答，你的回答很有帮助，有了定量的分析。不过我有点疑问，你提到过1亿条数据索引的blevel是3，100万条数据索引的blevel是1，不知道是你随便举得例子还是有计算依据？请不吝赐教！

anlinew

参考：
http://www.orafaq.com/papers/btree_sizing.pdf
“Understanding Indexes” Mr Tim Gorman
http://www.evdbt.com/2004_paper_549.doc

sundog315

原帖由 lfy_flying 于 2010-7-26 10:11 发表
主要的查询方式就是 按照手机号码进行主键查询

最后测试的时候怎么又用ZONE_ID进行分区了？这样的话，没法分区修剪

lfy_flying

原帖由 sundog315 于 2010-7-30 14:31 发表


最后测试的时候怎么又用ZONE_ID进行分区了？这样的话，没法分区修剪

ZONE_ID是DESTMSISDN的后两位

lfy_flying

首先感谢大家的回复，终于搞明白了，主键检索的性能只跟索引的B树的深度(BLevel，可以从user_indexes表中检索到)有关系，主键检索的I/O次数是BLevel+1。
我做了一个测试，用手机号码进行索引，1000万的数据量Blevel才2。理论上 每个数据块中索引指针个数的BLevel次方 > 数据库中记录条数