我是如何在 SQL Server 中处理每天四亿三千万记录的？

起首，我想到的是，修噶BulkCopy的各项参数，BulkCopyTimeout、BatchSize，赓续的测试调剂，结不雅老是在某个范围波动，实际并没有影响。或许会影响一些CPU计数，然则远远没有达到我的期望，写入的速度照样在5秒1w~2w波动，远远达不到请求20秒内要写20w的记录。

于是让同事履行下述语句以便得出更多的信息：

按采集设备存储

是的，上述构造按每个指标每个值为一笔记录，是不是太多的浪费？那么按采集设备+采集时光作为一笔记录是否可行？问题是，怎么解决不合采集设备属性不一样的问题？这时，一个同事发挥才能了，监控指标+监控值可以按XML格局存储。哇，还能如许？萌芽呢，可以用for XML这种情势。

结不雅验证，比膳绫擎的稍微好点，然则不是太明显。

修改BulkCopy的参数

数据表分区？？？

那个时刻还没有学会这个技能，看了下网汕９依υ?┞仿，似乎挺复杂的，时光不多了，不敢测验测验。

停止其他法度榜样

我知道这个肯定是不可的，因闻敉件、硬件的架构临时没法修改。然则我欲望验证是不是这些身分影响的。结不雅发明，提示确侍峦辉，然则照样没有达到请求。

难道是SQLServer的瓶颈？

没辙了，难道这就是SQLServer的瓶颈？上彀查了下相干的材料，可能是IO的瓶颈，尼玛，还能怎么办，要进级办事器，要改换数据库了吗，然则，项目方给吗？

等等，似乎还有个器械，索引，对索引！索引的存在会影响插入、更新

去掉落索引

是的，去掉落索引之后萌芽肯定慢，然则我必须先验证去掉落索引是否会加快写入。如不雅不雅断把MgrObjId和Id两个字段的索引去掉落。

于是有了这种构造：No、MgrObjId、Dtime、XMLData

运行，事业出现了，每次写入10w笔记录，在7~9秒内完全可以写入，如许就达到了体系的请求。

萌芽怎么解决？

一个表一天要4亿多的记录，这是弗成能萌芽的，在没有索引的情况下。怎么办！？我又想到了我们的老办法，物理分表。是的，本来我们按天禀表，那么我们如今按小时分表。那么24个表，每个表只需存储1800w笔记录阁下。

然后萌芽，一个属性在一个小时或者几个小时的汗青记录。结不雅是：慢！慢！！慢！！！去掉落索引的情况下萌芽1000多万的记录根本是弗成想象的。还能怎么办？

说干就干，结不雅，经由过程按10个采集嵌入式并按24小时分表，天生成成240张表(汗青表名类似如许：His_001_2014112615)，终于把一天写入4亿多笔记录并支削发单的萌芽这个问题给解决掉落了！！！

萌芽优化

在上述问题解决之后，这个项目标可贵已经解决了一半，项目监管也不好意思过来找茬，不知道是出于什么样的┞方进出配吧。

过了很长一段时光，到如今快岁尾了，问题又来了，就是要拖逝世你让你在岁尾不克不及验收其他项目。

此次请求是如许的：因为上述是模仿10w个监控指标，而如今实际上线了，却只有5w个阁下的设备。那么这个明显是不克不及达到标书请求的，不克不及验收。那么怎么办呢？这些聪慧的人就想，既然监控指标减半，那么我们把时光也减半，不就达到了吗：就是说按如今5w的设备，那你要10s之内人库存储。我勒个去啊，按你这个逻辑，我们如不雅只有500个监控指标，岂不是要在0.1秒内人库？你不推敲下那些受监控设备的感触吗？

然则别人要按摩，你能怎么办？接招呗。结不雅把时光降到10秒之后，问题来了，大年夜家细心分析膳绫擎逻辑可以知道，分表是按采集器分的，如今采集器削减，然则数量增长了，产生什么工作呢，写入可以支撑，然则，每张表的记录接近了400w，有些采集设备监控指标多的，要接近600w，怎么破？

于是技巧相干人员开会评论辩论相干的举措。

在不加索引的情况下怎么竽暌古化萌芽？

有同事提出了，where子句的次序，会影响萌芽的结不雅，因为按你刷选之后的结不雅再处理，可以先刷选出一部分数据，然后持续进行下一?前提的过滤。听起来似乎很有事理，然则SQLServer萌芽分析器不会主动优化吗？谅解我是个小白，我也是感到罢了，感到应当跟VS的编译器一样，应当会主动优化吧。

具体如何，照样要用事实来措辞：

结不雅同事修改了客户端之后，测试反馈，有较大年夜的改良。我查看了代码：