ITPub博客

     今天是有点八卦，属于趣谈。免责申明：提到的没有好坏之分，纯属名字巧合。我一贯风格也是不去贬低某种数据库。      如今国产数据库有几百个，实在太卷了，我从业这么多年，学习和掌握了十几种数据库，但是仍然有很多叫不出名字，甚至没见过。今天说的还都是在国内说的比较多的（没提到的不代表说的不多，只是和今天主题无关）  &nb

    昨天我转了一个不要微服务的，我还是看到有人点赞的。我不怕被说反潮流，我是比较务实的。我经历过没用微服务的，也经历过用微服务的。咱们也不说谁好，我就是看  一般的企业（注意我的范围，我没说阿里、腾讯、字节等）没用微服务的稳定性比用微服务的好一些，没用微服务的成本比用微服务的少很多，这个是估计放到哪里都能达成共识的。这个成本包括了人力、服务器等等。如果不信我们可以

    节前我处理了一个问题。先上图，可以看出来查询这个表，有两个条件，一个是code一个是实际。最终执行查了5000万行数据。历时900秒。当然最后也是查了个寂寞，没查到。对于5000万扫查了900秒，这个我既能理解，又不能理解。能理解的是扫描5000万用900多秒，说的过去。 不能理解是。从2022年1月开始到现在这个表一共才2亿条。 我每月一个分区，查询一个星期，怎么也在

     有一次听一某个银行讲他们用Oracle，说到业务连续性，他们说，如果卡死的时候要么重启，要么切换。他们明显是走重启路线的，类似强制关机那种。当时他说了一句，主机宕机了就重启数据库。主机宕机情况下，Oracle从来没有让我失望我。     以上是别人的声音，我回想我自己经历（仅代表个人），似乎也是差不多。只是刚工作时候用Oracl

首先说明这个问题不能怪数据库。上周遇到一个事情，大家都在讨论一个问题，我看没人@我，我也没管。直到有人说，让我去看看她那里为什么查询的比较慢。在处理过程中才发现这个数据库上活动会话有80多个。难怪慢。背景是这个MySQL内存仅4G。（为什么这么小，我回答不了）    看到红黄框一共10句，是一模一样的SQL，对一个log表全表排序。其中红框的两句几乎是同一时刻。后面的

 上周有人问我一个问题，数据库莫名重启了。其实是数据库crash了，然后守护进程把他马上启动了。我看了一下错误日志，很奇怪。也是第一次遇到。看到红色框的mysqld got signal 11，一下就感觉不好。历次数据库crash，必然有他。不过以前我遇到最多的是latch lock。这次不是。蓝色框数据库说可能是一个bug，不少人看到这句就说，遇到bug了。我个人不这么认为，因为这是官

    最早我听这句话是有一次DTCC上，有位嘉宾说Elasticsearch的。首先他既能存储数据也能做全文索引，所以Elasticsearch归属数据库范畴。也有不少人没有这个认识，甚至认为es和redis都算中间件，有这个认识的基本其实和他也没法深入沟通了。那么由于es的某些场景中全文索引解决了我们RDBMS中非常忌讳前%，不过这个有个前提条件就是有分词，如果没

     有一次大会听运营商和金融行业等都对业务连续性提出了很高的要求。在保证一致性的前提下，尽可能短的减少停机时间。这个压力主要都是在数据库上。在灾难来临时候对数据库进行切换。我们平时说的高可用一般来说都是容灾的，其实对于性能来说不是直接的提升。主从两个数据库采用读写分离来缓解压力，属于间接提升。我还是那句话，提升性能还是靠SQL。当然我也不反对硬件提升来提升性能。

   经常遇到这种场景，select count(*) from t where t.col='XXX'  其实col列就2-5种类型，这种通常来说建立一个索引的效果不好。但是去找开发谈的时候，开发说这就是2B的企业用户场景。一共就2-3家公司，又不是2C的有上万个用户，每个用户看自己的数据。这里每家公司已经是只看自己的数据了，就这样。  &

     好几天没写了，最近忙，今天告一段落。再不写本周就没产出了，这不是我风格啊。     今天帮一个开发看了一个场景，一个报表场景，一个SQLIO几乎用尽。5分钟一次，一次2分钟。可能大家认知中报表就应该这样。或者在hadoop中经历涅槃最后展现一个结果（后台服务器累的要死）。其实这是不对的，但是大家认知是这样很难改变。以前我也认为这

 可能这个比喻不是很恰当。但是不会差太多。前几天和一个算法美女博士谈及她的专业，我说其实数据库核心之一就是算法。我在她面前班门弄斧的说了阶乘和选择度等。当然博士容忍了我的吹牛。其实我个人也这样理解的，数据库是数学和物理学的结合。一个SQL就是把高级语言翻译成机器语言，最后在指定的地方读写值。如何读写其实很大程度取决于逻辑，我有时候看到一些待优化的SQL就是：查一年数据可能是200万（其实

      前几天在一个群里看到大家讨论硬件。大佬说：现在谁还共享池总出问题？（早期因为资源不足，SQL烂一点的话会造成争用），现在随随便便都是1T的内存，哪里会有共享池问题？其他人也说自己是128G内存起。有人也说之前看Oracle要那么大内存，感觉太夸张，随便上百G，现在看国产。这么一笔下来，Oracle真节约。    对于以上问题，我第一个说

上周有个事情，一个开发写的SQL，我有点接受不了。原始的是select   from t group by 后面跟了几十列。我当时也是震惊到了，为什么？他和我解释了一下，我当时真是想骂人。我来用几个表简单说明一下。我这里不用真实表和配置，我用个简单的表举例说明。比如说有一个表就流程表，大家可以看到有5个部门，每个部门做两件事，发工资和发奖金。（这种喜闻乐见的事情大家能快速理解）

   上周看到老白公众号的一篇文章。其中写到一句大实话：“能让硬件去干的事情，我们肯定尽可能不麻烦数据库，但是必须让数据库干的活都得让应用去解决，那么我们就受不了了”。   我就以上实话说说我的看法，前半句是说硬件提升了，硬件能解决的，那么就不会抠抠索索的限制这个限制那个。数据库本来就够复杂的，别让他再复杂了。但是如果数据库的本职工作如果都不做，比如锁，都要

我忘记我是不是写过了，如果写过就跳过吧。为什么写这个，以前出过几次问题，我发现分页写的有问题。很多人不是太明白。我这里列举一下：   A场景： select * from t where rownum<10 或者 limit 10  或者用fetch first 10 rows only;这种场景：不管表中数据量是TB级别还是PB级别，查询KB返回KB。&nbs

 我相信做过数据库对以上的都不陌生。基本上主流数据库都支持分区。分区是一种对应用透明的管理表方式。尽管可以在网上找不到不少黑MySQL分区的，但是时至今日我用MySQL分区没发现一点问题，当然PostgreSQL和Oracle的我也没发现问题。我猜测那些问题应该来自于使用上的不规范。我以前做公安系统由于单表几十亿上百亿，还采用过二级分区，效果非常好。    分区一般使

先来一个数据量运算关系。1 kilobyte kB = 1000 (103) byte1 megabyte MB = 1 000 000 (106) byte1 gigabyte GB = 1 000 000 000 (109) byte1 terabyte TB = 1 000 000 000 000 (1012) byte1 petabyte PB = 1 000 000 000 000 00

      虚拟机部署数据库（我认为在自己练习环境可以，正式环境还是算了）。数据库作为系统的核心，资源一定要独享。甲骨文说如果Oracle安装在虚拟机上，都不提供支持。如果一个物理机上运行一个database比如（MySQL这里的X PostgreSQL这里的X），这样的其实有点浪费，那么可能应该有多个。可能会有说现在微服务应该把数据库分开。其实我想说微服务和数据库是

 报警分为几种（结合我各行各业的工作经验）：1、无报警（这里主要说是数据库已经不行了，但是报警没有提示。因为设置90%报警，且要持续5分钟，现在是80%，持续了几个小时。）2、用户操作出现问题（同时我们系统也发现问题）和用户同时发现。比如用户点击页面1秒 2秒 3秒 。。。10秒没出，报502 503等50X 等等.  这个时候我们后台也会报警。这种要先于用户不现实。他没操作之

前几天半夜和一位朋友讨论他们集群的问题。我本人大概7年前干过一次集群报废的事情（好在是实验环境摸索）一下重启了所有节点（当时安装在一台机器上了）。这种情况下机器已重启所有节点都重启，cluster大的特点是要半数以上存活。这种情况下开了持久化，他集群也组合不起来了。（也许有高人有其他办法，我当时是没办法，重建的）。     当年我就在想一个问题，如果redis万一坏了