数据库大概存储几十万条IP记录，记录集如下：
+----------+----------+------------+---------+---------+--------+--------+
| ip_begin | ip_end | country_id | prov_id | city_id | isp_id | netbar |
+----------+----------+------------+---------+---------+--------+--------+
| 0 | 16777215 | 2 | 0 | 0 | 0 | 0 |
| 16777216 | 33554431 | 2 | 0 | 0 | 0 | 0 |
| 33554432 | 50331647 | 2 | 0 | 0 | 0 | 0 |
| 50331648 | 67108863 | 3 | 0 | 0 | 0 | 0 |
| 67108864 | 67829759 | 3 | 0 | 0 | 0 | 0 |
+----------+----------+------------+---------+---------+--------+--------+
这样做查询需要用到如下SQL：
<?php
$sql = 'SELECT * FROM i_m_ip WHERE ip_begin <= $client_ip AND ip_end >= $client_ip';
?>
这样的检索显然用不到索引，即使用到，MySQL查询效率也不大可能达到每秒500次以上，我做了很多并发优化，最终平均查询效率也只有每秒200次左右，实在是头痛。一开始我也有想到借鉴纯真IP库的检索方法，但是我一直对算法有抵触，也以为二分法很难，所以就没有尝试使用，直到最后没有办法了，才最终实现了二分法的IP地址检索。
从上表可以看到IP库是从0到4294967295的一个连续数值，这个数值要是拆开存储，会有几百G的数据，所以没办法使用索引也没办法哈希。最终我使用PHP将这些东东转为二进制存储，抛弃了数据库的检索。可以看到IP起止长度为一个4字节的长整型，后面的国家ID、省份ID等，可以使用2个字节的短整型来存储，总共一行数据就有18个字节，总共31万条数据，算起来也就5M的样子。具体IP库生成代码如下：
+----------+----------+------------+---------+---------+--------+--------+
| ip_begin | ip_end | country_id | prov_id | city_id | isp_id | netbar |
+----------+----------+------------+---------+---------+--------+--------+
| 0 | 16777215 | 2 | 0 | 0 | 0 | 0 |
| 16777216 | 33554431 | 2 | 0 | 0 | 0 | 0 |
| 33554432 | 50331647 | 2 | 0 | 0 | 0 | 0 |
| 50331648 | 67108863 | 3 | 0 | 0 | 0 | 0 |
| 67108864 | 67829759 | 3 | 0 | 0 | 0 | 0 |
+----------+----------+------------+---------+---------+--------+--------+
这样做查询需要用到如下SQL：
<?php
$sql = 'SELECT * FROM i_m_ip WHERE ip_begin <= $client_ip AND ip_end >= $client_ip';
?>
这样的检索显然用不到索引，即使用到，MySQL查询效率也不大可能达到每秒500次以上，我做了很多并发优化，最终平均查询效率也只有每秒200次左右，实在是头痛。一开始我也有想到借鉴纯真IP库的检索方法，但是我一直对算法有抵触，也以为二分法很难，所以就没有尝试使用，直到最后没有办法了，才最终实现了二分法的IP地址检索。
从上表可以看到IP库是从0到4294967295的一个连续数值，这个数值要是拆开存储，会有几百G的数据，所以没办法使用索引也没办法哈希。最终我使用PHP将这些东东转为二进制存储，抛弃了数据库的检索。可以看到IP起止长度为一个4字节的长整型，后面的国家ID、省份ID等，可以使用2个字节的短整型来存储，总共一行数据就有18个字节，总共31万条数据，算起来也就5M的样子。具体IP库生成代码如下：
