mysql 查询优化的怪事，跟大家分享一下
一个简单的查询，select   count(*)     from   table1     where   result   like   "%ahfdsd% ";特地不用索引来全盘扫描一张表，来测试mysql   的查询性能，result   是   text字段，没有索引。发现CPU的利用率30左右，内存占用较少，耗时31秒。搞笑的是，当我修改result的匹配值，多次执行该查询时，发现耗时42秒。
          当我设置   flush_time=50，以后的连续查询也只要31秒，可flush_time=50是每隔50秒关闭所有不用的表，而我接下来的查询都是要打开同一张表的啊，按理说，flush后重新打开表，查询需要的时间更长才对啊，郁闷。
          还有增大   read_buffer_size的值，read_buffer_size＝1M，   查询性能反而下降，要45秒。

我的配置是：windows   2003,mysql   5.1,CPU   2.0G   ,内存   2.0G；机器只运行mysql。
数据库中只有一张表   有1000万条记录，大小是2.03G；
my.ini的主要配置：table_cache   是256，read_buffer_size=32K   ，key_buffer_size=595M，引擎是myisam。
测试是在服务器的mysql   client   端执行的SQL语句。

大家说说自己的看法啊


------解决方案--------------------
like "%ahfdsd% "，你是否建立索引，数据库都不会使用索引的。

你发送sql到服务器，数据库会对你的sql进行优化，生成它认为最好的执行计划，当你下一次去使用相同的sql的时候，数据库不会对你的sql在进行优化了，直接使用以前的（就是说节省了一步）所以快一些。

read_buffer_size这个参数不太明白，看文档是说“请求将分配一个缓存区”，如果我理解的不错，当你把这个增大，那么，请求的命中率就降低了，所以会变慢。

------解决方案--------------------
因为你的数据量太大，而又使用不了索引（like '%XXXXX ' 是不会使用索引的），MySQL只能使用自身的加速查找算法。缓存是帮不了你什么忙的，其大数据量还是得依靠硬盘。
CPU的占用率低，但是，硬盘可是在疯狂转呀，如果，硬盘不转的话，估计CPU的占用率绝对在95％以上。（等待系统总线，硬盘接口和硬盘内部数据读取速度与CPU一级缓存速度一致的情况下再测试吧）

楼主的这个测试，估计缓存的命中率还是很高的。保守估计在99.5%以上。