|
现有问题：
1， 所有记录在一张表上。没有分类
2， 开发时，由于没有考虑这么大量的数据。查询语句放在程序中执行，造成速度过慢
3， 根据关系型数据库的插入过程原理，每插入一次，建一次索引查询，那么，将占用大量的内存与CPU资源，速度也将大大降低。在表中有100条记录的情况下插入与在10000条记录的情况下插入，速度与效率是完全不一样的！
4， 插入与查询是在同一张表里。并发处理数可能峰值有1000多。
5， 根据关系型数据库的查询原理，如果有人要查询记录表，将会是这样的一个数学表达式
一条记录 <=1K
总共100,000条记录，每天2万的增长速度
如果不知条件，任意查询，那将会是这样：
（1K * 100,000）/1024 = 10M
1个人是10M。如果是200个人同时查，那将会是这样：
200*10M = 2000M （约2G）
这样大的数据被数据库中取出来。并下载到本机查看，本来就是很庞大的。
6， 各输入网点的网速很多还是“猫”上网，速度肯定跟不上。
7，服务器中还存放着其它的数据等等。
7， 服务器带宽只是专线8M，就算服务器的CPU能计算得过来，数据也送不出去，就被挤塞了！
由于上述问题，出现的情况如下：
1， 网站服务器硬盘物理烧毁一块。
2， 网站带宽被完全占用，基本难以访问。
3， 网站页面速度极其慢，数据传输效率低。
4， 有些个输入单位由于网速无法响应他的操作，送出的数据包无法返回，已无法完成记录输入。
解决办法（思路）:
1， 服务器更新。（硬件上）
2， 网络带宽增加。（硬件上）
3， 把查询放在数据库中进行，使用存储过程，但在百兆网速下，存储过程的应用基本与程序查询没什么明显区别。（软件上）。
4， 插入记录时，使用缓冲表，每10分钟，将缓冲表向主记录表倒一次数据。这样可以缓解主记录表的压力。让主记录表专门应对查询动作（软件上）
5， 查询时，使用文本读出记录，因为基于系统底层的指计移动，查询效率将会提高100倍。但是需要FileObjectSystem组件支持。安全性要考虑。（软件上）
如果不采取措施，会引起的问题：
数据库不堪重负，硬盘会再次烧毁。
服务器CPU一直处在100%满负荷下运行。
程序系统完全崩溃。
数据无法即时插入，无法即时反应。
无法统计与追踪。
各网站无法正常运行。
|
