代码物语（三）：IP查询（2006）
完成这个IP查询是06年3月时候，记得挂机改造IP数据库那天去做的是计算机控制实验，回来时下着迷蒙小雨。
事实上ip查询的代码量是非常小的，后来的几个小应用都证明了，有时候完成一些有趣的事，只需几行代码。第一次写的算法是一个迂回查询，查询次数非常多。这说明了有时候数据的存储形式（还没到数据结构的地步）也是非常重要的。第二次写的查询方法就超级简单了，直接用大于小于进行判断，而且效率还非常不错。查询单个ip是瞬间完成。但当查询结果记录非常多的时候，翻页非常耗时了。翻页的耗时其实已经和查询方法没关，这只是一个打开大记录集（查询的返回结果）但仅仅需要显示其中一页的优化问题。任何大型的记录集都会遇到这个问题。
后来余读烟酒僧时上数据挖掘课，上网看到一种优化方式后自己改造了一下，并用这个IP数据库进行实验。
http://kuyurasu.blogbus.com/logs/31542961.html
看到一种分页方案：
SELECT TOP pagesize *
FROM Table
WHERE (ID NOT IN
(SELECT TOP pagesize*page ID
FROM Table
ORDER BY ID))
ORDER BY ID但ACCESS数据库的性能实在太烂
三十几万条数据，NOT IN的效率非常低下，比用游标打开整个数据集的方式还要不能忍耐改造了一下
SELECT TOP pagesize *
FROM (select Top (pagesize*page) * from TABLE order by ID) order by ID DESC
ID是自动递增的主键的话，可以去掉中间临时表的order by ID
改造后，page较小时速度比用游标打开整个数据集大大提升，
但当page增加到使得中间临时表几乎囊括全部数据，特别是page=最后一页时，速度就慢了下来，但即使如此，仍然比游标要快
返回的记录集是倒序方式，倒过来访问就行了还可以做一点改进，当page大于全部页数的一半时，从末端开始select TOP，也即中间临时表使用order by ID DESC，这能改善page接近末页的读取分页速度，但ACCESS大数据库使用order by是个噩梦，当page较接近中间位置时，反而会更加慢
查询IP段（0.0.0.0 – 255.255.255.255），30几万条数据的记录集，打开首页和前几页的速度是瞬间，这种分页优化方式是相当有效的。进一步优化还可以做到打开最后几页的速度也是瞬间。
代码下载：IpQuery.rar
文件夹v2是经过分页优化的源码，直接拷出来覆盖掉外面的即可。页码的获取是有问题的，原来打开整个记录集设定pagesize之后可以直接获得页码，分页优化后最终记录集的记录数永远小于或等于100，页码永远为1。获取页码应该换下方法，但余懒得写了Orz
最新评论