多线程BulkCopy批量添加数据到不同表

2016-05-18 09:35:33 562 阅读 AI 写同款 · GEO 优化AI 选题数据监测一键分发 ›

多线程的SqlBulkCopy批量导入、事务和SqlBulkCopy使用的数据集中自定义映射字段的注意事项 class Program { static volatile bool result; static void Main(string[] args) { DataSet ds = ExportDataSet(); //使用2个线程模拟并发操作 Threa 阅读详情

各位好
我开两个线程一次持续往同一个数据库表1表2中导入20000条数据大约500MS表1和2都能导入成功一次
现在我开10个线程往表1/表2......表10中各导入两万条数据发现耗时为500MS到5000MS之间
求优化的方法
我用的是sqlserver数据库

...全文

AI算力瓶颈与系统优化实战指南 AI算力瓶颈已成为制约人工智能发展的关键因素，特别是在处理transformer类模型时，传统的冯·诺依曼架构面临严重的'内存墙'问题。通过硬件加速、系统优化和算法改进的三级策略，可以有效提升资源利用率。在嵌入式AI领域，结合量化、剪枝和专用指令集扩展等技术，能在资源受限设备上实现高效推理。这些优化方法在自动驾驶、工业视觉等场景中已展现出显著价值，推动AI应用从云端向边缘迁移。随着AI算力需求的持续增长，掌握系统优化技能将成为开发者的核心竞争力。阅读详情

six-years

疑难问题 22,298 成员 121,727 内容

+ 关注 + 加入社区

切换为时间正序

user2007001 2016-05-26

打赏
举报

我觉得应该在程序代码上下功夫，SQL创建一个存储过程P，存储过程参数：表名、记录数据值、output参数。程序代码获取写入数据集，创建10个线程分别执行存储过程。

Tiger_Zhao 2016-05-23

打赏
举报

[Quote=引用 33 楼 yenange 的回复:]你的SQL 写得不错，但维护方面应该做得不多。 [/Quote]

除了你别人都是骗老板/客户钱的！

维护问题变数多多。
能够指出一个问题的可能方向，给出尝试的方法，我只能做到这样了。
像你那样凭着几句话就能下论断的，神仙啊

吉普赛的歌 2016-05-20

打赏
举报

引用 32 楼 Tiger_Zhao 的回复:

[Quote=引用 29 楼 yenange 的回复:]您在瞎扯吧。比如：一个库 100 GB, 设置增长 10%, 一次就得申请 10GB的空间，空间浪费大，申请10GB的空间得老半天…… [/Quote] 你的头像倒是和瞎扯很配！没看到后半句吗？

你的SQL 写得不错，但维护方面应该做得不多。

Tiger_Zhao 2016-05-20

打赏
举报

[Quote=引用 29 楼 yenange 的回复:]您在瞎扯吧。比如：一个库 100 GB, 设置增长 10%, 一次就得申请 10GB的空间，空间浪费大，申请10GB的空间得老半天…… [/Quote]
你的头像倒是和瞎扯很配！没看到后半句吗？

吉普赛的歌 2016-05-20

打赏
举报

引用 28 楼 Tiger_Zhao 的回复:

数据库就是靠用空间换时间的啊！临时增加MDF大小是一个比较耗时的操作。不要频繁引起MDF文件增长，MDF大小要一次性开足。增长率设为 5%～10%；如果固定大小增长，你估计一下自己的数据增量，至少要比一天的增量多一点。

您在瞎扯吧。比如：一个库 100 GB, 设置增长 10%, 一次就得申请 10GB的空间，空间浪费大，申请10GB的空间得老半天……

吉普赛的歌 2016-05-20

打赏
举报

引用 28 楼 Tiger_Zhao 的回复:

[Quote=引用 8 楼 Q1092926267 的回复:]目前的MDF文件增长速度才3M/s 服务器应该不至于吧[/Quote] 数据库就是靠用空间换时间的啊！临时增加MDF大小是一个比较耗时的操作。不要频繁引起MDF文件增长，MDF大小要一次性开足。增长率设为 5%～10%；如果固定大小增长，你估计一下自己的数据增量，至少要比一天的增量多一点。

您在瞎扯吧。比如：一个库 100 GB, 设置增长 10%, 一次就得申请 10GB的空间，空间浪费大，申请10GB的空间得老半天……

吉普赛的歌 2016-05-20

打赏
举报

引用 28 楼 Tiger_Zhao 的回复:

[Quote=引用 8 楼 Q1092926267 的回复:]目前的MDF文件增长速度才3M/s 服务器应该不至于吧[/Quote] 数据库就是靠用空间换时间的啊！临时增加MDF大小是一个比较耗时的操作。不要频繁引起MDF文件增长，MDF大小要一次性开足。增长率设为 5%～10%；如果固定大小增长，你估计一下自己的数据增量，至少要比一天的增量多一点。

您在瞎扯吧。比如：一个库 100 GB, 设置增长 10%, 一次就得申请 10GB的空间，空间浪费大，申请10GB的空间得老半天……

Tiger_Zhao 2016-05-20

打赏
举报

[Quote=引用 8 楼 Q1092926267 的回复:]目前的MDF文件增长速度才3M/s 服务器应该不至于吧[/Quote]
数据库就是靠用空间换时间的啊！
临时增加MDF大小是一个比较耗时的操作。
不要频繁引起MDF文件增长，MDF大小要一次性开足。
增长率设为 5%～10%；如果固定大小增长，你估计一下自己的数据增量，至少要比一天的增量多一点。

吉普赛的歌 2016-05-20

打赏
举报

1. 多线程往不同的表里插入数据，不会有堵塞的问题。 2. 如果慢，大部分情况是磁盘IO或者设置的问题。建议你先检测磁盘的IO，可以用工具：http://download.csdn.net/detail/yenange/9402028 3. 右键看一下数据库的“属性“->"文件"，观察一下列表中的”文件增长设置“，如果设置成每次增长1MB，不慢才怪！应该改成 50~100MB才算合理。

six-years 2016-05-19

打赏
举报

引用 25 楼 yupeigu 的回复:

[quote=引用 24 楼 Q1092926267 的回复:] [quote=引用 20 楼 yupeigu 的回复:] [quote=引用 19 楼 Q1092926267 的回复:] [quote=引用 18 楼 yupeigu 的回复:] [quote=引用 17 楼 Q1092926267 的回复:] [quote=引用 16 楼 yupeigu 的回复:] [quote=引用 15 楼 Q1092926267 的回复:] [quote=引用 13 楼 yupeigu 的回复:] 里面有一个 lastwaittype 字段，里面会有最后的等待类型。

ASYNC_NETWORK_IO 这个类型等待时间最长[/quote] 这个是异步网络io等待，也就说等待出现在网络上，你的程序是通过网络连接到sql server 的对吧[/quote] 没有啊是本地数据库程序和sql在同一台PC[/quote] 那就更加奇怪了，照理本地是不会偶这种网络等待情况的。对了，你确定这个等待是你的程序导致的吗？你的程序开了10个线程，每个线程是用独立的连接连接到数据库的，那么每个连接都会有一个会话id，你在程序中能否输出一下会话id： select @@spid 然后，和上面监控代码返回的结果去核定一下会话id，在看看等待是什么[/quote] 其他类型的等待例如latch_sh 以及io_complation 比较少两三百的样子[/quote] io_completion是硬盘方面的等待，latch_sh是内存共享闩锁的等待，一般是指读取次数太多导致的。[/quote] 我用sqlserver profiler监控 Reads 指标几万次这个是因为硬盘问题吗[/quote] 这个reads不一定就是硬盘的问题，reds可能是物理读，也可能是逻辑读，物理读就是从硬盘上读，逻辑读就是从内存里读，要具体情况具体分析。你的这个情况，不太清楚数据是从哪里读到哪里。[/quote] 我感觉应该从内存读取吧每次插入数据库都要从内存获取自增长的主键

LongRui888 2016-05-19

打赏
举报

引用 24 楼 Q1092926267 的回复:

[quote=引用 20 楼 yupeigu 的回复:] [quote=引用 19 楼 Q1092926267 的回复:] [quote=引用 18 楼 yupeigu 的回复:] [quote=引用 17 楼 Q1092926267 的回复:] [quote=引用 16 楼 yupeigu 的回复:] [quote=引用 15 楼 Q1092926267 的回复:] [quote=引用 13 楼 yupeigu 的回复:] 里面有一个 lastwaittype 字段，里面会有最后的等待类型。

six-years 2016-05-19

打赏
举报

引用 20 楼 yupeigu 的回复:

[quote=引用 19 楼 Q1092926267 的回复:] [quote=引用 18 楼 yupeigu 的回复:] [quote=引用 17 楼 Q1092926267 的回复:] [quote=引用 16 楼 yupeigu 的回复:] [quote=引用 15 楼 Q1092926267 的回复:] [quote=引用 13 楼 yupeigu 的回复:] 里面有一个 lastwaittype 字段，里面会有最后的等待类型。

six-years 2016-05-18

打赏
举报

引用 20 楼 yupeigu 的回复:

[quote=引用 19 楼 Q1092926267 的回复:] [quote=引用 18 楼 yupeigu 的回复:] [quote=引用 17 楼 Q1092926267 的回复:] [quote=引用 16 楼 yupeigu 的回复:] [quote=引用 15 楼 Q1092926267 的回复:] [quote=引用 13 楼 yupeigu 的回复:] 里面有一个 lastwaittype 字段，里面会有最后的等待类型。

LongRui888 2016-05-18

打赏
举报

引用 19 楼 Q1092926267 的回复:

[quote=引用 18 楼 yupeigu 的回复:] [quote=引用 17 楼 Q1092926267 的回复:] [quote=引用 16 楼 yupeigu 的回复:] [quote=引用 15 楼 Q1092926267 的回复:] [quote=引用 13 楼 yupeigu 的回复:] 里面有一个 lastwaittype 字段，里面会有最后的等待类型。

six-years 2016-05-18

打赏
举报

引用 18 楼 yupeigu 的回复:

[quote=引用 17 楼 Q1092926267 的回复:] [quote=引用 16 楼 yupeigu 的回复:] [quote=引用 15 楼 Q1092926267 的回复:] [quote=引用 13 楼 yupeigu 的回复:] 里面有一个 lastwaittype 字段，里面会有最后的等待类型。

LongRui888 2016-05-18

打赏
举报

引用 15 楼 Q1092926267 的回复:

[quote=引用 13 楼 yupeigu 的回复:] 里面有一个 lastwaittype 字段，里面会有最后的等待类型。

ASYNC_NETWORK_IO 这个类型等待时间最长[/quote] 这个是异步网络io等待，也就说等待出现在网络上，你的程序是通过网络连接到sql server 的对吧

six-years 2016-05-18

打赏
举报

引用 16 楼 yupeigu 的回复:

[quote=引用 15 楼 Q1092926267 的回复:] [quote=引用 13 楼 yupeigu 的回复:] 里面有一个 lastwaittype 字段，里面会有最后的等待类型。

ASYNC_NETWORK_IO 这个类型等待时间最长[/quote] 这个是异步网络io等待，也就说等待出现在网络上，你的程序是通过网络连接到sql server 的对吧[/quote] 没有啊是本地数据库程序和sql在同一台PC

LongRui888 2016-05-18

打赏
举报

引用 17 楼 Q1092926267 的回复:

[quote=引用 16 楼 yupeigu 的回复:] [quote=引用 15 楼 Q1092926267 的回复:] [quote=引用 13 楼 yupeigu 的回复:] 里面有一个 lastwaittype 字段，里面会有最后的等待类型。

six-years 2016-05-18

打赏
举报

引用 13 楼 yupeigu 的回复:

里面有一个 lastwaittype 字段，里面会有最后的等待类型。

ASYNC_NETWORK_IO 这个类型等待时间最长

Ginnnnnnnn 2016-05-18

打赏
举报

bulk insert 已经是sql server 里面大容量导入操作的方法，如果是多线程导入多表，会不会是硬盘的写入问题呢？

加载更多回复（15）

多线程BulkCopy批量添加数据到不同表

相关推荐