由于微服务技术发展迅猛，在我们的架构中，每个微服务都会相应的对接一个数据库，各个数据库之间有关联的表(比如用户表、业务表等)会互相同步数据，其他的数据操作各自独立(如日志表、操作表等)，这么设计是基于性能考虑降低数据库容量及尽最大努力避免性能遭遇瓶颈。这么设计对于container来说确实是极友好的，在日常运维中，比如每月/季度的数据汇总就难受了，身为DBA，处理跨表查询应该是小case，然而在hibernate跨表查询中，虽然麻烦但还是啃一下还是可以解决的。然而最近接到的需求却是要，跨！库！联！查！
我在想微服务的背景下，跨库查询应该是新常态单库时，系统中很多列表和详情页所需数据可以简单通过SQL join关联表查询；然而多库情况下，数据可能分布在不同的节点/实例上，不能跨库使用join，此时join带来的开发云主机域名问题就很棘手了。我们在开发过程中，连接数据库一个连接也是只能连一个数据库这个是常规操作，例如如果我们要查询另一个数据库呢？不就要，再建立一个连接嘛这个怎么可能用join操作，可能有读者想要杠一下，说，可以通过xx操作在代码层面进行开发，但是，这样的代码可读性有多强？另外就代码审查来说，也不会让你这么写，万一某一天你甩锅离职了，这天花乱坠的代码，谁受得了？
不过嘛，办法总比困难多的——视图。利用视图，我们可以非常简单的实现这样的跨库查询的需求。我们知道所谓视图，其实就是存储的查询语句，当调用的时候，产生结果集，视图充当的是虚拟表的角色。因此：一开始我也是被我这个想法惊讶到了，总觉得跨库建视图太过于惊悚了，毕竟实践是检验真理的唯一标准嘛，随手就在navicat上面建立一个视图，之后运行非常神奇~~那问题这样就解决啦，还是一条SQL语句就可以解决问题了通过这个思路，其实可以继续推广：跨表联查，建个视图，跨库联查，建个视图。建就完事了。另外这个操作其实还需要考虑数据同步的问题，因为是多库联查，如果数据不一致会是灾难的，这个具体问题要具体分析，加锁或者配置同步策略这些都是常规方案，由于我没有这个需求，就不展开讨论啦。这个案例对我来说很有感触
重点：配置GNR时需要所有的GNR以[ mysqld xxx]的格式命名，否则会报找到GNR的错误 准备Mysqld_multi配置文件加入多实例的配置信息 指定GNR启动实例(不要指定MYSQLD这个关键词) mysqld_multi start 3308 …
免责声明：本站发布的图片视频文字，以转载和分享为主，文章观点不代表本站立场，本站不承担相关法律责任；如果涉及侵权请联系邮箱：360163164@qq.com举报，并提供相关证据，经查实将立刻删除涉嫌侵权内容。
微信扫一扫 
