如何做大表分割

liyihongcug

如何做大表分割


记录很多的作水平分割  （具体？）
如果字段很多作垂直分割 （具体？ 这个用得很少）

liyihongcug

欢迎讨论一个问题：建立表分区与表分割之间的孰优孰劣？
编辑： 文章来源： 发布日期：2007-2-5 人气：1029
个人认为理论上使用表分割在性能上应该和建立表分区查不多，但是，表分割对于所有的数据库都适用，而表分区只能用于oracle这样的特定的数据库；表分区属于数据库物理设计，表分割属于逻辑设计。
所以，一般来说是不是应该使用表分割更好一些。
---------------------------------------------------------------

你说的表分割是指把一张大表分割成多个表吗?
表分区是ORACLE对于非常大的表进行优化的一种有效方法, 是非常有效的一种手段, 在很多情况下,比你说的表分割更有效,比如,有一个代码表,使用分区表把100万纪录分在10个分区中(ID 每从1到10万为一个分区),那样写查询语句的时候,只要给出查询条件中所需要的代码,ORACLE自动会定位到对应的分区进行查询,大大降低的查询时间. 而采用表分割,那必须先根据查询的代码指定所要查询的表,才能找到相应的纪录. 而且,如果有下面这样的语句,查询的条件是跨分区的:
SELECT * FROM MYTABLE WHERE ID BETWEEN 99000 AND 10111;
在分区表中是非常容易实现的,ORACLE会自动在两个分区中查询;而采用表分割的话是否必须写成两个查询语句在UNION ALL?

事实上,大型的数据库都有对大表的特殊处理方式(类似于分区表),如果太强调可移植性而放弃这些最重要的特性的话,那性能很可能受到很大的影响.
---------------------------------------------------------------

即便是oracle数据库，当数据量很大时，用分表比用表分区要快些，尤其是在表用到group by求和等操作。
---------------------------------------------------------------

我也认为表分区要好一些，也就是一般说来的分区表，对这些表操作起来有很多强大的功能，说他强大主要是体现在对与表中有海量数据的情况之下的，试问大家一个其中有1亿条记录的表你是否会经常的将其移植到其他数据库系统当中去呢？
表分区基于物理存储，还有就是基于分区的索引可以使用，很不错的，当然，这些都是在海量数据情况之下的比较，但是如果真要是数据量不大的情况下比较，我想要比较分区表和表分割就没什么意思了。
---------------------------------------------------------------

表分区的效果对硬件有所依赖，而且效果恐怕不如诸位想象中那么好。我做过一点测试，很失望。
而表分割的效率提升在很多时候（不是所有时候）是很明显的。
当然这都是在巨型表的前提下讨论，缩小表和索引的规模有利于提高效率，这正是分割表的特点。

liyihongcug

在数据仓库项目中，由于数据规模庞大，提高数据的查询效率是永恒的主题，常见的优化手段有:

1、 硬件优化:提高机器性能，增加硬件等;

2、 优化查询语句，将限定性强的where条件放前，用exists代替in操作等;

3、 优化索引，建立有效的索引并检查和修复缺少的统计信息等;

4、 数据库系统文件优化，将数据文件、索引文件、日志文件放置在不同的磁盘上，提高并行度等

除了以上方法外，还有一种很重要但易被大家忽略的方法:大表数据分割。当一个表的数据规模达到数亿条时，索引已基本发挥不了作用:建立索引要花费大量时间，查询时由于要扫描大的索引表也要花费大量时间。为了发挥索引的作用，可以将大表按照某个字段拆分为若干个小表。

例如，国内某大型保险公司，其有36家分公司，一年的保单明细表(f_policy)大概有2亿条记录,两年的数据超过4亿条，如果在f_policy上作一次查询，响应非常慢，可以考虑将f_policy按照机构拆分为36个同构的小表，在作整个保单明细表的查询时，可以使用union all操作合并数据，或者建立一个union all的视图，查询效率大大提高。并且，作这样的拆分非常有用，因为经常会有只查询某个分公司数据的需求。

liyihongcug

bcp in表数据时候如何分割大的数据表？

比如说我想用命令向数据库导入SP表，但是比较大，一次导入会产生大量的日志。

怎么分割呢？

另外可以不让这个操作产生日志吗？？

删除表上的索引了主键，
sp_dboption db_name,\"select into \",true

-->


有可能导致你建主键的时间过长哦！如果，表过大的话！

表是非常的大，有1G多，大概有一千多万条记录，上次导入的时候就是产生大量的日志把数据库设备都漫溢了；进都进不去，好容易弄好！！
sp_dboption我是设置了，索引对日志的产生有多大影响呢？？

必须删除主键和索引，否则会写log

还是加 -b参数算了，小事务提交。

如果主键和索引是必要的，是否能在导入数据前把它删除，等数据导入后在创建呢？？

这样可行吗？

-->
yeah,you are smart:mrgreen:

比较大的表可以分几次导入，如：
bcp aaa.dat in aaa -S -U -P -F1 -L1000
就是从第一条开始倒到第1000条，然后依次类推

还是要使用快速BCP，导完数据后，再建主键和索引，比有主键和索引时导入快多了，并且还可以使用并行。

分批bcp out，分批bcp in

加什么参数据能分批 BCP OUT ；BCP IN

前面的帖子不是说了吗，加-F -L参数。

>Create view viewname as select * from You-want-to-bcp-tablename where time>\'2004/1/1\'  
   and time<\'2004/5/1\'
>go

cmd>bcp DBname..viewname out viewname.bcp -Uusername -Ppassword -Sdbname -c
cmd>bcp DBname..viewname in viewname.bcp -F1 -L500000 -Uusername -Ppassword -Sdbname -c
>dump tran dbname with trun_only
>go
.............................
..............................................

我刚导完两个数据库，都是把大表的主建和INDEX还有关联的触发器删除，等数据BCP进去好再从新建，个人感觉还是比较快的！

This is the way to do it:
1. sp_dboption db_name,\'select into/bulkcopy\',true
2. sp_dboption db_name,\'trunc log on chkpt\',true
3. drop indexes,triggers on destination tables
   BCP won\'t fire triggers, but bcp program is optimized for tables without triggers.
4. bcp out data using either of the following methods,
    4.1 bcp out the whole data
    4.2 bcp ... out data1.txt ... -F1 -L10000000 ..... (use the last row number you want)
          bcp ....out data2.txx ... -F10000001 -L20000000..
5. bcp in data
    5.1 bcp in the whole data using -b option, say 5000, if you bcp version is higer than 12.0,otherwise
       5.1.1 use split -l linecount to split your file
       5.1.2 use FIFO pipe
   5.2 bcp ... in ...data1.txt ... -b 5000
         bcp ... in ...data2.txt ... -b 5000 ......
6. rebuild indexes, recreate triggers

I used bcp to move data from 12.5.2 to 12.0 (bcp 12.0 for solaris doesn\'t support files greater than 2G), there are 86 million records in one table, and 32 million records in another one, it took me 10 hours in total.

-->

正解，先删除主键及索引，导完后再建不会有日志且速度很快