秋色园QBlog技术原理解析：性能优化篇：数据库文章表分表及分库减压方案(十五)

本节将介绍秋色园 QBlog 从另一个角度上的网站优化方式：数据库分表分库基础优化。

 

基础说明：

秋色园 QBlog 的优化工作，从一开始都是基于代码的技术优化方案，其中一个很大的原因：

就是秋色园 QBlog 一开始是寄放在朋友国外虚拟主机的子目录中，本人仅有ftp权限；

而操作一个正在运行的几百M的access数据库，实在不是件容易的事，所以优化工作只能在技术上寻求突破。

 

自从秋色园 QBlog 转移到VPS后，能从物理上操作access，优化可选方案也增多了一下，

因此稍为偏移了一下，把整体优化的压力，部分分担到了access数据库。

本节将介绍一个最开始的数据库优化方式：文章内容的分表及分库。

基础分析：

秋色园 QBlog 的access数据库之所以超过600M，是因为有大量的文章表Blog_Content 。 而文章表中占最多空间的，得属文章的内容了，本节将把它给抽出来。

 

我们看下原始的文章表数据结构的设计：

博客文章表：Blog_Content

字段：

ID  文章ID

Title 文章标题

Body 文章内容

Abstract 文章简介

...... 其它字段省略

 

这里有一个常规文章表的设计，就是文章的内容Body 字段，通常是放在文章表中的。

 

而这个字段出现及使用是在什么情况？

出现1：后台发表或编辑文章时

出现2：查看文章。

从这里可以看出，涉及点并不多，很少，而且前台有静态页面顶着，基本除了发文章和编辑文章，这么大数据量的内容，几乎都不露面。

 

那文章表出现和使用又在什么情况下出现？

这个多的数不清，秋色园 QBlog 首页，用户博客首页，文章列表，文章档案，几乎每个页面，都会用到文章列表。

因此，将不常用的，又占有90%以上空间的文章内容 Body 字段独立出来，显得相当有必要。

 

于是进行分表：

多了一个Blog_ContentBody表：

字段，就两个：

ID：文章ID

Body：文章内容。

 

然而仅是进行分表，力度似乎不够。

 

于是再进行分库：

将Blog_ContentBody直接分到另一个access数据库中。

提示：最后发现，去除文章内容的数据库，仅剩下几十M，而文章内容，竟然占了500多M。

 

CYQ.Data 数据框架，自身已支持同时操作多个数据库，因此分库后，改动的代码量很少，主要改动点有：

1：直接登陆vps服务器，使用了CYQ.DBImport，从原来的数据库中，将ID和Body字段导入到另一个数据库的表Blog_contentBody中。

2：打开原来的表Blog_Content，删除Body字段，然后压缩一下数据库，剩下20多M了。

3：直接升级dll到服务器中，整个的升级过程很迅速。

至此，秋色园 QBlog  开始走进数据库优化及代码优化双重结合的整体策略方案，

只是，有一点还没改的，就是还一直纠结的使用access，别问我为啥不用mssql。

也许某天，Access它跑不动了，优化到顶了，其它数据库就上场了。

版权声明：本文原创发表于博客园，作者为路过秋天，原文链接：

http://www.cnblogs.com/cyq1162/archive/2011/07/09/2101729.html

6000字搞不懂大型网站架构技术细节：后端架构数据库分布式事务？ 上节中讨论的数据库事务是解决“单个数据库数据不一致”的问题，而在一些具有规模的网站系统当中，数据库往往不止一个，一旦出现多个数据库，则会出现多数据库的数据不一致问题。 多个数据库的数据不一致问题一般有两种场景，如图4.76所示。
TiDB原理解析系列（一）---Why Do We Use it？ TiDB是PingCAP公司设计的开源分布式NewSQL数据库。由于它兼容MySQL协议，并支持绝大多数SQL功能（比如joins，subqueries, transaction等）。业务能够直接通过MySQL connector去使用它来替换MySQL。
MySQL凭借着出色的性能、低廉的成本、丰富的资源，已经成为绝大多数互联网公司的首选关系型数据库。虽然性能出色，但所谓“好马配好鞍”，如何能够更好的使用它，已经成为开发工程师的必修课，我们经常会从职位描述上看到诸如“精通MySQL”、“SQL语句优化”、“了解数据库原理”等要求。