ITPub博客

身边不断裁员的现实告诉我没有那么稳中向好IT部门在日子好过的时候，可能玩的很花。但是日子不好过的时候，首先是被砍的对象。因为成本部门嘛。群里也好，身边也罢。降薪裁员是去年的主旋律，我相信今年也是，明年还是。概念随着寒冬退去这几年几乎没人谈Hadoop了，但是还有大数据。因为Hadoop和大数据不再是等号。微服务的也没有那么热了。中台该拆的也差不多了。区块链的书还有人买吗？元宇宙坟头草也不低了。但是

本文分两部分，前面讲两个练习AI怎么辅助的，后面我讲讲我的观点AI替代不了那么多人关注后面的读者可以忽略前面的。直接看后面。AI替代不了那么多人那段就行。AI辅助编程，但是无法替代开发人员年前我github的朋友请我尝试一下github的copilot。今天尝试了一下。步骤如下：1、先升级自己的vscode。一定要升级到最新。2、升级完成后安装插件。点击红色的扩展插件，搜索copilot。把git

我作为采访嘉宾去采访餐饮行业的标杆企业，食亨的CTO去之前，我天真的以为餐饮行业数据不多，毕竟不是所有餐饮都有信息化的诉求。如果有每家都有自己的，也不会太大。再说还有美团、饿了么这些垄断了很多企业。再说了吃一个鸡腿堡，和吃一次西贝价格虽然不一样，但是就是一个支付记录，应该不多吧。我带着这些问题去采访。事实是超出我意料的首先，食亨只做快餐（就是扫码点单，这种先付费的）这种。不做正餐（比如西贝、外婆家

以下有部分来源于AI，毕竟我认为AI还不能替代，他只能是辅助快速迭代是应用程序不是工程    在这个追求快速迭代、小步快跑的时代，我们似乎总是被 “快” 的节奏裹挟着前进。但当我们静下心来，审视 DeepSeek 的发展、饺子导演创作哪吒系列电影的历程，以及数据库的版本发布，会发现，厚积薄发，往往有着更为震撼人心的力量。两年前chatgpt在春节前后出世，而今年deepseek

起因有人反馈说SR，在系统资源还有空闲的时候，被操作系统杀掉了。没有日志，怀疑是bug，如果要解决这个bug。据说在网上查到要升级。请我准备一下升级。质疑StarRocks是一款分析型数据库，2021年正式开源，虽然起步晚，但是能听过且有不少应用的也不会有非常致命的问题。我觉得如果真的像上面说的，那就是比较严重的问题。但是我不认为这个反馈是对的。现实工作中有太多事情，反馈的和实际的简直相差很大。比

最近生病，每天都去医院输液。所以有好几天没有更新了。前天晚上，呼叫我上线分析问题。当我问及出什么问题时候，给我的是一个报错指向不明确一般来说数据库（不管什么数据库）报错都会有自己的特点。比如Oracle的有Ora开头的，MySQL的有MY开头的。等等所有有时候说连接不上数据库，有数据库报错的，那么是数据库的连接数达到上限了。如果没有通常就是JVM那里的连接池的达到上限了。而今天这个说了几乎和没说一

哪个数据库优秀不一定都能达成一致的意见在1.4日的PG上海生态大会上，我发言大致是：每个人都有自己主观意愿。比如MySQL和PG的争论，无论线上还是线下都是难解难分。主观意愿定了，很难改变。即使心里认，但是嘴上也不说。但是如果说到Oracle几乎所有人，都认为从技术、架构、理念和产品等综合来说是当之无愧的第一。而这也是几乎，不能说100%。只是没有其他数据库那么分裂。拿一个好的能替换一个稍微差一点

注意这里说的是有时候按说故障有因有果，但是有时候吧。处理问题在外人看来像是玄学。事情起因上周有人求助，我远程连上去，瞬间看到/目录就剩下20K的空间了。然后打了几个命令以后变成了0K。这时候的现象是linux的命令补齐都用不了了。这时候就别想着细致的查问题。只能粗浅的查问题了。这个得知主要是是Oracle的数据库软件，那么最大可能是trace目录下。日志增加的可能性。tail命令查看alert的日

迟来的纪念这个迟来有两个意思，一个是12月28日的活动，我当天只发了朋友圈和视频号没有写感想。我是想和1月4日的活动一起写。第二个意思是好多人已经把1.4日的活动写完了。我才开始。所以总之是晚了。作为对照我这里对照的不是两个会议的内容，而是都是我作为全场的主持人，我看看我主持的有没有问题。主持方面也要不断地提升。这其实和数据库一样的道理，看到其他数据库的得失，那么自己的产品应该如何改进呢？一路走来

2024年真的快结束了，可以总结自己的一年过往了。活动方面经过多年的积淀，这几年开始在业内活跃了。尤其是在技术大会、直播等活动中出现。我统计了一下2024年参与了如下活动：（按照时间倒序）2024年12月，2024TiDB上海站主持2024年12月，2024开放原子开发者大会，发表主题演讲《通用数据库SQL优化》2024年12月，华为直播-国产数据库存算分离架构技术创新与实践演进2024年12月，

云来了会不会去掉DBA      多年前我和瑞典马工在网上针对这个互相发公众号引发了争论。我们也在直播环节中进行了辩论。如今已经相逢一笑泯恩仇。马工回国在上海逗留的时候我们还一起聚餐。这个问题大家有各自的坚持，而更大的一个问题来了。AI时代下不仅仅是DBA，现在要不要程序员的话题也起来了。这和当年如出一辙，只是比当初的风暴更大了。因为涉及的面更大了，而且是因为现在AI

原生的PostgreSQL的特殊之处Oracle和MySQL都有undo这个机制，原生的PostgreSQL没有这个机制，它有自己独特的实现方式。实验如下 创建一个简单的表和索引xxg=# CREATE TABLE AA (id integer, name text);CREATE TABLExxg=#xxg=# CREATE INDEX x2 ON AA (id);CREATE INDEX写入1

微服务的确适用于一些企业但是不适合的企业更多这不是我第一次在公众号说微服务的负面了。我也不是第一个说的。网上从微服务切换到单体的案例也有，都是为了企业降低了大量的成本。主要是微服务拆分的不合理基本都是傻子过年看街坊的做法，阿里怎么做，我怎么做。问题是阿里的业务是简单的场景，比如支付，比如电商购物。换到to B的场景中，你看看。有很多时候我们说传统企业SQL复杂，为什么复杂？因为设计复杂。为什么设计

这个概念提出不是一天两天了具体怎么查，官方给出是一个课表之类的用例。但是这个其实让普遍的人认识不深刻。为此我看尹总监写过一篇以订单为用例的建模查询。我是看懂了。不过我不满足于此，我想看看怎么改。全文实践的只有查询，那么写呢？我开始的理解（我其实理解错了），就是对着表更新一行，他就把这行的一个字段更新了，如果这个字段在其他表上也有，那么一并更新了。这是我个人的理解。实验数据如下（我和官方的不一样）建

很简单的道理但是日常开发人员还有很多不理解以MySQL为例，其他数据库也是一样。样品数据如下：mysql> select * from x;±-----±-----±-----+| id | a | b |±-----±-----±-----+| 1 | 1 | 1 || 2 | 1 | 2 || 3 | 1 | 3 || 4 | 1 | 4 || 5 | 1 | 5 || 6 | 2 |

今天《业务向前，数据库向后》的文章我也想表达自己的观点    为了严谨一点我们把业务先分成靠谱的和不靠谱的。     很多时候有一句话说技术是为业务服务的，这句听起来政治正确的话，我其实颇有微词。有时候其实业务人员一点都不靠谱。这种时候需要规范一下业务。需求乱提者有之。    也有的时候是需求合理的，那么这时候就需要发挥技术人员

一次问题     数据库的归档日志很多，多到那个机器的硬件不足以处理了。查看了一下为什么产生这么多日志。发现其实都是一些不当的使用方式。比如开发人员建立了一个xxxx_temp从这么名字上就应该能猜出来这是要做什么？美其名曰是临时表。      就是导入一批数据，给这些数据做一系列加工（运算），然后再把这些数据删除。用SQL来描述，就是i

继上一篇cantian后的继续聊    既然cantian是走存储路线的，这次就从底层的存储这个角度切入。传统数据库架构是存储与计算在一台机器上。这种成为存算一体。那么硬件达到一定程度时候扩展会有点问题。   从事数据库相关工作的人都知道，数据库最大的不稳定因素是（低效）SQL，而低效SQL几乎都来自于大量的数据读取。即大量的IO，这里的IO即可能是逻辑IO

书接上回第二天在参会的途中就遇到了公司OGG的延迟问题。通过我快速的判断，我认为应该重启抽取进程。最终我的判断正确，这个问题得以解决。而我也把我的思路发给了昨天官方讲演OGG的老师。他也基本认可我的分析。我个人觉得这些如果能融合到数据库专有大模型的知识库中，数据库在不少场景中就可以免运维了。数据库自动化程度越高，DBA的低级操作也就越少。而可以把有限的精力开从源头开始管理开发和业务。比如故障自愈是

Oracle的CAB和PAB这是甲骨文的客户大会Oracle China Customer Advisory Board Metting CAB缩写。和Oracle China Partner Advisory Board Metting PAB缩写。这已经不是我第一次参加了。虽然现在有信创，但是技术人讨论技术还是要纯粹一点。所为纯粹就像精武英雄中 陈真和船越文夫的切磋。而对抗是陈真对藤田刚的对决