背景

最近收到一个求助，是某项目一天大概有30万PV左右，现在遇到一个问题就是：服务器的资源占用率过高，特别是CPU经常是100%。笔者初步查看了下这个项目的整体逻辑并不复杂，主要就是一个url2code表的插入与查询操作，这个表主要是把对应的url转换成产品码，有点像短网址或者抽奖系统的路径与随机码对应的表；而且服务器配置是2核心4GB。

按理说这个配置坑这种复杂度的30万PV的业务是没有问题的。笔者收到的求助是如何把项目的数据库进行分表及分库操作，收到请求的第一反应是这种级别的没必要把架构搞得太复杂，最多分表处理即可，因为业务流程本来就很单一，就一个核心流程一张数据表（大概50万条记录）和一张辅助表；而且业务复杂度和业务量并不是特别高。

分析

在一些较复杂业务流程中，50万条记录数据表进行分表是很常见的手段，然而求助方自己其实已经把历史的数据分了2张表，新业务按照20万一张表的容量进行分表。然而这样处理后资源占用虽然有所改善，但依然还是过高。于是求助笔者如何把项目快速、安全、低成本进行分库处理。

笔者大概了解了下他们这个项目，在同一条记录的时候，设置了10分钟的memcache实现的内存缓存，一天刷新的数据次数也就一万次以内；即便是这样为啥还是资源占用率超高？通过服务器分析发现是mysql进程占用很高的CPU资源。按理说这么这种级别的量还不足以导致这么大的系统开销。

在查看50万条记录的主表后发现问题所在：数据表的主键是数据的id号（自增的），但这个项目的场景并不像普通的CMS系统，在点击列表具体的文章的时候通过文章的ID去查询具体的详细信息。而它这里是最频繁的select是通过编码code去查询，这个code是个8位数的随机字符（字母+数字组成），也就是普通的文本格式。查询发现每次单条数据需要0.x秒的时间，如果刚好在某个时间段需要频繁刷新数据则势必使得mysql造成系统资源的极大开销。

解决

这里解决这个问题自然不需要去重新购买数据库做分库处理，那样开发成本也会提高（虽然这种复杂度的业务，进行分库也相对容易）。实际上只要优化表的索引问题，即可在相同硬件资源情况下轻松抗住当前的访问量。

相关

上面本质问题是由于开发人员mysql索引问题导致mysql占用CPU过高问题，最土豪的方式肯定是扩充CPU资源来缓解。这里也讲一个类似的场景：某技术支持服务客户咨询说，他们的视频点播系统，有时候总是很卡；原来的开发团队解决方案唯一的办法就是让他升级带宽；而且现在服务器带宽已经升级到100MB独享了。

看了他们这个项目实际上平常并没有多少播放量，业务高峰仅仅是部分短时间内，如他们像用户（主要是内部用）推送视频类型的通知的时候。很显然100MB独享带宽对于这么小的项目而言是有点浪费的，关键是体验依然很差劲。因为100MB带宽对于普通没有多少访问量的项目而言是太浪费了、而对于业务高峰（尤其是视频这种大文件传输场景）依然不够用。

其实稍微调整一下即可低成本解决这个问题，当然前提是原来的项目代码不要太烂。在上传视频的时候把视频文件分离到与web服务独立的存储端（如阿里云OSS），然后用户访问的时候通过按量付费的CDN网络访问即可。这样一来，只有高峰期需要调度更高的带宽资源来应对，而web页面有10MB带宽就足以支撑他这种访问量的项目了；一年下来节省的投入可是非常可观的。

最后

网站开发到底是否需要考虑高性能？这个问题肯定是需要考虑。但考虑从来不是为了考虑而考虑的，比如网上很多网友动不动就把一个小型网站的性能优化搞成了千万级流量网站的架构，那样成本自然也直线上升。

笔者认为，优化高性能是必须的；但这里“高性能”应该是相对的。比如一个DAU只有1万以下的普通的新闻资讯站点，几乎只需要做做简单的文件缓存或静态化以及分离图片等静态资源就足以应对这种访问量；而做更复杂的架构级的升级将大大提升成本。

其实最忌讳的就是本末倒置，比如文章开头说的案例。咨询者一上来就说了一堆诸如分库、均衡负载等等概念，殊不知其实这种数据量的仅仅优化索引问题以及其他适当优化（比如他们已经做了memcache做的两个核心节点的缓存：查url-code对应数据，以及缓存了用户查询记录；当然也有人用Redis来做这样的场景）即可。而一些细节问题不解决好，再所谓的“高阶”方案也是不治本的。