主要观点总结
文章主要讨论了数据库解耦与拆分的问题。随着业务复杂度和数据量的增长，数据库性能下降，扩容变得困难。文章通过实例说明了数据库耦合的问题，并介绍了如何通过服务化和垂直拆分来解除公共数据库与业务数据库的耦合。
关键观点总结
关键观点1: 数据库性能问题
随着业务复杂度和数据量的增长，数据库性能下降，通过增加数据库实例来扩容却不起作用，原因是数据库之间的强关联导致无法解耦。
关键观点2: 数据库耦合问题
文章以一个公共用户数据库和业务数据库的实例，说明了如何通过join实现业务导致的数据耦合问题，以及这种耦合带来的潜在风险。
关键观点3: 解除数据库耦合的方法
文章提出了通过服务化和垂直拆分来解除公共数据库与业务数据库的耦合。服务化将公共数据访问下沉，垂直拆分则针对个性化数据访问进行上浮。
关键观点4: 业务复杂性的影响
对于业务复杂、数据量大、并发量大的架构，解除数据库耦合尤为重要。通过增加机器和实例来实现扩容，提高系统的扩展性。
正文
where table_user.uid = table_A.uid
and table_user.uid = $uid
初期关联查询没有任何问题，单条记录访问，命中索引，一次查询所有数据，简单高效。
如何产生各业务数据耦合？
通过join实现业务，导致通用表table_user和业务表table_A必须存在于一个数据库实例里。
如果业务B也这么做，业务C也这么做，会导致
公用业务，业务A，业务B，业务C都
必须存在于一个数据库实例
里
。
会产生什么潜在问题呢？
假如A业务线上线了一个新功能，不小心进行了全表扫描，导致数据库CPU100%，数据库实例性能下降，由于实例共用，通用业务，业务B和业务C都会受影响。
即某个业务线的数据库性能急剧下降导致所有业务都受影响，这种耦合，历史总是惊人的相似：
1. 业务B的大boss
在群里首先发飙：“
技术都干啥了，怎么系统挂了
”；
2. 业务B的rd
一脸无辜：“
业务A上线了，所以我们挂了
”；
额，然而，这个理由，好像在大boss那解释不通…
