今天说的要有点争议了，我个人认为不一定是金融领域。数据库最难的一定是金融级，但是场景严苛和替换难未必是一回事
数据库最严苛的是金融领域
- 金融场景最严苛是毋庸置疑的。不能错，不能丢，不能慢。人行监管下同城双活都是最低要求。两地三中心，三地五中心都有。
- 金融用的人也多，所以业务量大，几乎都是7X24小时的。
- 在这种场景下单机数据库可能受到一定挑战。大型机、小型机、以及exadata这样的硬件结合数据库自身的高可用还是能应对的。
- 而OceanBase、TiDB等这类分布式数据库也能支持。这里的原因我个人今天的观点还是：金融场景的需求也相对严谨，设计也相对规范，应用程序质量也相对高。
- 因为我不认为几万行多表（十表乃至几十张表的关联）SQL在分布式数据库上能很好的并发运行。而这类SQL在金融场景几乎不存在，如果存在也不是核心功能，不在主流程上。这是从数据库理论的角度说的。
运营商都是高负荷大并发的领域
- 运营商的数据无疑也是和金融类似。同样能拿下金融场景的，那么在运营商这里也有可能。
- 不过我接触过一些第三方服务商的朋友帮助国产数据库厂商进行替换，就发现运营商的SQL写的不好，在国产数据库中遇到执行不动的情况。
- 当然这朋友在看了我提供的样例一样，马上就治愈了自己的焦虑。相比较而言，他经历的SQL已经算是好的了。然后安慰我说：哥，你这种SQL怎么上国产啊？
- 我这些年收集过很多SQL，各行各业、各种不同公司的。一句话概括，没有最差，只有更差。运营商的应用程序相对而言算是好的了。
互联网公司也是高负荷大并发的领域
- 互联网公司的符合和压力比运营商和金融都高，但是没说不能丢，也没说不能错。朋友圈丢一条数据，微博发重复了有关系吗？没有。
- 但是互联网公司的应用程序质量应该是最高的。因为低水平的开发者可能面试都不通过。
- 互联网场景的业务通常不复杂，或者说不是很复杂。OceanBase 、Polardb、TDSQL这些支持阿里腾讯业务这么成熟的自家产品，拿出来以后也不是说把原来系统的数据导进来就能用了。如果这样就能做了，那数据库替换早就完成了。是个逻辑吧。
传统行业没有大并发但是可能有高负荷
- 非以上行业你看着业务没有每天几千万的交易，但是系统负荷未必就比那些系统小。
- 原因主要还是SQL质量不行
- 原因很多：SQL复杂、读取大量数据
- 我们以前总说大厂的应用开发人员做了90%以上的逻辑（简单逻辑）在应用中，数据库只做简单场景。而传统行业几乎所有逻辑在数据库实现。巨大的鸿沟就是应用适配。
- 不过我最近在想一个问题，复杂SQL的原因--需求复杂--设计复杂--场景复杂。传统行业的业务业务场景逻辑是互联网行业场景难以理解的。有些不是在应用侧他就能解决的，我自认为我是坚定的反对复杂SQL的人。我觉得很多优雅的设计下，我实现需求即使用大家鄙视的存储过程，我都不会超过10行。但是我遇到很多业务场景下，我就是无法用简单的SQL实现。这里有数据库设计的问题，但是即使有些我设计好的情况下，业务偏离了当初的设计，然后这个就控制的不太好了。有些场景也是不断突破我们常人的底线。
所以我结论是传统行业的领域其实最难替换
- 原因很大程度上是SQL写的不好
- 而这种不好很大程度是使业务场景复杂不断叠加扩大的
- 可能一个全库TB级别的数据库，一天的逻辑读和物理读能超过100TB
- 最后一个实际的问题就是传统企业没有金融企业的钱，可以买大量的硬件