早上测试对性能压测，发现取sequence服务大量超时报错，查询线上的监控SQL：
大量这个查询，我在DeviceID和Isdelete上建有复合索引，应该很快，而且我测试了一下，取值，执行效率很高，不会出现慢的情况。
但是通过SQL Profile工具监控，发现这个sql，执行的CPU和IO都是很高,取出profile监控出来的sql：
exec sp_executesql N'select * from AppCustomerDevice where DeviceID=@DeviceID and IsDelete=0',N'@DeviceID nvarchar(4000)',@DeviceID=N''
原来这条数据查出17多万条数据，所以执行很慢。后来沟通下来DeviceID='' 是一些错误数据，技术可以把这些IsDelete=0的数据改成IsDelete=1，改成1后，按情况SQL应该优化好了，
但是通过SQL Profile工具发现，还是这个sql执行起来很慢，看其执行计划还是走的全表扫描，让技术把这个参数化的写法改成非参数化，但是要发版，后来在@DeviceID=N‘2’ 随便取值还是IO很高。
看情况是执行计划有午，要么固定其执行计划，加上 with(index=索引名)，但是发版时间长，感觉就是统计信息不对，
在这个库上执行了一下更新统计信息： EXEC sp_updatestats ，在清空一下缓存： dbcc freeproccache
再次执行，发现用到索引。问题解决。
总结：
1，一直以为建索引就OK，其实要看查询sql这个的数据量有多少，刚好这个查询就是查得最大的，17多万条，而且全部取出，
2，参数化查询后，执行计划未选择最优，可以考虑先更新一下数据库的统计信息 ，在清空一下缓存