解决方案 »

  1.   

    有一点忘了说了,整个表只有uid是主键,其他索引都没有。大概有50多个列吧,level是之中之一
      

  2.   

    那level肯定要加一个非聚集索引,不然那么宽的表一般走聚集索引,IO太大了
      

  3.   

    SELECT Row_Number() OVER (ORDER BY [Level] DESC) AS rank, Uid,[Level] FROM users这个的执行计划呢?话说10毫秒几乎感觉不出来,你的程序要求很高?
      

  4.   

    可以变通一下,ROW_NUMBER把比它级低的也带入计算了
    以下效果类似,要精确的话,在表连接条件作更精确比较SELECT COUNT(T2.Uid)rank
    FROM users T1
    LEFT JOIN users T2 ON T1.[Level]<=T2.[Level]
    WHERE T1.Uid = '12045'速度级别同正常的统计一样,优化时也可以参考统计的方式优化
      

  5.   

    SELECT COUNT(*)+1 AS rank
      FROM users
     WHERE [Level] < (SELECT MIN([Level]) FROM users WHERE tb.Uid = '12045')
    Level 上要有索引,这样可以避免全表扫描。
      

  6.   

    楼主,你的表中tb.Uid 是什么数据类型的?
    tb.Uid = '12045' 看一下这个是否会发生强制类型转换
      

  7.   

    能把执行计划贴出来看看不。另外,把uid的查询条件移到内部,怎么会导致rank都是1呢,这个不太可能呀
      

  8.   

    10ms是很快了如果还要改进,且实时性要求不高的话
    可以定时生成、更新 uid和rank的对照表
    查询直接对此表进行即可,速度最快!