天魔窟

sinzy 现在用的是 Access 数据库，0.8 版将改为 MySQL，我想当然的认为，所有的原有 SQL 查询速度都将会有极大提升。

但是昨晚的测试中发现，Blog 社区首页信息（主要是 Blog 名，用户名，网志数和评论数等等）的读取，使用同样的 SQL 语句（未经优化，包含相关联的子查询），Access 的速度明显比 MySQL 快得多，MySQL 最多的一次花了20秒！！！难以置信。

经过简单的 profiling，确定速度瓶颈在计算评论总数这一点上。

表的结构很简单，用户表（t_bloggers）里包含网志计数（entry_num）字段，网志表（t_entries）里包各篇网志的评论数，我需要用一条 SQL 取得网志数和评论数，比较直观的，借助子查询的写法就是 select title, entry_num, (select sum(comment_num) from t_entries where blogger_id = t_bloggers.id) from t_bloggers ... 在 Access 中，这一句的执行速度很快。即使单独将 select sum() 拎出来跑，MySQL 还是慢，比如统计我的评论总数时平均费时1.5秒。

我又不想去掉首页上评论数的显示，看了一下 PunBB（一个开源的论坛）的代码，它是用了2个冗余字段来分别保存主题数帖子数，我也觉得不爽。

于是放狗搜索，找到的一些说法大都是 MySQL 在处理关联子查询方面效率不高。

今天随意看到的一篇讲 MySQL 优化的文章，上面提到了

MySQL will indeed use a dynamic row format if it contains variable length fields like TEXT or BLOB, which, in this case, means sorting needs to be done on disk. The solution is not to eschew these datatypes, but rather to split off such fields into an associated table.

。

我的网志表正好包含 TEXT 类型字段，于是把它拆了出去，再跑，0.2秒。

原来如此，根据 DBMS 对不同类型字段的处理方法的不同，可以用垂直分区来做优化。学习了。

但为什么 Access 在这方面就做得很好呢？微软的东西，一贯傻瓜化吧。