20个MySQL高性能架构设计原则( 二 ) _MySQL

1.14. 为关键组件减负特别是数据库访问,数据库成本最高，扩展性最难，可用性保障最难，恢复难度和时间最大。减负：能不用就不用，使用最简单，成本最低的语句，避免大事务，慎用两阶段事务。
1.15. 建议灰度数据库减少发布时变更数据库对全局的影响,只有应用程序灰度是不够的，还要有专门的灰度数据库。在分库、读写分离架构下，一套含数据库的完整应用架构，变的很自然。所为灰度环境就是生产环境，生产数据，所影响的也是生产环境，只是范围比测试环境更广，更真实。其实就是小范围的生产环境。类似于游戏内测。
1.16. 建立高仿真架构体系

数据库，操作系统升级：应用是否适应，性能会变好，还是变坏
应用上线发布，系统变更（列如换平台），提前判断业务影响和性能瓶颈
应对突发交易量，例如双十一，性能极限在哪里，瓶颈在哪里。

1.17. 容灾保障高可用是运维核心要求，容灾是最后屏障例如双活比单活好，MGR比复制架构好，重要系统要做好高可用，容灾建设。
1.18. 多中心建设冗余是基础，多中心建设是为了提升容灾能力和扩展能力，并保障业务。
1.19. 应用和数据库是一个整体应用和运维人员一起，解决应用解耦，数据库解耦，追账补数，业务监控，应用路由，故障切换等。可用性，效率，故障恢复等方面都要一起参与。
1.20. 性能提升开源数据库使用应该合理且有效的结合周边的其他类型数据库，做到性能最大化。比如：redis，MongoDB，ES，ClickHouse等。
二、总结最适合的架构是结合软件特性和业务场景，又能取得成本收益平衡。大数据情况下可以是利用读写分离，分库分表，但要选择合适的。不适合分库的应该考虑竭尽所能把核心库做小，然后通过垂直扩展来扩容。用尽各种技术，高可用和容灾手段保证其可用。