sqlserver性能优化呼叫中心来电归属地查询

数据21万多,对【CHARINDEX和SUBSTRING】和【In和Or】在是否有索引的条件下的检测和比较。

1. CHARINDEX
SELECT addressFROM PhoneToAddressInfo WHERE (CHARINDEX(Phone, &＃39;15201956983&＃39;) &＃61; 1)
不创建索引&＃xff1a;表 &＃39;PhoneToAddressInfo&＃39;。扫描计数 1&＃xff0c;逻辑读 942 次&＃xff0c;物理读 0 次&＃xff0c;预读 0 次。CPU 时间 &＃61; 650 毫秒&＃xff0c;耗费时间 &＃61; 650 毫秒。
创建索引&＃xff1a;表 &＃39;PhoneToAddressInfo&＃39;。扫描计数 1&＃xff0c;逻辑读 955 次&＃xff0c;物理读 0 次&＃xff0c;预读 0 次。CPU 时间 &＃61; 734 毫秒&＃xff0c;耗费时间 &＃61; 736 毫秒。

结论&＃xff1a;CHARINDEX查询的列创建索引没有实际的意义&＃xff0c;因为CHARINDEX不走索引和like’%---‘相似。

2.SUBSTRING
SELECT Address FROM PhoneToAddressInfo WHERE phone&＃61;SUBSTRING(&＃39;15201956983&＃39;,1,7)
不创建索引&＃xff1a;表 &＃39;PhoneToAddressInfo&＃39;。扫描计数 1&＃xff0c;逻辑读 942 次&＃xff0c;物理读 0 次&＃xff0c;预读 0 次。CPU 时间 &＃61; 75 毫秒&＃xff0c;耗费时间 &＃61; 75 毫秒
创建索引&＃xff1a;表 &＃39;PhoneToAddressInfo&＃39;。扫描计数 1&＃xff0c;逻辑读 3 次&＃xff0c;物理读 0 次&＃xff0c;预读 0 次。CPU 时间 &＃61; 0 毫秒&＃xff0c;耗费时间 &＃61; 0 毫秒。

结论&＃xff1a;SUBSTRING查询的列创建索引在查询时有着本质的提高&＃xff0c;合理使用提高查询性能。

3.IN
表 &＃39;PhoneToAddressInfo&＃39;。扫描计数 3&＃xff0c;逻辑读 10 次&＃xff0c;物理读 0 次&＃xff0c;预读 0 次。CPU 时间 &＃61; 0 毫秒&＃xff0c;耗费时间 &＃61; 0 毫秒。
SELECT Address FROM PhoneToAddressInfo WHERE phone in (SUBSTRING(&＃39;15201956983&＃39;,1,7),SUBSTRING(&＃39;18926175999&＃39;,1,7),SUBSTRING(&＃39;13150105555&＃39;,1,7))



4.OR
表 &＃39;PhoneToAddressInfo&＃39;。扫描计数 3&＃xff0c;逻辑读 10 次&＃xff0c;物理读 0 次&＃xff0c;预读 0 次。CPU 时间 &＃61; 0 毫秒&＃xff0c;耗费时间 &＃61; 0 毫秒。
SELECT Address FROM PhoneToAddressInfo WHERE phone&＃61;SUBSTRING(&＃39;15201956983&＃39;,1,7) or phone&＃61;SUBSTRING(&＃39;18926175999&＃39;,1,7) or phone&＃61;SUBSTRING(&＃39;13150105555&＃39;,1,7)


结论&＃xff1a; or和in的效率几乎一样
1、当IN(条件列表) 中的条件列表是少量值时&＃xff0c;它会解释成OR连接&＃xff0c;即最后编译成和OR连接一模一样的语句&＃xff1b;
2、当IN(条件列表) 中的条件列表很长时&＃xff0c;或者你使用OR方法来连接条件并且连接数量很多时&＃xff0c;则它们最后的解释效果也是一样的&＃xff0c;即都是把条件列表创建为一个哈希表&＃xff0c;然后和被查询的表中的行进行对比。