ITPub博客

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

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

    我们公司每年中午午休时候会关灯。由于每次关灯时间都不一样，我徒弟说说这一看就是为人的。机器执行理论上都是一个时间点。就这句话我想起来我十几年前遇到的一次问题。那次问题就是机器执行，但是时间就是不准的。   时间回到2008年，那时候我技术还很一般。有一个项目我去现场实施，那个项目说起来悲催。第一次去北京奥运会还没开幕，第二次去伦敦奥运会都闭幕了。你说

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

JSON这种数据类型在关系型数据库中已经是标配了。如果不是深度应用比如游戏那种的确是离开不了MongoDB，其他的一些简单场景的话Oracle MySQL PostgreSQL都有JSON。今天仅仅说一下Oracle的JSON在使用上的一些问题。

    周五周六两天参加了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都不用改，这样来自开发方面的阻力就没有了

  之前我写过一篇《你没有大数据》那一篇被阅读的也很多。我这里说的是大部分企业，少数公司有这个场景的可以使用。不过即使大数据为未必使用Hadoop。  Oracle和PG都有组件或者衍生途径去实现列式存储，那么对数据分析是有利的。MySQL当然也有只是目前在企业版中，在云上有。所以他相比较其他不太适合做分析。但是今天我就用这个不太适合做分析的数据来说一下为什么一般企业不用大数据

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

    在工作中经历过不少使用es的场景。es作为搜索引擎数据库用作全文搜索是不错的，但是真正用到es的不多，不少场景可能用MySQL、PG甚至Oracle都可以很好的完成，只是缺乏专人的设计和把控。不过我的ES水平也有限，只能处理简单的场景。这里要是有不对的，请指出一下。今天就是分享一个故事。     es数据库又名全文索引，它的索引其实就是传统

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

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

    一般来说大事务大查询会导致undo变大。默认配置不会自动收缩。印象中OCP的考试中都没涉及到这样的考点。     记录了一次在实验环境下模拟收缩的实验。需要在参数文件中设置这几个参数;innodb_max_undo_log_size = 10M  --回收后的初始状态一般是16M，即使这里设置是10M，最终通过实验测试得出也是16

   从Oracle10开始就有闪回，这个功能多次起到力挽狂澜的作用。比如有两个表，分别是sh1和sh2。                       SQL> create table sh1 (a int,b int);表已创建。  &nb

    下面说的 这些问题都是随意导致的。真的不是所有开发都可以写SQL，不是所有开发都能建表。这给后续的开发和运维工作带来很大的问题。     上周意外发现一个SQL，大致 SELECT  *   FROM a   LEFT JOIN b  ON s.xx = d.xx&nbs

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

     一次数据库迁移过后，运维反馈数据库空间不足了。原来规划导入10G数据，现在占用空间比预期大量3倍。这个迁移过程我知道，中途还有insert into select的动作。但是处理的数据有点大，导致处理失败。     其实这也就是表膨胀的主要因素。     创建一个表，写入一些数据。看到这个表现在大小