上次说到的场景7和8都还是有意识要关联的。但是也有直接select * from a,b 后面什么都不带的，虽然执行时间一样慢，但是输出效果和意识不一样。这种真的应该拉出去打一顿。我真的见到过这种引起故障。相比较来说，数据库安全出问题（极少，不是没有），硬件故障（更加少，当今硬件技术起步就很高）。而这种SQL引起的不稳定因素几乎天天有，而且不止一次。从管理学的二八定律来说，精力倾斜应该放在哪里呢？
说到这里有时候又来了一些不明真相的质疑。多方质疑数据库。（这里的数据库是指核心交易数据库OLTP）
质疑1：数据库也不行嘛。一个SQL就能把数据库搞死。是的。有的时候真的一句话就可以搞宕机。因为如果执行了读几个TB甚至几百个TB的数据，数据库要发出指令CPU和IO全部调动起来，至于要花多久那不好说了。可能几个小时，也可能几个星期。这个过程中整个计算机几乎已经是无响应状态了。数据库底层是物理学和数学。如果做出了违反这两门基础科学的常识，那么不是数据库的问题。是常识问题。
质疑2：数据库也不行嘛。这个不让做，那么不允许。任何产品都有使用说明书，这些就是使用规范。比如手机说明书中就说不要放到火里面。同样SQL也有规范，这种规范不仅仅是如何写，还有如何写的好。据说Oracle官方的这个文档2500页。我是没见过，我也是听说的。
质疑3：数据库也不行嘛。删除一个文件就起不来了？这点上可以理解为在windows的system32中删除一个文件（如果可以删除的话），重启一下windows也起不来一样的道理。就像人一样少了一个重要器官可能也活不了了。之所以数据库起不来是因为日志文件、数据库文件、控制文件等所有文件的检查点要一致，如果不一致就是问题，为了防止在错误道路上越走越远，所以不能继续工作。先解决问题。
一个表上的id1存在A文件上，本来和另外一个表的id1存在B文件上关联的。现在B文件被删除了。整个逻辑都不对了，怎么继续走下去呢？
质疑4：数据库也不行嘛。不能随时扩展。不是不能扩展，是不太好扩展。因为CAP的一致性原理。在P的前提下，C和A只能满足一个。在这个理论模型没有突破之前，一致性就是限制扩展的。NoSQL没有强一致性所以NoSQL不会作为核心交易系统的数据库。当然现在通过一主多从，以及Oracle RAC等架构是可以扩展的。因为大家系统的负荷主要来自于读，极个别比如阿里双11的数据库读写都是会迎来高峰的。
质疑5：数据库也不行嘛。这点并发就不行了？你看看别人双11.是的。人家双11用的是什么硬件，中小企业用的是什么硬件？这是大厂的硬实力。大厂的开发可以把程序做到极致，百度春晚的开发甚至在2个字节上看看能不能优化成1个字节。支付宝和微信，把业务逻辑做到了极简。大厂又有很好的规范，禁止犯低级错误。比如不会并发出报表，余额不是把微信10年的收支sum一下得出。这些都支持高并发的软实力。
质疑6：数据库也不行嘛。就不能跳过这个错误继续吗？问题是真的不行啊。我账户有10元钱，别人转给我1000元。现在有1010元。本来我买一个300元的东西是可以的。但是由于异常这个1000的日志丢了。没传过来或者由于故障跳过去了，最终没有应用到数据库日志中去，最后账户就还是10元，这个买300的就买不了。逻辑上和实际不符。再比如说双向复制。不过用什么CDC工具都要面对这个问题。 我们假设 AB两个中心。有业务要使用A的数据（比如是信用卡）您在上海刷卡。您夫人用你的副卡在北京出差刷卡。其实是一个卡，一个额度。你连接A 她连接B 。你说这两个同时刷卡（非常极端，当然数据库断电也是极端不是嘛。就是钻牛角尖，极端） 好，这个时候你说两个数据库怎么保证不突破额度？可以随便跳过吗？ 其实如果说数据不重要可以跳过，那么其实这个系统好像也不重要。反之如果数据一丁点也不能容忍错误，那么这个系统应该是比较重要的。比如金融、支付、证券。这些都不是儿戏，关系到社会民生。
以前做公安系统面对警方要求的需求，我们会尽力怼回去。尽管市场、销售找领导压我们，也不做。因为反科学。最终甲方都能接受我专业的说法，最终放弃了不合理的想法。其实遇到不懂技术的，真的是把脆弱的生命往墙上撞。数据库基于数学和物理学。违反自然科学的事情，不是数据库做不到，是现阶段科学技术达不到。
