数据库 内 “卷” 在 当时

卷， 内卷，目前社会的现状，每个人都在感受当今社会的内卷，每个人也都在为内卷“添砖加瓦”。换到数据库本身也身在内“卷” 中， 每个从业者都无法逃避，卷，与被卷。

从XC（两个简写是什么意思，我也不大敢说），数据库行业的内卷就开始了，从一个手就可以扒拉干净的从业机构，到上百家机构涌现，当然这是好的，终究会有好的JG从其中涌现出来，来分一分，从ORACLE上掉下的一块块“肉”，也必然形成竞争过度，变成时下的“卷”。

其实有没有人冷静的思考一个问题，到底数据库要做什么，客户需要什么，什么都有，什么都能，各种奇葩的要求都能做到，甚至一些听上去不符合逻辑和理性的需求，都完全肯定，加上各种的QP性的测试，组成了目前“卷”的实质,你能130， 我能170 ，测试的性能和上世纪放卫星一样的高产，实际的FS估计只有鬼知道，数据库的性能在部分数据库上你要多低，就有多低。

YN呆了几个月，从热切的加入，到灰冷的撤出，是在是卷的厉害，不能消受，某些CP就和改装车一样，发动机一样，变速箱一样，加一个贴膜或者换换轮胎的大小就可以称为GH之光。

或许ZB都是都是要逐利，这是一个无法改变的本质，时间上不允许有更多的思考和可能走的弯路，剩下的就是拼劲全力“制造”出来，看上去和众泰保时捷一样的产品以及各种客户提出无法回答的Questions.

 有些问题实质如此，如FBS数据库必然在一定数据量的情况下，无法和DT的数据的性能比拟，2PC方式的提交必然导致事务提交的时延增加，数据访问节点的切换，很可能导致业务访问的中断，系统压力过大加上拿来就用的高可用，必然会引起某些敏感的数据库节点的swithover  over over over. TSO 已经成为业界的FBS标准化，有些问题是“胎”里带，并不是一时半刻可以快速解决和处理了,可惜在卷的时代，哪里让你有时间改正和诉说其中的不易，有的只有魔术性的测试和比拼谁有更好看的戏法。

经过此事，也算受到真切的教训，看上去很美的东西，只可远观不可亵玩，不切实际的CP，会在时间的洗礼下，或快或慢的没有声音，卷到最后，只是卷了个寂寞。

。

谅某些简写，还是 select * from CP where  SQ like "%模糊%" 的比较好，终究就是讲一个“故事”。

以上纯属故事，如有巧合，与我无关