天高云淡

热度:

这个问题像梦魇一样一直挥之不去。随着数据记录数量的增长数据表越来越大是无法避免的，而博客服务器资源有限也是现实的，再说了还有数据记录超过5万之后对速度的影响也是非常明显的（记录数量过了10万“朋友来访”就无法正常显示，删到5万就正常了）。

一般共享服务器对数据库大小都是有限制的，否则可能因为个别用户使用超大数据库查询时占用太多系统资源影响其他用户，这个限制是多少目前没谱。不过我的统计数据表曾经达到了40M之巨，那一般的服务器提供给博主使用的应该也差不多在50M左右。数据库大小限定既然是存在的，那StatPressCN必须提供解决方案，不能任由数据库增长超限时出现异常或被服务器提供方警告从而引起博主对插件的不满。限制大小其实是通过限制数据记录数量来实现的，初步计算每条数据记录的大小是231个字节，那10M的大小就是45392条数据记录。给数据表设定大小限制，通过判断数据记录数量进行，超过了就删除时间最早的记录，然后更新归档数据。出于效率考虑，删一条增一条效率太低，因为每次都要归档数据，合适的做法是判断超限了，那就一次性删除一定数量的记录，更新归档数据，优化数据表（实际执行数据记录的操作），等下次又超限的时候在删除一定数量的记录，更新归档数据，优化数据表，如此循环。这个数量定为多少合适呢？不能太小，因为会影响效率，又不能太大，删除多了对博主对来访统计全貌的了解是个损失。那就在两天的数据记录和1024（反应在数据表上大小上则是231K）之间进行比较找个小的做标准，这样可以保障最高也不会删除超过两天的数据记录。那删除那些数据记录呢？因为是要解决数据表占用空间问题，所以操作对象是所有数据记录，包括404的和正常访问的。对删除的记录数量需要做记录吗？为了反映StatPressCN运行的整体情况，还是记录已删除记录数量的好。在什么时候执行这个操作？在加载插件的时候执行有点浪费，因为不是每次访问都会被统计，比如那些对爬虫的来访（设定不统计爬虫来访的前提下）。最好的挂接点是已经确认要记录该次访问了，那就是append新记录之前。

综合以上分析，拟用以下方案解决数据记录太多超过服务器限定大小或影响插件以及博客运行速度的问题：

1、在选项页中增加“数据表大小”设定选项，默认是5M，其它可选项是10M、15M和20M。默认5M是个超安全的设定，能容纳22696条访问记录，对一般的博客流量来讲够用了，且不会影响访问速度和后台高级功能（如朋友来访）的使用。对于那些服务器资源足够且网络水平较高（起码要能理解数据表大小会随着数据记录的增加而增大的）的朋友，可以吧数据表大小设定的更大点以便得到更多的来访信息。另外，此数据表大小限定的优先级别明显高于存储时限限定，且存储时限限定因为不直观对一般用户不容易理解，所以存储时限限定这个选项就可以退休了。

2、在确实要添加新访问记录 的时候，根据所设定的数据表大小对应的数据记录和实际已有的数据记录进行判断，看是否需要执行table_size_limit函数。

3、在table_size_limit函数中首先初始化或对比需要删除的数量，这样更智能，可以应对访问量突然跃上一个新台阶的情况，当然也可以简单化处置，设定一个固定值即可。然后执行删除操作，并将实际删除的记录数量记录在案（可以在其他合适的地方进行显示），然后更新归档数据，然后优化数据表实现物理删除。

这个方案对新用户（刚好使用最新版本启用访问统计的）可以良好运行，但对于使用老版本的当前用户就可能出现问题，比如某用户数据表大小已经超过20M了存储了近两年的数据，可能会因为新版本中对数据表大小5M的默认设定而删除掉大量以前的来访记录。因此需要先判断数据表现有的大小，然后给定一个稍大的值，避免在用户不知情的情况下删除其统计数据记录，还可以避免其数据表无限增大。