1、 数据库设计：数据库内所有表结构均添加索引

调整原因：

近日数据库压力很大，经查有些大数据量表的查询速度很慢，导致数据库服务器CPU一直持续90%-100%，将这些表添加索引后，CPU很快变正常。

2、 将大数据表做分库、分区处理:

具体操作如下：

1）、将大数据表与主数据库分离，单独新建一个数据库，然后将这些表做分区；

2）、将数据插入到消息队列内，后台利用windows计划任务执行（5分钟执行一次）C#控制台程序将消息队列内的数据批量（消息队列内有50000条记录，一次性插入到数据表内）插入到相应的数据表内；

调整原因：

例如：用户访问日志，每次用户访问一个页面的时候我们之前的操作是直接将数据插入数据库，这样做对数据库的访问及操作太大，严重影响其他数据插入、查询的效率，利用分库、分区、消息队列完成此操作的好处是用户访问页面的时候不直接对数据库操作，而是在消息队列内积累一定数量的数据后批量插入数据库，只执行一次数据库操作，而且因为数据库分离的原因，对其他的查询及插入不会有影响；

3、 图片站点分离：

具体操作如下：

1）、新创建一个二级域名，并将二级域名做CDN处理；

2）、网站前台所有图片均使用这个二级域名；

调整原因：

用户访问网站时，如果图片和网站都放在一个站点内，会使得所有操作都在一个站点内进行，一个站点在CPU内的进程有限，都被图片使用了，会影响其他用户的正常下单及其他操作，这样操作的好处是可以减轻一个站点的压力分流到另外一个站点，如果有条件还可以多建立几个图片站点放到不同服务器上（但要做集群操作），JS及CSS也同样可以做这样的操作。

4、 数据缓存：

具体操作如下：

将一些不经常改变的数据，比如商品信息、商品图片信息、分类信息等在程序内做缓存处理。

调整原因：

近日发现业务数据库执行的SQL句中，图片的信息每分钟要查询数据库2000多次甚至更多，这样频繁的去查数据库会给数据库造成很大的压力，如果做了缓存处理之后就不会对数据查询那么频繁了，如果有条件的话可以配置一个高速缓存服务器（但目前还不知道如何操作）

5、 CSS、JS、图片缓存问题：

具体操作如下：

每次图片、CSS、JS有调整后上传覆盖后，将页面内这些文件后面增加版本号，例如一个图片名称为test.jpg的图片被覆盖后在页面上这个图片后面增加版本号：test.jpg?v=1000，CSS、JS同理。

调整原因：

因为有的时候客户在一天内频繁替换一张图片，而替换后由于CDN缓存问题导致图片一直维持原来的状态，无法变为替换后的图片，这样做的是为了告诉CDN服务器这个图片有改变了，需要CDN重新读取，而不是读取缓存，增加版本号后图片马上就会变为新替换的图片。

6、 CSS、JS压缩问题：

具体操作如下：

利用程序，将页面内所有JS合并为1个JS并进行压缩，CSS同理。

调整原因：

这样做的好处是减少浏览器解析JS及CSS的次数，增加解析速度，使得网站访问速度变快；

7、 根据雅虎军规对网站访问速度进行优化（雅虎军规详见附件）：

具体操作如下：

根据第三方网站（http://gtmetrix.com）及火狐的组件（Yslow）的提示对网站内不足的地方进行逐一优化，另网站内需要制作图片延时加载。

调整原因：

LifeVC网站未优化之前网站打开速度为22.68秒，优化之后：8.78秒；

8、 订单跟踪：

订单从生成到完结，没一步不要有日志，每个状态的转换都必须要有日志跟着，否则订单一旦出错，都不知道是什么人做了操作，查都不知道在哪里查。

       调整原因：

有些时候会出现一些异常订单，因为没有日志，导致不知道这个订单是怎么变成这样的。

9、 接口方面：

所有跟第三方的接口，接收与发送数据都要记录原始档案，接收到的什么就存什么。

调整原因：

运营期间，如果出现了错误，我们可以直接拿出原始档，与第三方公司理论，不然我们只能吃哑巴亏。

关于未来网站访问速度及后台查询速度的优化建议