xuexiaogang的专栏

以MySQL为例，其他数据库也是一样。

为了严谨一点我们把业务先分成靠谱的和不靠谱的。很多时候有一句话说技术是为业务服务的，这句听起来政治正确的话，我其实颇有微词。有时候其实业务人员一点都不靠谱。这种时候需要规范一下业务。需求乱提者有之。也有的时候是需求合理的，那么这时候就需要发挥技术人员的能力，尽可能完成业务诉求。我更多的时候能做到的是超过预期。

数据库的归档日志很多，多到那个机器的硬件不足以处理了。查看了一下为什么产生这么多日志。发现其实都是一些不当的使用方式。比如开发人员建立了一个xxxx_temp从这么名字上就应该能猜出来这是要做什么？美其名曰是临时表。就是导入一批数据，给这些数据做一系列加工（运算），然后再把这些数据删除。用SQL来描述，就是insert 1亿，update 1亿，再delete 1亿。（这里说的1亿是虚数）最终表上是0行数据，但是日志产生了3亿行的操作日志。其实不应该这样用的。如果了解数据库原理就不会这样做。

既然cantian是走存储路线的，这次就从底层的存储这个角度切入。传统数据库架构是存储与计算在一台机器上。这种成为存算一体。那么硬件达到一定程度时候扩展会有点问题。从事数据库相关工作的人都知道，数据库最大的不稳定因素是（低效）SQL，而低效SQL几乎都来自于大量的数据读取。即大量的IO，这里的IO即可能是逻辑IO也可能是物理IO。相对于逻辑IO来说物理IO更为恐怖。所以一般所谓的优化主要工作就是来减少IO。很多时候IO是瓶颈。当然也会遇到优化不动的时候。既然应用侧解决不了，那么就存储侧解决。

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

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

从招聘网站中还能看到Java架构师、PHP架构师.NET架构师等等。我不否认每个都有自己的架构，但是我觉得这些都应该是应用架构。我接触到不少架构师是Java出身，然后也懂操作系统，也知道一点数据库，也懂中间件。只是喜欢简单问题复杂化，动不动就是Redis、Mongodb、Kafka、RabbitMQ、NGINX等等。再就是DataX的数据同步。确实全面覆盖了。

有人问我他遇到一个问题，就是醒目录入后有乱码的出现。而出现乱码的地方是维族的名字中间的 •。比如迪丽热巴·迪力木拉提。

在月初作为大会观察团的团长，再次领导了任务卡。帮忙联络业内朋友参会。本次邀请的都是第三方代表的个人。都不是OB的用户。最终大家以公众号主理人的身份出现在宣传视频中。而OB另外的宣传报道中也非常注重的将参会嘉宾逐一介绍，而将自己的CTO、CEO、科学家等放置在了海报的最下方。这种姿态受到了大家的好评。

刚才我们提到说这个产品算存储这边的。不知道的人会问为什么这样算？结合他们在gitee上的描述：Cantian引擎，是一个存储引擎，采用了存算分的离架构，通过分布式缓存技术、事务MVCC机制、多主集群高可用等关键技术，可以让使能普通的单机数据库，让其变得具有类似Oracle RAC的多读多写能力。Cantian引擎无需修改已有数据库的实现，可以以无侵入的方式被MySQL等数据库加载运行。类似Oracle RAC，Cantian引擎的多读多写，也需要基于共享存储来构建。

各种数据库都有对误删除文件都有一定的处理方式。今天说说Oracle的DRA。这个不是新技术，但是其实知道的人我估计不多。当年是考OCP的时候学习到的。那时候是11G，这个版本是2007年发布的。所以说不是新东西。但是即使这是OCP中必考的，但依然很多人不知道。说句实话我也是在考试中学习，生产环境中没有用过。就像一般的备份，大家也几乎很少用到一样。只能说运气好，工作以来从来没让我去用备份恢复过生产。而这个DRA技术也是一直停留在实验环境中。在有备份的前提下，把系统的文件删除了。从图中看到，被恶意删除了sysa

27个大的列表，不断的写入和读出。你可以理解为一个消息队列。虽然说Redis支持消息队列的这种应用。这个我在第一本书中介绍过。但是吧。支持也有个前提条件。毕竟不能当做kafka用。就像数据库的多模是可以解决异构数据库的融合，但是极致的应用的话，还是差点意思。这就像不少数据库说兼容谁谁谁。但是如果是深度应用的话，还是不行。这种深度不是说使用了存储过程就是深度。10行的存储过程，那叫兼容。10万行的存储过程，那叫深度应用。所以我一般和人交流，有的企业说我们已经不让用存储过程了。

由于经济形势的不好，我看参展商少了一点。可能不少都是为了生计而挣扎。2023年1月明叔主持的栏目有一期特别节目《数据库诸神之战》，请来了OB、TiDB、TDSQL和TDEngine的掌门人来讨论数据库的未来，那时候结论是3年后国内健康运营的数据库公司不超过30家。目前已经快过去2年了。现在日子的确越来越难过了。现实可能和预测差不多。

技术大会每年有很多，有开发者大会、有运维大会，还有AI相关的。要论集中在数据库专项上的只有DTC和DTCC两个了。论规模的话DTC是2天的，而DTCC是3天的。

整个活动下来，感受到了参天团队的热情和专业。和新闻联播一样，读秒开播。面向主要是社区内部。看来每周都有这种请外部人士进来交流。大家提问题也很踊跃。整体的专业也很强，尤其是他们对存储很专业。专业存储不仅仅是解决了本地盘的可靠性问题，其实数据库本身就是IO密集型产品。众所周知，数据库的优化主要就是去减少IO。当然如果实在减少不了，那么就是加速IO了。有些人没有意识到数据库和存储强相关。其实你看有时候同样一个数据库版本，但是在不同硬件环境下的运行状态和吞吐能力不一样。

OpenTenBase，是企业级分布式数据库TDSQL的社区发行版。2023年12月16日，腾讯云将OpenTenBase捐赠给开放原子开源基金会。最初是TDSQL for PG，如今OpenTenBase已经包括了TDSQL的MySQL版（就是TPCC打榜的那个）

我以前用过MySQL的部分索引。不过说实话使用场景不多。于是上次本来打算在书中也写这个。结果徐老师说PG的不一样。后来我尝试了。果然不一样。Seq Scan on xxg (cost=0.00…45691.00 rows=100000 width=12)(1 row)xxg=# \d xxgTable “public.xxg”Column | Type | Collation | Nullable | Default--------±--------±----------±---------±---

分布式事务也控制不了N个数据库，其中还是异构数据库的，全体回退。比如一个系统需要用户的信息，每次调会员的接口。下次自己有的用自己的，没有再去找。结果就是自己理解的划分，或者说是抄别人的。终于原本的小寺庙成了个大寺庙，自然大寺庙就需要大寺庙的配套模式：开会、文件、沟通、协调、打分、评比……结果导致成立更多的部门，招聘更多的管理者，提拔更多的干部，设立更多的管理岗位，设置更多的考核、激励机制……你再看看hadoop的架构，也非常像上面提到的。首先如果要查询的数据在不同的数据库上，这下就无法关联查询了。

分割。

如果写成exists那么，这两种是一样的结果。那么这种就是返回了较少的表的全部数据。当然这种会随着两个表的数量上升以及关联的范围越来越大会变得越来越慢。有时候这个较少的表也很大。比如这时候子查询是2条。从日志中就可以看到，关联子查询不会再是子查询仅返回1行的那种优势了。而实际工作中X和表Y表都会很大。而且实际工作中更多的是这种写法。这种关联子查询的方式。其实日常工作中遇到的都是基础问题，很难有什么高级问题。实际上这样写，子查询有一条或者是1万条都是返回父查询，没有差别。我的新书中有更多有价值的的经验。