上两周一向设法子提高发芽速度，取得一点效不美观，解决了部门问题，记下来以便未来自己查看。

因为公司没有专门的DBA，我自己对mysql数据库也不是很熟悉，而且这个JAVA开发的收集审计系统的打点系统，是经由了N多人几年时刻的修点改动，今天到我们手里，要改成能撑持年夜流量情形的版本，所以对我们这个只有几小我的JAVA组来说，确实是个难题。

这个年夜流量的情形在以前的文章里也提到过，就是冲要持每秒钟措置1G摆布的收集数据包，HTTP和谈的数据包最多，是以HTTP和谈剖析模块的流水日志表记实最年夜，据估算可能达到一天4000万标识表记标帜录，采用一天一张表，那也是很年夜的，我看了.MYD文件巨细，已经是8G多了。

而我们打点系统发芽日志记势瘫，对好几个字段都要进行前提发芽，而且有几个字段长度达到256，在8G这么年夜的内外发芽一个字符串，如不美观找不到，那必定年夜头要查到尾，速度慢得根柢受不了。客户还要好几个字段一路设置前提来发芽，这样根基上是二三十分钟都出不来，系统可用性极差。

我采用的体例是以测试为主，同时看JAVA代码，经由过程Log4j和Perf4j日志，看每个sql语句使用的时刻，寻找机能瓶颈，然后有的放矢地进行优化。

对发芽最有用不美观的优化，自然是成立索引了，ID自然是自增、主键，这个前人已经做了；年夜where语句剖析，时刻字段作为发芽前提良多，时刻是8字节，而且不一再，设置索引斗劲适合。我把时刻设置为索引，有一点效不美观，但不年夜，估算一下：8 * 4000 0000 = 320 000 000 字节，4000万记实的表仅仅时刻一个字段的索引将是320M，这还仅仅是我们上百张表的一张表而已（客户要求我们至少保留3个月记实）。

成立索引能起到必然浸染，但仍是解决不了我们的问题。物理表成立不能再缩短时刻了，因为一天一张表，3个月就91~92张表，30个和谈模块就得2700多，这仅仅是和谈流水日志表，还有其它表呢。

也不能把客户要求做成前提的字段都设置成索引，那索引表将和原表差不多年夜，索引就失踪去意义了。在数据库自己上优化，想去想来其实一会儿想不到好法子，感受数据量年夜了，就算在Oracle上也没有什么神奇法子吧。

我最后采用分段发芽的体例，就是4000万条数据，我不管你设置什么前提来发芽，我都是平均划为成N段来发芽，好比400万为一段，在页面上供给一个下拉单：0~400万，400~800万，…，3600~4000万，虽然发芽斗劲麻烦一点，但每段发芽的速度年夜年夜提高，节制在30秒摆布，牺牲一些可用性，总比30分钟还查不出来好吧。

流水日志可以采用分段发芽解决，但客户要求的各类统计呢，这不能说分段统计，别人要统计2天的，你分隔是不行的。

以前已经采用了一次预统计，预先按时在后台对流水日志表进行统计一次，保留到预统计表，等用户来发芽时，年夜预统计表进行各类发芽—-这个做法好，不得不夸下前任开发人员。

但此刻形势分歧了，因为预统计表是采用一个月一张的，就此刻流水日志表的规模，那预统计表可能一张表跨越4000万，具体看客户收集数据的分布情形，欠好估量。

最后我和同事们对统计模式具体剖析，一个同事提出再在预统计表基本长进行二次预统计，我们估算了一下，根基上等用户来发芽时，所面临的表已经很小了，最多几千标识表记标帜录，很快了。

解决统计发芽过程中，让我体味到具体剖析营业流程细节，作出响应的优化，有时是可以解决问题的。

总体上来说，对数据库发芽的优化，我们采纳了一些常规的优化之后，如不美观还没有取得想要的效不美观，我们有时辰不必硬碰硬饶暌古化发芽自己，改变一下使用模式，找找营业措置流程是否还有可改削的，说不定就轻松解决了存在的难题。

还有就是主管要把整个开发组积极性调动起来，巨匠一路测试、剖析、设法子、验证，最后一致确定一个可行的方案，然后巨匠分头去不打折扣的实现。

来历：liangbing 的博客

注：相关网站培植技巧阅读请移步到建站教程频道。