解决服务器性能瓶颈

背景
    公司项目组当初对项目开发性能评估不足，统计分析系统服务端与数据库同处一台服务器设备上，数据库中的很多关键数据表数据都由外界多台应用服务器长时间不间断地实时入库产生，平均每分钟有几万笔数据入库，这些数据表企业要求必须最少保存90天数据，日积月累，数据表数据数以千万计，同时入库的这些数据表还是后台定时统计小时及天数据的作业的源表和用户查询实时数据的目标表，极大影响入库、后台统计和查询分析的执行效率，并且很容易产生资源的竞争。运行一年后统计分析系统性能瓶颈日益显现出来，客户十分不满意。

解决方案
    由于数据库与统计分析系统同处一台服务器设备上，数据库负担之重直接影响统计分析系统程序处理性能。在无法扩容硬件资源的情况下尽最大努力优化服务器架构，减少系统资源消耗，提高统计分析系统程序处理性能。
    最大限度地使入库和统计查询分析的数据表不是同一个，并减少单个数据表的容量，采取自动分流存储，优化数据库定时作业：
    1，实时入库的数据以天为单位存储，数据表命名为“原表名+日期”，实时数据入库时自动选择当天数据表，我们就统称源表；
    2，小时数据以月为单位存储，数据表命名为“原小时表名+月份”，后台定时统计作业自动选择当月数据表；
    3，数据库备份和历史数据清理作业计划每周六执行一次；
    4，后台定时统计作业计划每天凌晨1点执行一次；
    5，要求用户使用统计分析系统选择时间范围时不对分钟数据进行跨天查询，不对小时数据进行跨月查询（系统界面有精确到分钟、小时和天数据的查询条件）；
    6，要求报表系统只产生昨天或过去数据，不对今天的数据做报表分析；
 

好穷。连一台机器都买不起吗？

就看你们进行的这所谓的优化吧。有这些工夫，买台什么服务器买不来。人工不是钱呀。表能改动到这个份上，程序结构的改动也轻不了多少。而且查询代价特别大，这个不成，那个也不许。那还查询分析什么。综合考虑下来，结论是得不偿失。
应该作为反面教材为后人鉴。

买台机器就完事了。

明显的应该使用分区表，按时间分区。

明显没做过电信应用，你以为就几万条数据啊，你那样做一个表里数据肯定上亿，对这些数据做复杂的查询，如连接、分组、排序及其它计算，估计一个查询一年都出不来！

楼主做的没错，电信报表就是一级一级的生成报表，有时一个表要倒好几次数据，将数据过滤到最少，来提高查询速度！

楼主的系统只是在数据库端做了过滤统计的优化，我们的系统在程序处理的过程中在内存中就先做了一层过滤（目前以小时为单位，为防止系统崩溃丢失内存数据，采用了嵌入式数据库做缓存），数据库再做天及其以上的统计！

什么单位这么穷，又平均每分钟有几万笔数据入库？

兄弟，这种情况了都还不加硬件，我真的不知道说什么了。呵呵，估计这个项目没什么钱赚吧。祝你好运

数据应用优化有几个方面的
硬件只是一个方面
先不说 硬件的提升也是有极限的，机器持续增加不见得性能就能对应增长
这在多击并行热备时候显现尤为突出

lz的数据业务上不要求做处理的，直接入库最好
更像个数据仓库

lz也很明显的知道现在瓶颈是硬件IO了，系统部分再榨取也是有限的
而且你们的系统压力大，硬件似乎也没有可靠性的考虑，双机热备，磁阵，RAID估计都没得，也就只能天天半夜备份了。
数据库横纵分表做了，索引做了，还能在查询上动动脑筋
比如使用存储过程来优化sql
使用缓存来减轻重复读取
用友好的用户界面减缓客户等待的烦躁
唉，苦命的娃