有关mybatis的select元素中的flushCache属性的问题？

情况：

二级缓存使用memcached， 确认已经有效。 
select为最简单的单表查询。

代码：

    @Test
    public void selectInterface() { // 查询一条记录  绑定接口的方法
        long start = System.currentTimeMillis();
        Blog blog = blogMapper.selectOne(20);
        log.info(System.currentTimeMillis() - start);
        System.out.println(blog);
    }

这个测试我已经运行了好多遍，发现当flushCache为true时，显示命中，耗时555ms.当flushCache=false，显示命中，耗时60ms.

问题来了，命中了为什么还会去执行sql查询，导致耗时这么高（555ms)? 当flushCache=true，不是应该清空二级缓存嘛，为什么没有清空？

下面是memcached服务端的打印信息，当flushCache为true时。
看到这些打印信息的时候，上面的问题是可以解决了（正如manong回答的一样）。但是有这种需求吗？...... 什么时候需要这种情况.

<27 new auto-negotiating client connection
27: Client using the ascii protocol
<27 get _mybatis_c68c7a9c8692f50b0a7e9d8cd5c0fb5ec39f8147
>27 sending key _mybatis_c68c7a9c8692f50b0a7e9d8cd5c0fb5ec39f8147
>27 END
<27 get _mybatis_1b0fd7114deb0c874aa3baf3328c114b91d05ea4
>27 sending key _mybatis_1b0fd7114deb0c874aa3baf3328c114b91d05ea4
>27 END
<27 delete _mybatis_c68c7a9c8692f50b0a7e9d8cd5c0fb5ec39f8147
>27 DELETED
<27 delete _mybatis_1b0fd7114deb0c874aa3baf3328c114b91d05ea4
>27 DELETED
<27 set _mybatis_c68c7a9c8692f50b0a7e9d8cd5c0fb5ec39f8147 1 2592000 228
>27 STORED
<27 get _mybatis_1b0fd7114deb0c874aa3baf3328c114b91d05ea4
>27 END
<27 set _mybatis_1b0fd7114deb0c874aa3baf3328c114b91d05ea4 1 2592000 105
>27 STORED
<27 connection closed.

flushCache为true的时候，每次调用都清理缓存，这样等于你每次调用都要重新读数据库和写缓存，自然很慢
flushCache为false的时候，每次调用不清缓存，除了第一次调用较慢，后面都会很快

题主可能对useCache和flushCache这两个选项有点混淆：

flushCache：如果设成true，当语句调用时一级二级缓存都会被清理掉。select语句默认是false
useCache：如果设成true，语句调用的结果会缓存在二级缓存里。select语句默认是true

一般来讲，我们查询的时候会把useCache设成true，当然可能有些结果变化很频繁的查询可以设成false，因为这种做缓存效果不大。flushCache一般会设成false，因为查询不会改变数据库的结果，不需要去更新缓存

相反，我们做update或delete的时候，flushCache就要设成true了，因为可能会改变数据库的记录导致缓存失效。同时useCache就没必要设成true了，因为update或delete的结果缓存没啥意义

希望上面的描述能帮助题主理清概念

【热门文章】