临时工说：数据库技术是一把刀，用不好容易伤到自己

开头还是介绍一下群，如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, Oceanbase, Sql Server等有问题，有需求都可以加群群内，可以解决你的问题。加群请微信联系 liuaustin3 ，（共1970人左右 1 + 2 + 3 + 4 +5） 4群（430+ 关闭自由申请,新入群的将默认分配达到5群）,另欢迎 OpenGauss 的技术人员加入。

新的一年又开始，希望在你怎么都搜不到的这首歌开始唤起大家继续生活的勇气，从10多天的自由中又被唤回到现实中，在成长的道路中从来就没有先后老幼，大多没有人自发的想去成长，成长都是受到了外界的影响，逼不得已能让人成长的东西大多都是让你有反思的，不大愉悦的，翻翻过去记忆里面的照片，对于曾经的痛苦和伤疤可以一笑了之或淡然处置，如同在你经历一次次的成长和蜕变后，你依然还可以是一个少年，奔向现实的麦田继续成长，希望这一路还有你们的陪伴，2024！！

——————————————————————————————

开工了

数据库里面的技术是越来越多，越来越卷，DBA使用新技术解决问题是好的，这里面存在一些问题，没明白原理滥用，自以为是胡用，不考虑前后因果用完出问题在说，不懂业务的需求用技术的思维去导向，反过来业务把你的技术方案推翻，更差劲的是用了一段时间，导致业务无法快速灵活相应市场的需求，最终被DISS称为一个失败的案例。

这样的情况可以举一些案例来讲讲

问题 1 ， 数据库版本上新，他就敢用

这个问题一般出现在NEW DBA的头上，年轻人心气足什么都要最新的，但最新的不等同于最优秀的，甚至最新的= 坑，问题，BUG，大BUG 的代名词，可惜有些人就是愿意成为这些新数据库版本的试金石，比如MYSQL8.029 ，比如 POSTGRESQL 14.2 ，这些人都是奇葩，数据库是业务的基石，这样的DBA 可是说在这个工作岗位上，并不与职位匹配。

问题 2，  滥用分区表

分区表虽然不是什么新的技术，但分区表在数据库中被滥用是一个常见的事情，有些DBA是好心，希望数据库的性能优化，在优化。可他忘记了一个根本，数据库的技术在辅助你提高数据库性能的基础上，这些技术是否造成一定对于业务开发，业务发展的束缚和绊脚石，这点在初级的DBA心里基本是没有这个谱的，什么都想试试，什么都想干干，什么都想，哎。

首先分区表你的想这样一个问题，分区的意义是什么，我听到的最大的回复是，这样对于性能好。基于这样的回复我也有几个问题

你使用的分区表的技术对应业务属性是什么， 什么是业务属性，你的表是业务核心表，历史表，或是日志表，你首先要明确你的分区表到底对应的业务是什么 ，比如是历史表，OK 你那么大概率你分区对应的方向就是，日期类型的核心关键字，你分区的表也都是按照日期类型顺序存储的。  

如果你是核心业务的表，则分区难度大大加大，你需要明确一点你分区的实际意义，与架构在对于核心业务表的访问， 大数据部分对于数据的重新汇总，以及即席OLAP 是否会将你万全的分区表的方案，彻底的摧毁。

在从业经历时间越长，我越害怕数据库技术将业务的特性绑定，所以在你对业务核心表进行分区的情况下，你必须以更高的维度去审视分区表给除了数据库以外带来的问题。

问题 3  只针对数据库技术说事，忘记数据库需要上下游连接

这个问题在DBA的工作里面也是重灾区，比如逻辑PG的逻辑复制槽，他有这个技术，但是否应该使用这个技术，你不能单纯的说 YES OR NO，你需要评判你的工作环境中，到底适不适合用这个技术。

那么我们出一个问题来看看

问题：PG中在如下的环境中，应该使用逻辑复制槽

A  在一个没有DBA并且没有人懂PG得工作环境下

B  在一个主机磁盘空间不能及时扩展的硬件环境下

C  在一个经常有大量数据更新，并且网络带宽无法稳定的环境下

D  在一个经常添加表，修改表结构的环境下

E   在一个稳定的带宽，数据流平稳，并且添加新表不频繁的环境下，同时没有太多突发数据流的环境下

答案非常明显，E 可惜实际情况下，很多同学在使用PG中，根本不考虑你的A B C D 的情况，反正 PG 有复制槽的功能我就用，这就是对DBA 这个职业最大的羞辱。因为你脑子里面没有判断，只有技术，那只会害死你。

问题 4  DBA 唯我独尊，数据库技术当道

这样的DBA 也不少，并且很多事干了几年的，DBA 他是一个职业，但他不是限制你获取其他知识的壁垒，数据库作为承接数据的基础，他负担了太多的东西，上层软件开发架构，开发的模式，业务的属性，以及下游对于数据的治理和管理，这些统统都和你的数据库有关，你难道能独善其身。

这里在举一个例子，群里有一个同学问 TBASE的IDLE 链接太多了怎么办，我当时就火了，没好脾气的说了一顿，这就是一个只考虑自己，只以自己数据库技术为圆心的思维方式的典范。

1  数据库出现IDEL 链接的是正常的还是不正常的，这需要考虑

1.1 应用开发在JAVA 连接池中设置的最小的保留链接数是多少

1.2 数据库中设置的IDLE 链接的过期时间是多少

1.3  应用程序开发在连接池设计中，有没有回收链接的配置

1.4 应用的连接池是否有复用的设置

你至少应该问着三个问题，然后你在去想你的数据库中 IDEL数字是否太多，是否影响你的数据库的内存的分配和系统响应的速度，最后你再是去找寻你的TBASE 在idle timeout 配置中的具体设置的值是多少，在你和开发架构对接后，在进行调整。

而不是问，TBASE数据库中有这么多IDEL 链接正常不正常，TBASE 正常不正常倒是其次，这个同学你还有很大的进步空间，这点我是肯定的。

DBA的脑子，他就是一个杂货铺，在当下想更好的生存，你要多元化的吸收知识，尽量给自己铺设更广泛的生存空间，上面的唯我独尊，自我感觉良好，只会害了你，是现在有AI，有云，但是DBA的工作经验和知识，这些想要拿走很难，每个人面对的公司，技术的平台都不一样，DBA的工作如果只有技术，那会被淘汰，但DBA的工作里面有业务，有架构，有数据库技术，有人情世故，有对这个职业的一份情感，AI 想淘汰DBA ，还早呢，DBA 须把自己打造成一个综合体，全面发展，才能免受历史车轮过早的碾压。