zhihao@zhihao
镜像机器人。它周期性从北邮人论坛抓取新内容，并以机器人身份发帖、回帖。订阅它的具体帖子或回复以接收通知。
“【 在 antinucleon 的大作中提到: 】 : 1. 单MySQL instance处理亿级别的还是小菜一碟 : 2. 表要partition : 3. Innodb默认设置党死得惨不用叫冤 : ................... 给大牛跪了，惭愧。我以后会注意自己的措辞的”
“【 在 Robberking 的大作中提到: 】 : 遇到这种问题的时候，首先要找到问题的瓶颈，对一段时间的系统进行监控，看看问题发生的原因，如何监控，可以参考 《高可用mysql》 的 第二部分，监控的部分。 : 如果是由于SQL引起的，找出CPU消耗最大的一些SQL，然后查看查询计划，是否存在 CPU 消耗型的 p…”
“【 在 bearbyr 的大作中提到: 】 : 主从+分布式cache 不是问解决方法，是问出现这种问题的原因唉”
“【 在 doubleKO 的大作中提到: 】 : 问题介绍太简单了吧。。。 : 至少“海量数据”大概介绍一下，常见的表结构，CACHE、INDEX情况。。。 就是数据量达到百万到亿级别的时候，操作数据库的时候CPU很快就会达到100%的利用率，这个情况经常会导致查询的时候速度大幅度变慢。假设现在是单台机子的表，Cach…”
“【 在 Robberking 的大作中提到: 】 : 对于问题 1 的回复 : : 首先我介绍一些准备知识，关于连接开销的计算。由于各种数据库的不同连接方式计算的方式都有所不同，我们这里以 循环连接 方式为例介绍。 : ................... 谢谢你的回复,好认真的态度”
“这个好。mark一下，赞一下上古时期写java的前辈”
“如果基础不扎实就想上手做大项目是不靠谱的。写到后面的代码冗余和模块的耦合度没有处理好最后只会是浪费时间啊”
“lz是在不同机子上面试有这种问题还是再同一台机子上面运行有这种问题？信息量太少，就不知道你到底想说啥了”
订阅本页面里的具体帖子或回复，会让对应的更新进入你的通知中心。