ITPub博客

看到这个标题可能觉得我在乱说，其实很多中间件作为数据库的上下游，它们的稳定取决于数据库的稳定。这里我主要指的是SQL。 很早之前我说开发的主题语言其实更多的是SQL（这里并没有说Java不重要的意思），只是Java中并没有太多的业务逻辑。真正的业务逻辑主要还是在SQL中体现的。说的直白一点是如何写数据，如何读数据。 我现在工作不太做数据库安装、备份等。更多的是看看开发这里的问题

 概念1：大数据。这个概念出现的较早，只是在我国实际上变得口口相传实在2010年前后，其实大数据这个就开始流行起来。以至于我父辈的亲戚中都说我是搞大数据的。其实和他们也解释不通，别说他们了，就是和周围的开发同事或者都是做技术的也解释不清楚（也可能是很多人清楚但是装着不清楚）。这里我要说的是：1：Hadoop是大数据解决方案之一，是个代名词，但是不是全部。2：除了少数公司，绝大多数（99.

确实干过一些有问题方案。方案1：一次接一个电话就到会议室，简单告诉我背景。就说原来有个A数据库，后来由于种种原因吧，有了一个B数据库。业务在使用过程中就发现B数据库必须用到A数据库的数据，目前需要2个表。且一致性和实时性非常高。要求解决，且（重点来了），不能增加开发工作量，最好48小时以后就可以用。数据库是同构数据库Oracle。基于以上的条件我只能给出了在B数据库上建立一个到A数据库的物化视图的

看到这个标题可能觉得我在乱说，数据库选型要从多个角度和维度看来，还有各种POC。很多供应商朋友告诉我POC是一个漫长的过程，非常痛苦，要解决各种技术问题。怎么能说和技术无关呢？因为从我的经历和周围听说的经验来说，技术只占很少的一部分。甚至可以忽略。如果是DBA主导，那么这事情就单纯了。纯技术的角度哪个产品安稳易用（安全、稳定、容易使用）用哪个。实际上是技术账、商务账等等多方面的。而这里同样一个问题

    上周在北京参加了阿里云的开发者大会，我因为去年做了一点小贡献。非常荣幸的获得了阿里云的MVP的这个殊荣。（期间也认识了一些大神级的人物）还有就是一些网上认识的打卡们线下见面。这个也是我一直追求的荣誉。几乎在同时P（PingCAP）社为了感谢我去年做出的一点小贡献，也给我颁发了一些荣誉。对我来说是双喜临门。   有人诋毁我一直说国产的坏话，这是不实言论

   这个题目有点拗口，和最近有些话题有点关系，但是更多的还是我作为这些年过来的一些矛盾的阐述。   从前有个笑话。一队军舰在水域巡航，这天晚上大雾。军舰看看到前方有灯光，立刻发出“海军灯语”。请立即让开。对方也给这艘军舰发出灯语，请你绕开。军舰不服，打出灯语：“我是旗舰，你必须要让我先通过。”对只回应说：“你让开，我是灯塔。我在这里已经很久了，我为所有的船

    2023年的最后一个工作日了，大家都开始卷回顾了。接下来就流水一下今年大事记。首先失去了一位亲人，然后家里也有亲人住院半年。不太顺利。    2023年2月获得了PostgreSQL ACE Partner感谢PG分会魏波老师。这个我做的还不够，往后多多贡献。在2月也参加了分会的年会。和美创的几位Oracle的ACE当面认识了。还有和灿灿、崔鹏、闫书

   其实这个话题没有一个可以定量的结论。因为有的企业甚至没有这个岗位，更加别说相关的人了。不设置这个岗位的一般也有他的道理：1.     不需要。比如甲方。有事是乙方或者集成商处理。2.     没预算。招一个靠谱的人很贵。3.    &

为什么要说这个，可能有些朋友觉得和这几天话题有关。其实没有什么太大关系，我没有被抄袭所以也没法去说。（也许我写的还不够被抄袭的资格）。我真正想表达的是使用和运维开源数据库（含其他软件）的人，应该得到重视。这个重视第一就是体现在价值上。似乎每个技术人，甚至作为管理者都认同这句话：开源不等于免费。但是似乎就没有然后了，不免费，但是也没花钱。这就很矛盾了。几年前写过一篇《从推荐使用MySQL TiDB等

    周五周六两天参加了2023年的中国系统架构师大会。这是这个会议第一次离开北京举办。读过我公众号的朋友知道我是从2013年开始一次偶然的机会参加DTCC的，中国数据库技术大会。那时候我除了知道Oracle、MySQL、SQLServer、DB2就不知道其他数据库了。那时候有多菜啊。Hbase是啥？不知道。总之让我打开眼界，然后在翻看会议资料时候发现DTCC还有一个同父异母

    首先我是猜测，具体是什么不知道。但是今天一个操作实在让我吃惊了。听我慢慢说。     故事是这样的今年报税意外了，导致专项扣除有点问题。然后本月收入少了好几千。联系了公司人力资源，她们请我过去直接操作我手机看看专项扣除的问题。最终推断我修改了，但是税务系统和公司的对接上估计走的是定时批量。错过了定时任务的时间。说到这里我就觉得这样

这次正好在假期期间被邀请参加OB的发布会以及DBA老友会。1．朋友相见。若干个读者和群友和我本人见到了比如天舟兄。也结识了一些平时就听过的知名人物比如同为ACE的戴明明，这次面对面的深入交流。在OB的发布会上，还看到了我曾经的学员已经升职到所在单位技术部门的副总了。这也是个人与数据库相互成就。更多的是遇到了平时就熟悉的朋友以及新结识的朋友们。退役和现役的4个ACE。    OB

     最近关注数增加的较多，增加了几百人。感谢各位了。不少朋友都说捧了我，其实我就是主动或者被动接触的数据库多一点，Oracle、MySQL、PostgreSQL、Redis、Elasticsearch、MongoDB、Hadoop全家桶、列式数据库、时序数据库、图数据库还有达梦、OB、TiDB等等都学习或者使用过。头衔也不少，所以有时候说话还要注意啊。&nbsp

       我个人愿意学习多种数据库，但是我不太愿意去切换数据库，这里有多方面原因。有点长，看完了再觉得是不是要骂我。有可能不骂了，也可能骂的更厉害了。       开发原因：做过DBA的都知道，遇到让开发改SQL几乎没有顺利的。我曾经遇到过Oracle从11到19，一个SQL都不用改，这样来自开发方面的阻力就没有了

     好几天没写了，这段时间积累了一点要说的问题。上周遇到华为的一个朋友，在提及数据库的时候很多性能指标。首先我不怀疑他的指标，我觉得十有八九就是真的。现在只要拿出的数据，基本都靠谱。因为如果离谱的数据，同行会质疑的。不过我说了一下就是在实际环境中，通常用户连这个百分之一的都达不到。这不是说产品不行，而是使用者不行。     我们数据

     我经历过很多项目，从前就一个数据库支持上万并发，存储上百亿行数据的级别是非常容易得。现如今的玩法不是这样了，而是将一台数据库能解决的事情，拆分成几十个数据库。有一次我的群里有人说有个项目将一个Oracle拆了100个MySQL，每个MySQL一主两从。也就是2比300的这样的比例。（因为Oracle也是主从，算两个吧）。这技术难度和成本上都陡增。这和最近几年

    子查询和关联查询过多的危害（从前标量子查询那篇文章的延续）        子查询过多（很有可能不少都是不必要的，或者设计导致的）会导致SQL变得很慢。下面实验采用MySQL演示但是结论适用于MySQL、PostgreSQL以及Oracle都所有关系型数据库。    创建两张样例表，a和b。a表的id列

   又是一年盛大的技术盛宴结束。从2013年至今DTCC和SACC成就了我，也希望越来越多的人可以参会提升自己，并且学习到知识。   参会的目的：   1学习：学然后知不足，知耻而后勇。让自己不断的知道自己差距有多大。   2会友：很多在线上因为对方技术博客或者发言而结识的朋友，进行当面的技术交流。  &n

最近在几个群里发现有些SQL实在是惨不忍睹。有的SQL 有40多个表连接，有的SQL是几十个UNION ALL。第一感觉这样的开发留着过年吗？    其实对于这种现象有很多种可能。有些是框架干的。有些是被动为之（前人就这样堆的，也只能继续）。有些是因为设计不合理或者需求不合理造成的。也有些是因为不懂，所以无意识的干成这样的。其实这些在国内非常普遍，哪个公司几乎都会遇到。没有这类

今天又是一个问题，这个问题从数据库可观测性角度来看就是IO问题。数据库已经给出了建议（AWR）。这里说明一下：原来是物理机，后来迁移到虚拟机。我本人其实方案数据库在虚拟机中运行。虚拟机不配运行正式环境的数据库。这么说可能是有点情绪，但是正儿八经的系统，我还是建议不要用虚拟机。     既然是IO问题，硬盘IO不是简单加硬盘就能解决，我想的就是增加内存。把数据尽可能在内