IP地址定位区间的问题分析

我总是希望找到一些与众不同地点来解读这一类问题，结果在偶然的一天从IP数据云这里找到了一些思路。

首先需求在IP数据云里面输入一个IP地址【https://www.ip66.net/?utm-source=LJ&utm-keyword=?1146】，能够根据IP查返回IP对应的区域，这就是一个看起来很简单的IP地址定位的问题。

从系统负载方面，CPU的负载较高，而其中很大的一方面代价就是IP地址和数字（IP地址转换为数字）之间的转换和映射。

Buffer Gets指标极高，这个部分其实和整个语句的查取效果有关，如果没有找到匹配的数据，就会扫描更多地块。这个部分一个立竿见影的效果就是使用rownum的方式来截断，在这个基础上，和Oracle的朋友聊，其实也有一些改进措施的，这个部分对于极限优化来说可以参考，所以暂且放一放。

从索引的角度来考虑，Range Scan的方式总是会有优点和缺点，不可能把它同时结合起来达到一个最优的效果，换做哪一个数据库都是如此，只能说有些回表的数据处理Oracle隐式（比如使用rowid)）做好了，而MySQL里面可能需要单独处理。

问题就交代到这里，我今天想再次讨论这个问题是想从几个基础的问题开始来聊聊MySQL在这方面的优势，没错，是相比于Oracle的优势的地方。

第一个考虑点还是数据类型，IP地址是一个字符串，我们是考虑使用varchar类型还是char呢。

假设一个IP地址为10.127.133.199，字符串的长度就是14位，最高设置为3*4+3=15位，这是第一点。

而如果我们存储了一个IP，则意味着这个工作还没有完成，我们还需要转换，所以还不如直接转换为数值，所以综合起来，其实我们实现这个需求，从简化的角度来看，其实不需要一个字符型，而是需要一个数值型即可。

那么问题来了，数值型数据类型其实是很丰富的，这一点和Oracle大大不同，Oracle里面很多开发，DBA都懒了，或者说Oracle内部已经做好了这种适配，数值精度也不需要更多考虑了，长度也不需要区别对待了，直接一个number类型，想调精度，就直接在这个基础上改，比如number(10,3),可以定义长度和精度。MySQL在这方面就分得比较轻，有支持0-128以内的tiny int,32767的smallint等，每一个数据类型都抠得很细。

所以在Oracle里面的豪气在这里就是粗放了，一定需要认真区别对待。

因为我们打算使用数值类型，最后我们选择了int(11),没有留出很富裕的值是因为我们从设计的角度来考虑尽可能按需分配。