经常看我公众号的朋友知道，我一直说单机数据库是最好的架构（这里单机不是说就一个机器，而是一套高可用的架构。支持节点切换，保证数据不丢失的）。分布式数据库也是的，因为它是一套。
所以我一直说数据决定架构。单套最怕的是什么？因为是一套了不用过度担心硬件了（其实都2022年了，谁家的机器天天坏）。（断网断电不考虑）除此之外最怕的，也是唯一怕的就是杀手级的SQL。往往一个SQL可以让一个数据库轰然倒地。
我这么多年从事了也不少行业和公司。挽救了不少系统，所以也积累了可以杀死系统的方法。只要不按照规范来，一定会出事。就是早晚而已。所以很多数据库都为了防止这种节操碎了一地的SQL，推出了自己的解决方案。都采用机器学习等方式将杀手的SQL直接摁在地上，装载盒子中。比如Oracle19C 用一体机实现。Polardb 、OceanBase、TDSQL我还没查到怎么实现，可能是我资料有限。
所谓再牛逼的香水也干不过韭菜盒子。没有条件的怎么办呢？其实有两种方法：
方案1：严控开发质量。代价是开发需要提升水平。收益是数据库规模基本不变，成本可控。通常选择这种路线的不少，比如互联网公司、金融行业、运营商等。对数据非常敬畏而且系统就是公司的生命。
方案2：低成本开发高成本运维。代价是分库分表、机器增加、数据汇聚、数据同步、异构数据库、消息队列、大数据、流式计算。。。。。。。才疏学浅后面写不下去了，可能还有很多没考虑到或者没马上想到的。乍一看，方案2好像架构高大上了啊。可以出去吹牛了。也有不少选择这个方案的。
就一个分库分表其实就足以让开发和运维人员头痛不已，有的时候发现架构层面甚至不一定能解决一致性的问题，即使解决了付出的代价之大和性能衰减是吃惊的。所谓性能不行架构凑。
方案1：对开发来说太low，还要提升能力，招不到开发，也没人愿意来。
方案2：对运维来说太坑，招不到运维，不想填坑。
不管怎么说本期主题的结论出来了，应用写的差，是真的可以改变架构的。但是应用写的好，可以改变架构吗？答案也是肯定的。
