博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
大表之困惑 - 数据建模的前期规划十分重要
阅读量:6497 次
发布时间:2019-06-24

本文共 1436 字,大约阅读时间需要 4 分钟。

  hot3.png

这几天被一个数据库中的大表所困扰,这是一个插入非常频繁的数据表,该表目前大约有20亿记录,是一个分区表:

SQL> SELECT TABLE_NAME,NUM_ROWS,BLOCKS,AVG_SPACE,SAMPLE_SIZE,LAST_ANALYZED  2  FROM DBA_TABLES WHERE OWNER='SMS' AND TABLE_NAME='SSMG';TABLE_NAME                       NUM_ROWS     BLOCKS  AVG_SPACE SAMPLE_SIZE LAST_ANALYZE------------------------------ ---------- ---------- ---------- ----------- ------------SSMG                           2000426788   60053382          0   101416650 12-SEP-09

然而这个表上建有的都是全局索引,现在需要按照跟索引基本无关的条件进行删除,以下几个索引都无可利用:

SQL> select  2      INDEX_NAME,BLEVEL,LEAF_BLOCKS,DISTINCT_KEYS,  3      NUM_ROWS,CLUSTERING_FACTOR,last_analyzed  4  from  5      dba_indexes t  6  where  7      table_name = 'SSMG'  8  and table_owner = 'SMS'  9  /INDEX_NAME                   BLEVEL LEAF_BLOCKS DISTINCT_KEYS   NUM_ROWS CLUSTERING_FACTOR LAST_ANALYZE------------------------ ---------- ----------- ------------- ---------- ----------------- ------------IDX_SMS_DEST_MDN                3    12186077      19507227 2071388105        1816174507 12-SEP-09IDX_SMS_SERVICE_ID              3     8184696            48 1990938187         113031962 12-SEP-09UN_SMS                          4    21717598    1973096899 1973096899         138625843 12-SEP-09

客户写了个Loop循环,通过另外一个表的关联去判断删除,另外一个表具有400万记录,初步计算了一下程序效率,跑完一次大约要200天。

好了,现在的问题是,要么面对不可能,要么建个索引,加快处理,可是在20亿上建一个索引,即便是Online的方式,对应用的性能也会有几大的影响。
要么很复杂的去处理,要么很慢的去处理,当初如果多加个索引,该有多好啊!

转载于:https://my.oschina.net/90888/blog/830784

你可能感兴趣的文章
concurrent包的实现示意图
查看>>
golang os.Args
查看>>
Linux常用命令
查看>>
【重磅】云栖社区2017年度内容特辑
查看>>
Java WEB开发时struts标签 显示set内容
查看>>
spring-data-elasticsearch 概述及入门(二)
查看>>
Solr启动和结束命令
查看>>
1.12 xshell密钥认证
查看>>
3.2 用户组管理
查看>>
awk
查看>>
AliOS Things SMP系统及其在esp32上实现示例
查看>>
VMware虚拟机出现“需要整合虚拟机磁盘”的解决方法
查看>>
ibatis 动态查询
查看>>
汇编语言之实验一
查看>>
09、Modules - Directory根据目录加载模块文件
查看>>
观影识人生
查看>>
The Little Prince-12/12
查看>>
git 调用 Beyond Compare
查看>>
ECMAScript 5 —— Function 类型 (一)
查看>>
SQL基础-->层次化查询(START BY ... CONNECT BY PRIOR)[转]
查看>>