本文正在参加「金石计划」 大家好呀，我是飘渺！ 我们知道在分库分表中对于toC业务来说，需要选择用户属性如 user_id 作为分片键，不推荐使用order_id这样的作为分片键。 那问题来了，对于订

ShardingSphere-JDBC兼容dynamicDataSource实现多数据源，保证原服务正常运行的前提下新增读写分离功能

分库分表后对数据库的性能提升，用一个字形容，那就是爽！分库分表能让数据存储层真正成为高性能、高可用、高稳定的三高架构，但爽归爽，其带来后患问题也是无穷的，本文则携手诸位详解分库分表后产生的一系列问题！

单日数据暴增几十万、几百万甚至上千万，远超出传统单表的性能极限，此时该如何处理呢？本章会结合真实的线上业务，全面阐述单表数据增长过快的优雅处理方案。

主从复制是一种十分常见的高可用手段，MQ、Redis、ES、ZK、Kafka....任何技术栈基本上都会有对应实现，而MySQL也同样不例外，但数据库的主从复制技术底层是咋实现的？本文将深入探讨！

主从读写分离、双主双写热备这些高可用的代表性名词，相信大家都一定听说过，但这些方案该如何落地呢？本文会带来一套手摸手版超详细的搭建教学~

讲分库分表概念的文章比比皆是，但真正带人落地实践资料相对较少，而本次会基于最新的Sharding-Sphere5.2.1框架，来逐步讲解分库分表的完整性实战~

小阿花：嗯，是的。 小阿花：额，都是 DBA 帮我们搞好的，我们直接用就好了。 小阿花：这个也是 DBA 搞的。 面试官：（微笑）好的，今天就到这里，回去等通知吧。 现在不用再等 DBA 了，自己配置 MySQL 主从，自己做自己的 DBA 吧。 假设各位都已经安装好了 MyS…

大家好，我是小富～ （一）好好的系统，为什么要分库分表？ 本文是《分库分表ShardingSphere5.x原理与实战》系列的第二篇文章，距离上一篇文章已经过去好久了，惭愧惭愧～ 还是不着急实战，咱们