针对你8万行数据的IP查询场景，最有效的优化是改变数据存储方式，而非在现有的8个tinyint列上直接添加索引。当前的查询逻辑几乎无法有效利用索引，强行建索引效果也很有限。

🔍 为什么当前的查询很难用上索引？

你的WHERE条件是由大量OR连接的复杂不等式（<, >, <=, >=）。B树索引在处理这种跨多列的不等式OR查询时能力很弱，SQL Server通常只能选择全表扫描。ORDER BY id DESC又进一步增加了排序开销。

现有的8个tinyint列（IPS0-3, IPE0-3）把IP地址拆得太散，导致索引无法进行有效的范围定位。标准B树索引在处理这种“两维不等式”查询时，本身就不是最优选择。

🚀 首选方案：添加持久化计算列（性能提升最显著）

这是针对IP区间查询的经典优化方案。核心思路是将IP地址转换为单个整数（BIGINT），从而将复杂的8列比较简化为一个简单的BETWEEN查询。

1. 添加计算列并建立索引

-- 添加起始IP和结束IP的整数计算列（PERSISTED使值物理存储，可建索引）
ALTER TABLE china_ip_range
ADD IPS_Int AS (CAST(IPS0 AS BIGINT)*16777216 + CAST(IPS1 AS BIGINT)*65536 + CAST(IPS2 AS BIGINT)*256 + IPS3) PERSISTED;
ALTER TABLE china_ip_range
ADD IPE_Int AS (CAST(IPE0 AS BIGINT)*16777216 + CAST(IPE1 AS BIGINT)*65536 + CAST(IPE2 AS BIGINT)*256 + IPE3) PERSISTED;
-- 在整数列上创建聚集索引（关键！）
CREATE CLUSTERED INDEX IX_china_ip_range_IPS_Int 
ON china_ip_range (IPS_Int);
-- 为结束IP创建非聚集索引
CREATE NONCLUSTERED INDEX IX_china_ip_range_IPE_Int 
ON china_ip_range (IPE_Int) 
INCLUDE (address);

2. 重写查询语句
将应用层的IP也转换为整数（例如 183.22.12.3 → 3071675395），然后执行：

SELECT TOP 1 address 
FROM china_ip_range 
WHERE 3071675395 BETWEEN IPS_Int AND IPE_Int
ORDER BY IPS_Int DESC;

原理：将聚集索引建在IPS_Int上后，查询会快速定位到起始IP小于等于目标IP的记录，然后只需检查紧邻的少数几行的IPE_Int，找到第一个满足条件的区间即可停止，效率极高。有案例表明，这种改造比在ID上建聚集索引快6到7倍，能轻松应对百万级数据。

💡 备选方案：如果暂时不能改表结构

如果受限于应用层改造，必须在现有列上优化，可以创建一个覆盖索引，但效果远不如首选方案。

CREATE NONCLUSTERED INDEX IX_china_ip_range_Covering
ON china_ip_range (IPS0, IPS1, IPS2, IPS3, IPE0, IPE1, IPE2, IPE3)
INCLUDE (address);

​注意：根据复合索引“等值条件在前，范围条件在后”的原则，这个索引只能帮助SQL Server快速定位IPS0（第一个范围列），后续列无法有效利用索引查找，仍可能产生大量扫描。ORDER BY id DESC也可能需要额外排序。这只能算一种妥协方案。

💎 总结与建议

对于IP归属地查询，数据模型的优化远比调整索引重要。将IP地址存储为单个整数是业界最佳实践。

推荐路径：

1. 首选：立即采用持久化计算列 + 整数聚集索引的方案。这是针对此类查询最根本、性能提升最大的优化，8万行数据会瞬间完成查询。

2. 长期建议：在未来的表设计中，直接使用BIGINT类型的IPStart和IPEnd列来存储IP区间，从源头避免拆分存储带来的问题。