检查了几遍还是忘了，每张表是 20 张，所以一共 20*5

@kiddult 确实是批量插入，不过在 jdbc 端有这样的方式，至少可以在数据流中不用把数据落地就能快速的入库，另外一个关键点就在于不用拼 insert 语句，对方不管什么数据库，只要按照约定格式把数据给过来基本上不存在性能的瓶颈。我们现在实时数据接入、计算都采取的这种方式。这功能也不算新，再配上 spark+kafka 简直不要太好用

数据大小 34G
索引大小 11G
表一共 100 张，每张表上面一个索引，都是建在数字上的
数据样例：
表 A
表
CREATE TABLE A (
storegid integer,
gid integer,
code character varying(20),
name character varying(80),
spec character varying(40),
sort character varying(255),
munit character varying(255),
rtlprc numeric(24,4),
inprc numeric(24,4),
mbrprc numeric(24,4),
isdisp integer,
alword integer,
alwsord integer,
prctype integer,
promote integer,
lwtrtlprc numeric(24,4),
gft integer,
mcode character varying(20),
dep character varying(64),
shortname character varying(40),
catalog character varying(1),
alcprc numeric(24,4),
brand character varying(20),
description character varying(255),
alwout integer,
costtype integer,
extendedattributes character varying(255),
validperiod integer,
code2 character varying(32),
brandname character varying(64),
origin character varying(40),
vdrcode character varying(100),
sortname character varying(255),
impprc numeric(24,4),
bgnwarnday integer,
endwarnday integer,
busgatename character varying(255),
permilgoal numeric(24,4),
ordflag character varying(4),
isbind integer,
indeadvalidday integer,
outdeadvalidday integer,
validdayunit character varying(4),
dayalc integer,
orddatelst character varying(20),
acode character varying(20),
bcode character varying(20),
ccode character varying(20),
dcode character varying(20),
usevalidate integer,
storenature character varying(20),
invprc numeric(24,4),
isgft integer,
originalcreator character varying(20),
validperioddes character varying(100),
alwmodprc integer,
stdrtlprc numeric(24,4),
stdmbrprc numeric(24,4),
highrtlprc numeric(24,4),
alwxf integer,
alwmod integer,
specreturnmemo character varying(255),
alwinputckqty integer,
cntinprc numeric(24,4),
vdrname character varying(100),
validdaycalc integer,
unsaleproperty integer,
strcol1 character varying(80),
strcol2 character varying(80),
strcol3 character varying(80),
strcol4 character varying(80),
strcol5 character varying(80),
strcol6 character varying(80),
numcol1 numeric(20,4),
numcol2 numeric(20,4),
numcol3 numeric(20,4),
numcol4 numeric(20,4)
);

索引 btree (storegid, gid)

1000021 | 3000035 | 06020125 | 泰优美牛肚 30g | 30g | 0802 | 包 | 5.0000 | 0.0000 | 5.0000 | 0 | 1 | 1 | 0 | -1 | 0.0000 | 0 |
| - | | A | 4.0000 | 1076 | | 1 | 0 | | | 6923405100516 | 泰优美 | | 800
328 | 牛肉类 | 5.0000 | 0 | 0 | - | | 00 | 0 | 0 | 0 | | |
| 08 | 0802 | 0802 | 0802 | | 默认 | 0.0000 | | | | 0 | 5.0000 | 5.0000 | 9999.0
000 | 1 | 1 | | | 3.3000 | | | | | | | | |
| | | |

表 B
CREATE TABLE B
storegid integer,
gdgid integer,
highinv numeric(24,4),
lowinv numeric(24,4),
stdshow numeric(24,2),
alc character varying(10),
busgate integer,
busgatename character varying(255),
abctype character varying(20)
);
索引
btree (storegid, gdgid);
数据
1000025 | 3004329 | 9999.0000 | 0.0000 | 0.00 | 直送 | 7000020 | 正常 |

表 C
CREATE TABLE C (
storegid integer,
gid integer,
qpc numeric(24,4),
rtlprc numeric(24,4),
mbrprc numeric(24,4),
lwtrtlprc numeric(24,4),
impprc numeric(24,4)
);
索引：btree (storegid, gid, qpc)
数据： 1000036 | 3001832 | 1.0000 | 5.0000 | 4.5000 | 0.0000 | 5.0000

表 D
CREATE TABLE D (
storegid integer,
gid integer,
qpcstr character varying(20),
qpc numeric(24,4),
isdu integer,
ispu integer,
iswu integer,
isru integer
);
索引：btree (storegid, gid)
1000033 | 3053299 | 1*1 | 1.0000 | 2 | 2 | 2 | 2


表 E
表：CREATE TABLE E (
storegid integer,
code character varying(20),
codetype integer,
gid integer,
rtlprc numeric(24,4),
qpc numeric(24,4),
munit character varying(6),
mbrprc numeric(24,4),
lwtrtlprc numeric(24,4),
score integer,
catalog character varying(6),
impprc numeric(24,4)
);

索引：btree (storegid, gid)
数据： 1000033 | 6917246013081 | 0 | 3003501 | 23.9000 | 1.0000 | 支 | 23.9000 | 0.0000 | 0 | A | 23.9000


很期待那几位经验丰富的大神能给出好的方案。

@yangqi 又说场景简单了，那么在这个简单场景下，您经验丰富，有这个经验，能给个方案吗，几亿条数据 7 分钟从 oralce 导进 8 核 16g 顺序 io100MB/s 左右的机器上的 mysql。

打嘴炮没意思，能用数据或者事实说话吗？

另外一个我哪一个字说自己是专家，这数据也不是我测的。

@kiddult 我全程没说开发者的智商吧，至于方式，能给个方案吗，几亿条数据 7 分钟从 oralce 导进 8 核 16g 顺序 io100MB/s 左右的机器上的 mysql

@azh7138m navcat 是现在在生产上跑的。

然后这次测试他们有分别用过 kettle/和手写 java 程序 先导数据，再建索引；索引存在的时候导数据。测下来 10000 条 /30s 左右就没测了。数据落地的方案肯定要快些，但是流程控制比较长，他们也没人专门维护这个，所以不愿意选择

@sagaxu 他们数据源在 oracle 里面，不好用 mysqldump 吧

实际业务场景就是 oracle 与文物库里面的数据，每天算好报表以后同步到 mysql。大概几十张表，100 个索引，数据量 40 多 G。

@kindjeff 这种导出到文件的，每个数据库都快。

我们同事是数据在 oracle 里面，不在文件里面。如果导文件每天要倒一次还要比较记录条数，控制数据格式，重建索引，如果把这个做成一套逻辑的话就比较麻烦了

@azh7138m load file 当然快啊，但是 load file 要先把数据从 oracle 里面写出来落地吧，再 load 到 mysql。不知道您这个数据多少索引，他们是几十张表，一共上面有 100 个索引

@sunchen 我们自己用的是 pg+hawq+spark+kafka，也好使

@azh7138m 后来直接用 java 写了代码开了 10 个线程写，也就 30000 条一分钟

@yangqi 你内行，几亿条数据你 7 分钟从 oralce 搞进 8 核 16g io100 左右的机器上的 mysql 我就服你，有本事别只会打嘴炮啊

@est 列存我知道好，不过 pg 优化器没有专门为列存做优化，我看一些评测下面 pg 下列存的效果不明显。

@crazyneo 谁告诉你 olap 就必须用列存的。再说列存也不是 pg 原生支持的，pg 的优化器并没有为列存专门做优化，列存相比原生的堆处理能有多大优势。你自己脑补的够多的。

话说 pg 好用我还不能抬 pg 了？什么时候自己的嘴要账在别人身上。至于为什么说 copyin，只是恰好别人跑压测测到这个环节而已。批量导入确实谁都有，在你眼里 copyin 就是命令行的 copy 命令，那是你没玩好，copyin 在实时数据导入，流处理方面好处多了去。

德哥为 pg 做的贡献搞 pg 的谁不知道。

@crazyneo 你哪里看到我用了列存？还是你自己脑补的，“估计你光看结果都不知道我说了什么吧”

你列的那些需要吹吗，用过的人自然懂，没用过的你和他说他也不知道。基本的 copyin 你看有几个人知道

又问了下，pg 的 4 多秒的时候是带索引的写入，一共有 100 个索引。

@stabc 是不是最优配置我就不清楚了，那个环境我也没登上去过。pg 的配置也只是从开发环境拷过去的一个配置，当时应该是按照 8 核 16GB 来配的。

他们这个场景应该是个 olap 的场景，在这方面，pg 的优化器更先进，数据吞吐量更大，查询可以并行执行的特点其实更适合他们

@picone 有试过，之前建议他们关闭索引，有改善但不明显。

都有索引(他们索引比较多，貌似 60 还是 100 来个)的情况下，mysql 写入一分钟只有 3 万行 /s，pg 是 387 万行 /s

@picone 看下面回复，刚才特意问了，不是默认配置。用作生产的不可能是默认配置

@stabc 除了并行基本上都是对的，mysql，pg 应该最后都是 10 个并行。