Air支持SQLLite数据库优化

Air支持SQLLite数据库，再实际开发中还是有不少地方需要注意优化的。这次AIR Reader中表结构设计时，就为数据库的性能做了不少优化。前几天公司Dev team邮件组里也有关于数据库优化的讨论，这里分享一下。

DBA team主要对Blog的数据库做了优化，把博客系统中大量消耗资源的存储过程查询给消除了一大半。看起来也起到了较好的效果，整个Profile数据库的负载运行情况有明显改善，如图：


-----
Profile数据库服务器的CPU占用率在优化后由近3日的平均40-50% 下降至20%以下。
而从微观的分析来看，昨天在优化1306数据库前，2分钟不到即跟踪到500多次IO超过1000的查询。完成博客存储过程优化后，跟踪了约7分种才捕获到500次IO超过1000的查询。

这 次优化，主要是通过数据结构的变更来得到的。例如，很多博客存储过程比较消耗资源的原因是：一些数据都是每次在查询中进行统计、计算，而不是事先准备好 的，例如：用户每月发表的博客数。以前是需要用到时每次从用户发表的博客列表中进行统计。现在改为每次发表、修改、删除博客时都维护一下当月发表的博客数 （这个代价很小的），查询时直接读取该数据就可以了。
因而可以看到，在我们这样的用户众多的即时事务处理系统中，数据结构设计的一个原则应该是：尽可能通过业务逻辑的设计，在事先将需要的数据准备好，而不是在每次需要用到时进行计算。

另 外一个数据结构方面的较大优化是：将博客内容表中可能用到作为查询条件的字段分离出来（有文章ID、用户ID、发表时间、博客类型、浏览权限类型、分类、 标题等字段），这些字段主要都是整数或者时间类型，不包含博客内容、描述字段，因而整个表的size和索引都比较小，有利于查询的高性能化。在需要用到博 客的内容等其它字段时，首先在小表中查询到ID，再根据到内容表中找齐需要的其他字段。这种方式，在这次查询优化中起到了主要的效果，IO较高的博客存储 过程基本都可以通过这种方式优化，一些原来IO达到数千的在优化后只有几十个甚至十几个IO。
其基本思想应该是：在表结构设计中，应该面向查询进行结构设计的优化，尽可能减少需要大量查询表中行的长度。不再使用的字段一定要从表中删除。（原来的博客文章表中约有三十个字段，其中包含十个左右不再使用的字段）。
-----[by 王平，Myspace China]

这些经验是针对并发访问很高的大型数据库的，但是对AIR开发也有很好的启发作用，如将博客内容表中可能用到作为查询条件的字段分离出来，且尽量使用整数或时间类型等。
但是关于先计算再存储，还是先查询再计算，应该在开发中灵活针对不同的环境选择性使用。


上一篇：AIR中批量insert数据应该怎么解决？   下一篇：SnipplrV1 Released(AIR版)