ITPub博客

数据层透明扩展最困难的部分join操作，被我克服。第一个真正做到客户不要动手，通过yougeProxy，直接完成MySQL数据层的水平扩展。后期就是实现问题了。

OneProxy优点性能缺点闭源，被商业公司掌控，到时候随别人蹂躏可维护性极差，缺乏友好的出错信息，光维护这个环节就被他人掌控定价不明有没有这样的公司？大到10wtps，但是没人能理解MyCat的，或者不能fixMyCat代码的。我认为没有，所以gameover。

其节短：从露出迹象到实际行动时间一定要很短，否则别人知道你要出什么招，就会有所防备。其势险：出招是因为一定能击中，这不是事后猜测，而是目前的状态对比，我必然能赢。

写着写着就感觉变味了，主要是心态变了。当初写博客有两个目的，其一，锻炼自己的写作能力，其二是为了梳理自己的知识结构。最近的写的几篇文章，有的阅读量破千了，我的心里也开始被这些数字牵动了。80、120、140、170，到今天的180。现在我每天都要打开博客十几次，看看阅读量是不是有爆发性的增长，美其名

很多药方，只要吃不死，总有一款适合你。哈哈。我要做西医，先检查身体，再了解每种药的作用，做到对症下药。

通过以下关键字分库分表，读写分离，连接池，跨库查询，开源数据库，MySQL，高性能，并行查询在搜索引擎中，都找不到OneProxy和OneSQL的影子

一、十亿数据，轻松秒出实时监控领域有两个显著的特点，一是数据来源很多而且数据量大，有来自监控摄像头、GPS、智能设备等；二是需要实时处理。我们的客户在做实时处理时，就遇到这样的问题。客户的某个数据表中有10亿条记录，希望统计类查询的响应时间在30s以内，而使用单台MySQL的响应时间在300s以上。

因为Proxy类的中间件不适合实现preparedstatement，所以无法测试，导致我们无法使用标准的测试工具去发布OneProxy的测试结果

虽然我知道我的技术是下三滥，但是也不能一下子就炉火纯青啊。急不得，只能尽我所能，把自己的疑问搞透了。

今天意识到需要建立一个以我为核心的客户关系网，否则最核心的环节无法打通

从先辈的产品中抄。从抄先辈的先辈的产品中抄。从后辈的产品中抄。当你发现你的领导有个好的idea时，那一定是又找到一个新的抄点了。

今天把spockproxy编译通过并且运行了。大家如果在编译这款类似于MySQLproxy的软件遇到问题时，可以联系我。微信onesoft007

都快30的人了，还整天担惊受怕老板对你的看法,这辈子就这点出息了。做自己的事情。

才算明白曲高和寡的真正意思了

在大量的客户端，更新数据表的同一行时，会造成数据库的吞吐量大幅降低。很多数据库的前辈和同行分别通过实验和源码的方法，定位到了罪魁祸首----MySQL死锁检测实验方式：http://blog.csdn.net/zhaiwx1987/article/details/6952285源码方式：http:/

OneProxy为了实现拆库拆表，必须有能力管理多个主从集群。启动脚本截取如下：#################################################--proxy-master-addresses=172.30.12.9:3306@data1\--proxy-maste

OneProxy具有主从延迟检测功能，检测方式有两种。1、通过MySQL本身提供的延迟信息，即在从库中执行showslavestatus;查看Seconds_Behind_Master值；2、通过更新一个特定的表的时间戳来判断，类似pt-toolkits中的pt-heartbeat。第一种配置方法为

按照我的作风，没图说个啥环境下面是受叶金荣老师的启发把相关环境交代清楚MySQL和OneSQL的关键参数配置如下数据库sync_binloginnodb_flush_log_at_trx_commitinnodb_log_file_sizeinnodb_buffer_pool_sizeOneSQL0

短时间出大量文字，怎么办？只有抄了。今天我就在抄，以此为凭证。

不把文档写好吧，别人不会用，自然推广不开；把文档写好吧，别人用了，不需要你的支持，就拿不到钱了。看来只能加入注册码了。