接手一个采集项目，性能极其低下，一跑公司数据库直接瘫痪。
采集数据访问密集，但对数据及时性无大要求。
下面是我接触过最痛苦的一个项目，也应该是此生见过最烂的项目。
代码层面
1：一次采集10W条，直接进内存
优化：分割，以两千条分步处理。
2：数据进内存时，逐条插入，我不想多说了，（插入前还要验是否有重复数据，走全表扫描，无索引，此条如果规划合适，完全可以避免）
优化：1）：结合业务和数据，比如，此是采集当天，完全可以把当天的需验证的字段全进内存，在内存维护一张小表（或缓存服务器），进行重复验证，将计算挪到本地CPU，避免大量高频的全表扫描。
2）：改为表插入，逐条插入，小数据量还OK，对这种每天近百万的量，简直就是个坑。
3多线程实现方式错误，用10个线程，牛逼吧，可全都是winform的伪多线程，屁用没有。
优化：1）：改用线程池，咱用真线程
4设计一踏糊涂，从多个来源，提取数据，取数据汇总，这些数据必有共性，实现的逻辑连基本的封装都没有，每个是一套，完全独立
优化：1）：接口，封装提取逻辑API，实现公共接口。
5表设计一踏糊涂，同样的数据模型，完全可以放到一张表内，加一个字段区分，这设计的却是完全独立的表，一共20多张表，有没有？！！！！
最坑爹的是，不同的表，同样含意的字段，要么名字不同，要么大小写不同，写SQL，第一个一个比对。
6传参数一踏糊涂，连业务对象都未封装，方法内部，完全一个个传参，一次传10个参的不在少数，优化的时候，我得一个一个对参数，参数命名也不规范，眼睛都对花了，天！！！！！！
前面不是说了么，20多张表呢，优化完1张之后，满以为第二张很顺利，一年瞎了，字段得重新对！！！！！！！
测试数据呢，会写SQL，满心欢喜的写完一个，以为通用了，呵呵，换到另一个表，先改表名，再照着改字段名，呵呵呵呵
7全程SQL，且未用第三方作SQL管理，难以维护，更难以优化，我得在这串SQL里找表，找字段！！！！！！！
优化：1）：改用ORM，至少有数据模型，如果用ORM的话会稍微好些，大数据插入依然走SQL,但至少传参，业务整合，维护着更清晰。
8游标，有统计汇总的功能，但偏偏是用游标实现，一开始统计时，游标会扫描数据，我取个例子，插入或更新10W条，那游标会扫10W次表，同时在跑的这种巨型坑可能有好几个哦，我都想骂娘了！！！！！！！！！！！！！
优化：1）：去游标，游标的细节，这里不想说，因为我也忘了，记住一条，游标走不了数据库的各种优化，能不用就不用，只用在简单函数和触发器里，一次最多扫10条数据，扫多了会哭的。
9定时调用，原本的实现方式，能吓尿你！
编译20多个程序，然后用微软的定时器来定时执行某程序，爽吧，我快爽飞了。
我都快哭了有没有！！！！
想想这场景，修改项目启动参数，编译，上传，再修改编译，再上传，再修改编译，再上传，我当时这么干的时候，心里都麻了，差点过去打人！
当然咱是守法好公民，打人是不会的，不过我真的差点背包走人，后来也真走了。
咱一开始还真这么编译着干，编译了几个，也聪明了，微软的定时器不就自带传参么亲？直接编译一套，我也懒得给他套定时调用框架了，在MAIN方法里写一套参数判断，设定时器的时候，写个参数，这就OK了，只用编译上传一次，不过要在上面复制个20份（因为当时没优化完，有一些数据是要存在程序根目录的文件里）……
优化：1最好的，网上这么多定时的框架，拿一个用用很难？？？？
2不知道这些框架，自已写一套简单的又何难？封装个task，定时反射加载，不就OK了？这种实现方式会死人的。
3最次，我用的那套，用不同的启动参数不就
我折腾了一个多月，极为痛苦的，把这个项目优化好了，转眼发现，如果要我拿来重作，也就2星期的事
简洁，优美，高效。
折腾完了，公司说不要这么项目了。
浪费了一个多月，给一个51程序员擦屁股，擦了一个多月，公司说，这一个月你什么成果都没有么……
呵呵呵。
不过我总算是见识了五年经验一年水平的程序员是什么样了。
如今想来，依然心有余悸，所幸已经解脱了
珍爱生命，远离51
烂项目扔过来，看一眼，吓人，直接闪。