数据库管理298期 2025-03-03
数据库管理-第298期 数据量VS语句复杂度（20250303）
作者：胖头鱼的鱼缸（尹海文） Oracle ACE Pro: Database PostgreSQL ACE Partner 10年数据库行业经验 拥有OCM 11g/12c/19c、MySQL 8.0 OCP、Exadata、CDP等认证 墨天轮MVP，ITPUB认证专家 圈内拥有“总监”称号，非著名社恐（社交恐怖分子） 公众号：胖头鱼的鱼缸 CSDN：胖头鱼的鱼缸（尹海文） 墨天轮：胖头鱼的鱼缸 ITPUB：yhw1809。 除授权转载并标明出处外，均为“非法”抄袭复制
最近遇到了一些纠结的事情，就是针对一个业务系统的数据库来说，以不考虑中小系统的一种极端的方式进行比较的话，是单纯数据量大而业务相对单一的数据库还是数据量一般而业务逻辑（语句）复杂的数据库的维护难度大。
1 数据量大
一般来说我们所说的核心业务，比如银行的借记卡、运营商的计费等就是业务相对单一但数据量非常大的业务，其业务主要是针对单行点查的修改和数据新增。
数据量大带来的最直观的问题就是需要更多磁盘，不管是HDD的瓷碟还是SSD的闪存颗粒，我们在获取数据的时候都需要从更多的存储介质中去筛选，这势必增加IO的压力，这里即包含IO的带宽还有IOPS能力。即便大多数数据库都有缓存机制，会根据LRU机制将尽可能多的常用数据缓存到内存之中以减少IO压力。虽然内存的容量是远不及存储容量的，但是这类业务对应数据库一般也有一个特点，就是热数据相对较少，历史数据较多甚至是海量，而历史数据往往不会在同一个数据库中进行分析，会同步到其他系统重进行相关分析操作，当然分析的即时性肯定不佳。
这类系统看重的是数据库海量并发情况下入库与更新的时效性，以及数据库的稳定性。
2 业务复杂
简单来说，另一类系统的场景主要是相对没那么高的总数据量和数据变更压力，但是几乎所有的查询都需要涉及较多的内容（简单来说就是多表关联），这时候你就会发现这类系统的热数据也真是不少啊，而且随着业务的发展对于查询结果的时效性也越来越高，在优化业务逻辑和好好写好SQL不大可能实现的前提下，主要的压力就给到了数据库的优化器，怎样选择最佳的路径最高效的获取数据，这中间还要考虑索引、统计信息、hint、存储等各方面原因。一般来说这类系统每次出结果往往并不是靠一条语句就能实现的，特别涉及流程类操作，会有一系列复杂语句需要执行，同时根据不同的上下文关系，相同流程不同的过程状态还可能对应不同的语句。
这类系统就是需要处理复杂语句还需要考虑多语句可变长流程。
3 短停一下
两种业务系统在我看来：
- 一个需要的是极致的快与稳：这里需要相对极致的业务设计能力与语句优化能力，对数据库包含其配置、高可用和硬件选择都需要进行巨大的投入，除了确保每条语句用最短时间完成，还要确保其运行效率的稳定无波动，还需要做到几乎任何故障不会影响业务响应
- 另一个更考验综合实力：因为业务逻辑的复杂度，既要考虑单次复杂语句的执行效率，还要考虑流程类语句执行对整体的影响，因为数据交互多，还要考虑所有语句执行的互相影响
那么到底那种系统的数据库维护更难，二者各有各的特点，而且从很多地方业务的发展来看，核心系统的正常运行也需要辅助系统的支撑，所以二者从一些传统的核心与否来判断维护难易度没有参考意义，对应起来数据量亦是如此（毕竟如果真要算数据量，其实数据量最大的大多在后分析系统和历史库中，扯远了）。
感觉说了一堆废话，我想表达的是，都是做数据库维护的，除了场景不同，没啥高下之分。
4 HTAP
又扯到HTAP了，但我只是想在小节题目上用一下。看似HTAP可以将上面两种系统合一，还能有效减少数据冗余、降低数据传输压力、提升数据关联利用效率等，但是对于所有业务系统来说，良好的业务逻辑设计、数据库设计与语句书写比任何事后优化效果都好，要用好数据库的HTAP需要更高的能力做好这些事，对后期维护的要求也不会低。
总结
有的只是场景的不同，没有维护难度的高下。
老规矩，不知道写了些啥。
