条件中使用like的疑问

guilber

免费乐捐，感谢支持

有两条语句，查询结果一样，执行计划不同，执行效率也不同，但不知效率为什么又这么大的差距

语句一：select count(*) from table1 where usernumber like '1332222%'

    STEP 1
        The type of query is SELECT.
        Evaluate Ungrouped COUNT AGGREGATE.

        FROM TABLE
            table1
        Nested iteration.
        Index : idx_table1
        Forward scan.
        Positioning by key.
        Index contains all needed columns. Base table will not be read.
        Keys are:
            usernumber  ASC
        Using I/O Size 2 Kbytes for index leaf pages.
        With LRU Buffer Replacement Strategy for index leaf pages.

语句二：select count(*) from table1 where usernumber like '1332222'+'%'

    STEP 1
        The type of query is SELECT.
        Evaluate Ungrouped COUNT AGGREGATE.

        FROM TABLE
            table1
        Nested iteration.
        Index : idx_table1
        Forward scan.
        Positioning at index start.
        Index contains all needed columns. Base table will not be read.
        Using I/O Size 2 Kbytes for index leaf pages.
        With MRU Buffer Replacement Strategy for index leaf pages.

flybean

执行效率是怎么比较的？两次测试的先后顺序？之间有没有重新启动ＡＳＥ？

guilber

table1有500万的数据，使用语句1，瞬间便能查出结果；使用语句2，查询时间为四十几秒

同样找到一张表，数据有70万左右，类似语句1和语句2的查询，均有如上的效率差别现象

另外，查询前后未重启ASE，查询先后并未改变现象。

另外从计划中可看出

语句1：

With LRU Buffer Replacement Strategy for index leaf pages.

语句2：

With MRU Buffer Replacement Strategy for index leaf pages.

查询了一些资料，不知是否与此有关。

guilber

没人回答，自己顶！

诺华

涉及到一个搜索变量问题。如果你用like '1332222%'，可以使用搜索变量，实际上转换为大于和小于；如果你使用like '1332222'+'%'，则属于有算术表达式，就不能使用搜索变量。而由于所需列都在索引里面，只是一个索引覆盖，当然效率差很多了！

ehxz

最好用字符串,先把表达式,那怕是简单的+组合起来再SQL处理试试.对数据库来说使用的处理机制不一样,效率就差远了.