随着问问题的同学越来越多，公众号内部私信回答问题已经很困难了，所以建立了一个群，关于各种数据库的问题都可以，目前主要是 POSTGRESQL, MYSQL ,MONGODB ,POLARDB ,REDIS 等，期待你的加入，另外针对云的问题，我们可以多多交流互相学习
————————————————————————
正文
之前和某个同仁探讨问题，得知某金融类的大型xx,在转型上云，并且在上云后，第一件事情就是解雇了几个DBA ，美其名曰，体现上云后的成本节约。
听完是又好笑又好X，那本期就来说说，数据库上云后会遇到的那些事情，让那些成本节约的 BIG POTATO 了解一下他们节约成本之后，可能会发生的一些有意思的事情。
(写在前面，任何方式方法都有他的利弊，在说有意思的事情的同时，我们也应该思考，云，云数据库给我们带来的变革，以及我们怎么更专业的拥抱云数据库，更加有效的使用云数据库，提高自我水平，才是更主要，一味的指着并不能提高自己。)
1 硬件配置让你下降头
说到这个问题，那我们是非常有发言权的，你在裸金属上的数据库做的所有的优化基于数据库参数的和性能的优化，在你数据库上云后，统统的打回原形，为什么，因为你的硬件变化了，明明之前你的裸金属 4C 16 G SSD 能完成的任务，到了云上哪就不大好说了，可能你的进行测试，测试，在测试，基于我们的经验，一个系统上云后，一般都会性能低于裸金属，当然这是很正常的事情，从CPU 内存 磁盘紧密的通过物理的电路方式连接， 而到了云上，通过网络的方式来进行连接，那么延迟是必然的，所以云数据库最高的要求，或者目前云厂商一直在想达到的性能，就是和你本地机一样的性能，这也是云厂商本身硬件架构调整后，在成本，服务，和性能三者间的博弈。
基于以上问题提高配置来让你的数据库在云上运行，一般是必然的，不是偶然的。
2 各种消费陷阱 割韭菜和服务 “喽“
现在各个云的价格都偏低，（实际上也不低），而怎么去挖掘潜在的money 拿方法是一套一套的。
（写在前面，实际上我个人也认为某些收费的项目是合理的因为使用者层次不同，有些功能可能就是开放了，对有些使用者也不是很优化，集中整合然后售卖，提供双赢的方式也是好事）
方法1 ， 屏蔽+消费
一般来说开源数据库中的一些功能尤其是监控的系统表，都是DB获得数据库核心信息的窗口，那么上云后，如果你还通过窗口来获得数据，那么必然是一件不怎么美好的事情，所以云厂商会通过手段，将你的一些“窗口” 关掉，禁止掉，设置各种障碍来让你变成瞎子， 然后让你通过他们的某些 洞察的功能，在撤去你眼前的障碍物。我们与这个问题，PK 了很长之间，一个一个数据库PK ，有些云的数据库的负责人比较 “良心”，默认持续优化，并且将功能做的越来越完善，好的咱们的说说，就是某云的 PG 数据库，做的是越来越好，功能是越来越多，让用户少花钱，多办事，尤其一些 如index_advisor 的功能引入，和 EDB 的功能看齐，PG 的小伙伴都应该知道我在说什么。
但是还是这个云的 the world of popular database 可就没有这么美好了，能关的参数，那是一个劲的关，设置了重重障碍，让performance_schema 成为一个 “失踪者”。我们费了九牛二虎之力，才打开了一些参数，但后面又玩消失，要不“洞察” 功能卖谁去。同时客服也是有意思，只要问问题，问的深入一点就给你推荐 洞察功能。
方法 2， 不懂技术，就割
一般来说，上云的数据库的甲方，很少有DBA ，有也都让云给忽悠“走了”，然后人家云就可以“动手” 割肉了，配置参数按照“最优” 的配置给你，曾经有一个 MYSQL 业内的人士，在10年前讲了一个笑话，某云，MYSQL 开了32G 的内存，但innodb_buffer_pool 的参数一直是 128MB， 并且那个公司的IT 也没有DBA, 数据库系统经常是瓶颈，问云就是内存不足，在扩充内存，最后扩充到 64G ，然后 innodb_buffer_pool 还是128MB, 最后公司老板扛不住了，请了那个 大仙去看，最后把问题解决了，大仙留下一句话， 没有专业的技术人员盯着你的数据库， 云厂商不 “割死”你那就没有什么天理了。
提高技术壁垒也是相对说，如果你单位有懂行的，能和云厂商相较长短，那么你可能会少吃亏， 知识就是力量，不尊重知识的老板被割肉，这就叫大梨
标签：上云后,功能,DBA,数据库,上云,问题 From： https://blog.51cto.com/u_14150796/6534697