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%以上。
