浅谈--数据库 SQL千万级数据处理解决方案

末蓝、 2022-09-23 04:54 358阅读 0赞

在这个大数据兴起的时代，过亿条的数据的处理已经不少见了。以至于一个处理过程要几个小时的。后面慢慢优化，查找一些经验文章。才学到了一些基本方法。分享一下，由于不是专业的DBA，可能不是最优的解决方案,共同学习和探讨吧...

1. 数据太多。放在一个表肯定不行。   
  
比如月周期表。一个月1000万，一年就1.2亿，如此累计下去肯定不行的。所以都是基于一个周期数据一个表。甚至一个周期数据就要分几个分表。主要是考虑实际的数据量而定。当你创建一个新表时，可能这个表需要有索引，但是都要先取消索引，或者先建立表，导入数据后，再建立索引。   
  
必要时处理完，统计完后，就备份到磁带或者其他介质。然后清掉。   
  
从问题域来看，一个周期内的数据关联性最大。比如统计一个客户某个帐期的话单总额，同比上月增幅，还有就是零话费客户等。如此种种，参照的数据不外乎本周期，或者两个周期，甚至更多就是一个季度，或者半年的样子（类似三个月连续零话费，或者三个月连续欠费未交之类的，保存量之类的报表可能会要一年的数据）。而且这样的情况在数据挖掘或者高级管理报表中比较常见，一般营业部门使用的界面中，是不可能含有这样的统计的。   
  
所以数据按表分开，甚至于可以按数据库分开，更便于管理。   
  
大家要打消一种固有的思路，这些数据，跟环卫工人处理垃圾一样，是几乎有点带人工处置的多步骤方式，也就是不会作为常规数据（如客户基本资料等）长期存在和频繁使用的。所以我们可以改变思路，就是想尽办法，在需要的时候，做最佳处理，而在不需要时，清理掉它。也就是说，比如分表，你可以分100个表，1000个表都可以。只要方便统计和得到所需数据即可。   
  
view只是说你能在写select语句时简单一点，对速度没有任何提高。   
  
主要是，你的分表的方式能建立减少访问所有数据，就能提高速度。比如你做某个统计，那些数据恰好在某个分表内。举例说，你有10个分部，而你统计id=1这个分部时，你恰好把数据放在第一个分表里，你就可以在存储器内通过判断，只访问第一个分表，从而提高统计速度。如果你的统计需要统计全部分表内的数据，那处理速度还是一样慢。   
  
2. 假设每个表的数据在数十万条，那统计起来是没有任何瓶颈的。常规的数据库都应该没任何问题。   
  
3. 预处理的必要性。   
  
有人问：我统计一千万条数据汇总，要多久多久，能否提高。。。试想你把中国人所有的存款加总，需要多长时间吧？看看这个问题的规模，其实再复杂的数据库dbms，我们说他都逃不过：找出符合条件的数据，一条一条的加总这个计算过程。暂且不提where条件了。预处理的必要性在于，如此规模的数据处理，本身就是一个非常耗时的过程，我们有必要提前，处理其结果到一个表内，或者多个表里面。用户查询时，再显示出来。比如说1000万数据分10个分部，要看每个分部的应收增长，那我们可以预先统计数据到分部费用表中，则用户端报表显示时，就非常快。如果任何数据汇总都要从原始数据去统计，那是不现实的。所以我们可以设置原始数据表，中间结果表，结果表，汇总表，月结表，期间表之类的东西。逐步统计归属。   
  
另外要提的是，这样的动作肯定非常耗时，而且！这样的数据如果由服务器的存储过程定期定时执行的话，处理的规模就只有一次，任何客户端，都只从结果表里产生报表。如果不用此方法，任何客户端报表都从原始数据产生，理论上是可以，但是这样的千万条数据汇总的处理会做N次。而且时间上也是不容许的。   
  
  
还有，这样的统计过程最好是分开db进行存放，而公用的数据比如客户基本资料，最好拷贝一份到这个新db中来处理。这样可以不干扰到正常的使用。   
  
可以在晚上，或者另开db或者在另外的server上跑这个过程。处理完后，写一个标志告诉主db，则客户端可以统计这些报表了。   
  
4. 对单行数据做计算字段。举个例子，比如一条记录的产生时间是2016-01-01 12:00:00.001,如果你的统计刚好需要对某个时段进行统计，那最好增加字段，比如hour字段，下一个批处理命令下去，取得小时数，然后再统计。   
  
  
5. select语句中忌讳对column做函数。因为函数将导致查询条件不走索引，而改走遍历所有数据。这样你就是查一条数据，也会遍历所有数据，那岂不是可怜。   
  
  
6. 条件尽量都是数字，也就是都用id，比如分部，镇区，业务种类，接入类型，客户地址，等等，都需要用到fk方式的编码，主表里只用数字id，请记住是数字型id。整数型数字是计算最快的数据类型。如果金额极大，可以用decimal(小数=0）。varchar类型是效率很低的，不过好像有sql的md5算法，我想可以尝试这个方法（我还没试过）。   
  
  
7. 索引，这个是海量数据查询首要解决的问题。   
  
没有索引，就是遍历。索引没有覆盖到，也会走遍历。   
  
  
8. 复杂的统计，用存储器做分步处理，然后得到结果，同比一条select语句实现要轻松和明白得多。   
  
而且对表的占用时间要短得多。当然，很复杂的统计可能要用到条件判断，循环等，一条select语句是无法处理的。多层的where中的子句也是效率低，容易占用表的写法。   
  
原则上，这里我所讨论的问题都不是那种基于网站内容管理的小case，主要对企业运用而言。比如举例说查一个“存量客户增幅表”，问题都不是简单到直接对比两个月的话费总额这么简单，还得找出之前他的话费如何，比如超过多少钱的才列入统计对象。所以，我的理解：复杂的问题，必须存储过程。真正做过几个项目才会明白，写sql语句会比编程代码还要多。真正的程序，其实是sql。   
  
最后说一句，如果经验足够丰富，写出的统计过程，其执行时间在数分钟甚至几个小时都是正常的。所以初学者应该明白，数据量是与处理时间成正比的。如果平时处理几条数据感觉很快，数据量猛然增加几个数量级，不要认为时间上还能优化到几秒钟。   
  
  
ERP里的MRP展开计算，通常能到几个小时的。这都是正常的。(主要是物料多，bom多，计算步骤太多造成)   
  
9. 补充一点。如果数据量超过我们标题的千万级，甚至几十亿数量级。那也不存在问题，还是分而治之的思路，就是把数据在多台服务器上并行运行。就好像为灾区捐款一样，靠一个人的力量是不行的。人多力量大。类似数据分拣之类的，只需要原始数据和基本资料，还有一些计费策略之类的。完全可以分布在多台server上同时处理，也是必要的。主要根据你的数据量和单台处理的速度以及你要求的总的处理时间而决定的。有人说select语句难道也需要分布？只能说，如果确实有必要，也能做到。比如你要返回所有话单异常的数据，那也可以从每台执行检索，然后汇合到一起，我想是可以的。   
  
总而言之：   
  
一。合理设计表结构，使得统计汇总最高效（包括fk设计和用数字id，不用varchar，索引设计，计算字段）；   
  
二。合理分表，使得单表数据规模适当；   
  
三。用存储器分多个步骤处理。   
  
四。数据预先处理。   
  
五。分布在多台server上同时处理。   
  
也就是分而治之与预处理。