- 博客(56)
- 资源 (3)
- 问答 (1)
- 收藏
- 关注
原创 震惊!一次小时级到秒级的优化--原因实在不敢恭维
支持人员说可能打听到的逻辑是:更加excel的某几列去数据库的表中找到相应的数据,先进行一波删除。虽然整体设计和逻辑上我不认同这样做,但是这个又不是我的系统,帮别人就先按照优先的条件去做。这就1万的数据同步到50万的场景,硬是搞出了大数据(48亿行的运算)的场景。做技术的总有对技术的研究,深入研究的都知道大数据库本身就是数据库。原理也都是一样的,无论小马拉大车还是杀鸡用牛刀都是不合适的。正式上传的时候,就看到那个页面的进度条不动(估计在初始化),然后进度条开始了。不少人还会说,大数据的机器是要负荷高的。
2024-03-14 20:56:01 338
原创 其实很多人不了解SQL Developer
这种方法网上找不到,我是发挥自己的机智,在微信群中搜索关键字。就左下角出现了单独的SSH配置框然后建立SSH主机(这个就是堡垒机的地址)当然官方的最新的版本23C的在SSH上有bug。而且SQL Developer的实时监控约等于一个简化的EM。其实Oracle官方自己也有自己的工具叫SQL Developer。这个是个不错的软件。打开这个目录就看到了熟悉的tnsname.ora。就是把所有的配置(我自己名下权限的数据库连接字符串)导出了。然后在工具的连接框内就出现了配置文件中包含的数据库连接。
2024-03-13 17:42:40 336
原创 【无标题】
今天还是主要是开源的,开源的可以自己搞就是上面说的,觉得自己可以解决。可以说很多架构问题都是出在数据层,例如常见的「烟囱式系统」带来的种种问题,特别是数据孤岛问题,其实本质上的原因就出在没有将数据层打通。开源软件写的也不容易(很多公司做的东西不开源,我觉得可能是开源了被内行看到说这写的什么玩意啊)。(当然如果是我们团队几个人一起在改,互相发送改的内容这个不算传播)那么就要按照开源软件的协议做,声明来自哪里,谁做的,并且也开源。我觉得这不是问题,别人做出来的,开源了不是他的义务,愿意开源好。
2024-03-06 20:54:12 387
原创 低代码工具APEX的入门使用(未包含安装)
那时候还没有流行低代码,直到2021年的时候,那时候开始低代码无代码。然后只要会写高质量的SQL,那么就完成了数据采集和数据展示的工作。请看Oracle ACE的网站,这就是用APEX做的。实际上有一次我看O记的人操作他们的办公流程,都是用APEX做的。但是我们要注意其实APEX这种技术不是现在才有的,Oracle11G的时候就有了。在外观对话框中,Apex默认提供了三种类型的主题和导航,我们可以⾃由选择。在APEX ⼯作区主⻚中,选择 SQL⼯作室,单击对象浏览器(就像客户端工具的一样功能)。
2024-03-04 22:18:08 371
原创 每当遇到一致性问题我就思念一个数据库好
估计马上就会被问责。例如,卡号可能是CARD_ID,也可能个是CARD_NO或者CARD_NUM,当然也可能是不带下划线等等。但是有些字段比如时间,连数据类型可能都不一样,比如有的是时间型,有些是字符型。那么其他数据库都是好的,也基本是瘫痪的。这个标准包含,字段名,字段含义、字段类型、字段长度和字段的值。例如,A系统的STATUS,表示发送状态。A系统的1表示全额付款,B系统的1表示部分支付。而且就风险和收益来说,我觉得应对风险的成本单实例成本低,性价比高。可能还有,不一一列出了,因为优点实在是太多了。
2024-02-26 19:59:43 325
原创 MariaDB落幕和思考
这个背景是说在宋代以前都是认为曹魏是正统,但是北宋灭亡后,南宋偏安一隅。考虑了半天,结果什么都没发生,只有自己这里发生问题了。很多系统中考虑了主备模式,甚至同城双活,两地三中心,现在三地五中心的也有。应该考虑,但是一年到头几乎没有遇到,毕竟国泰民安的,地震海啸属实不容易遇到,几年甚至几十年才有一次。比起说起来卡脖子了,闭源的来说,还是先看看自己的企业能坚持多久。更多的是风险还没来,公司关门了。就像是魏国,甲骨文说我买过来了(皇帝在我这里),我是正统。与其担心一些遥远的不着边际的问题,不如看看当下的问题。
2024-02-22 21:26:43 620
原创 MySQL到Redis的同步的做法(文末有官方推荐)
说清楚这个以后,还是要说如果有非常频繁访问的数据,还是应该放在Redis中,毕竟能解放在线交易数据库,就解放一点吧。毕竟每秒几十次的通过索引点查的请求对关系型数据库来说,这都不叫事(其实每秒几万也问题不大,感兴趣的话看我早期的公众号。这是把MySQL等数据库的计算过程说的慢,查询结算结果的快做了一个不公平的比较。最近Redis企业版推出了一个新功能,可以通过CDC的方式从RDBMS里面自动把数据变化同步到Redis,直接供应用从redis读取数据,避免了从业务逻辑层面处理数据导入导出的问题。
2024-02-21 17:07:03 360
原创 从starrocks安装说起和Oracle的OLAP殊途同归
它引入了更多的SIMD(Single Instruction, Multiple Data)指令,可以同时对多个数据进行操作,加快向量化计算和并行处理的速度。问过后原厂产研的老师非常准确的说,是avx2的问题。通过使用AVX2指令集,程序可以更高效地利用CPU的并行计算能力,加快运算速度,提高系统的响应能力。Oracle的In-memory之所以快,其实也是因为SIMD的原因(当然在内存中做就更加快了),而这个是2013年就发布的。对于做数据库的人都知道什么是交易型数据库,什么是分析型数据库。
2024-02-20 19:55:19 850
原创 DBA不仅仅是管理数据库--也要管理好需求
我想说就是如果砌的墙比紫禁城还高,但是就是有人就是要去偷鸡,他可以挖地道。但是软硬件提升的情况下,业务和SQL什么都不改,问题就解决了。所以有钱有有钱的做法,有些都惹不起的情况下,就用钱来解决吧。不同的数据库有不同的处理方式,不少数据库都有自己的解决方案。我多年经验告诉我,在设计一塌糊涂的前提下,优化显得苍白无力。比如不是什么人都能提需求,那种不靠谱或者不着调的人提的不靠谱、不着调的需求就要扼杀在摇篮里。现在酒驾的人少多了,但是依然有。而士兵指的是不靠谱的业务或者按照这种不靠谱的业务照单全收的开发人员。
2024-02-06 20:07:20 368
原创 DBA不仅仅是管理数据库--也要管理中间件
但是在一次次数据库问题甚至故障后,越来越多的开发人员意识到我说的是对的。多次中间件(这里指的是Tomcat的JVM和消息队列等)的问题(OOM或者是频繁Full GC)也是由于SQL造成的。因为一次取的数据太多,数据库把数据明细这种几十万甚至上百万的数据送到相关环节,这些环节一下处理不了这些数据,就发生了OOM或者是频繁Full GC。很早之前我说开发的主题语言其实更多的是SQL(这里并没有说Java不重要的意思),只是Java中并没有太多的业务逻辑。更多的是看看开发这里的问题。这里我主要指的是SQL。
2024-02-05 22:16:37 1517
原创 对比上次MySQL的DDL
这个命令在11G是不可能这么快的。而且也没有MySQL的超够64就会重新构建的问题。这个是在Oracle19C下的实验,特别说明。因为在Oracle11G下有些结论是不成立的。这个命令在11G是也是同样效果。MySQL的DDL未必都是可以快速完成的,那么Oracle同等场景下如何?再对这个表进行增加字段的DDL,带有默认值和非空约束。比较稳定的都是不到20毫秒的扩容和1.5秒左右的缩容。这个命令在11G是不可能这么快的。这个命令在11G是不可能这么快的。下面对这个进行增加字段的DDL。
2024-02-01 21:00:39 408
原创 即使在MySQL8上也不是所有DDL都是秒过的
MySQL8的特性借鉴了Oracle 11G的设计,将表结构放在数据字典上管理。换句话说小于64位的长度在这个区间内从小到大扩大是可以快速DDL的。大于64位的,从小小到大扩大也是可以快速DDL的。在MySQL8中可以看到没有非空,也没有默认值也是可以快速加字段的。这里涉及到的问题就是,数据字典存储64位长度以下的和存储64位以上是不一样的。但是就是主要如果从小于64扩大到超过64位,则需要考虑会发生表重构的可能。当然如果增加了,更加没有问题,可以快速增加字段。这里可以复现一下,构造了一个1000万的表。
2024-01-29 21:26:21 836
原创 致IT领域那些忽悠过的概念
他只是说我汇报的东西里面,可能有50%是符合他当初的期望的。现在是多个数据库,异步解耦,分布式事务,还分布式锁,最终一堆技术栈上去以后,数据还不能保证100%一致。当年我很多系统的单表100亿级别都没有用到小型机,在PC服务器上就运行的很好,那些表大约都是100TB级别,基本碾压现在大部分公司的数据量。其实和他们也解释不通,别说他们了,就是和周围的开发同事或者都是做技术的也解释不清楚(也可能是很多人清楚但是装着不清楚)。作为锦上添花的功能,在经济富足的时候需要,在经济不行的情况下就有点可有可无了。
2024-01-28 22:45:10 860
原创 数落这些年我给的不靠谱的方案--痛心疾首
然后我顺便去看了这个数据库,结果发现当初说好的同步2个表,现在有50多个表,每5秒刷新一下。就说原来有个A数据库,后来由于种种原因吧,有了一个B数据库。要求解决,且(重点来了),不能增加开发工作量,最好48小时以后就可以用。说,这些传感器的数据单独在一起发挥不了太大的作用。听到这里我不禁想说,您早说的话,我直接让这些写入生产库(毕竟这些数据也不多,而且也是生产数据)那么问题就都解决了。基于以上的条件我只能给出了在B数据库上建立一个到A数据库的物化视图的方案。我想说:单机(含高可用)是最好的架构,没有之一。
2024-01-25 18:58:47 371
原创 数据库选型其实技术维度不太重要
他们可能是看到一个公众号,也可能是听到朋友聊天谈起来、再或者是参加一个大会看到一种数据库,就可能倾向于选择这个。(现在国产快300个数据库,有些我们熟知的国产数据库在决策者那里可能闻所未闻,所以可能你学习了八种数据库,最后企业选型选择了你不熟悉的第9种。和用户关系好的数据库,是好的关系型数据库。我这几天看到一位做移动开发的准备培训材料(鸿蒙开发),他之前做安卓开发的,我立刻秒懂了。因为从我的经历和周围听说的经验来说,技术只占很少的一部分。但是决策者可能考虑的是,我花钱来是解决问题的,不是带孩子来包容他的。
2024-01-24 22:01:13 374
原创 2024年开年的荣誉--来自国产数据库
去年参加OB的发布会后的DBA老友会,OB也非常谦虚的向业内的一些专家请教提一些对产品的意见和建议。对于不让说问题的产品,这种我是不会去用的,这个倒不是我怕律师函。尽管我们都对数据库选型没有绝对的话语权(后续我会写文章为什么我们大多数没有决定权),但是作为使用方对产品的使用评价权还是有的。我记得很多年前听PingCAP的CEO刘奇在一次会议上说:今天来的都是客户,我有两点要求。我国的政治制度是政治协商,民主党派对共产党也有提意见的时候。每年两会的一些提案和议案就是对当前的一些问题的改进。
2024-01-21 23:06:24 574
原创 应用适配数据库还是数据库适配应用
为了性能可能要做一些SQL改写(能改写好的算运气好的了),那这个改写的算不算对新数据库的适配改造呢?运气不好的那就大改特改了,甚至是重构。在海军中,“旗舰”是指一艘指挥舰,所有军舰要服从我,而在航海中,“灯塔”是一种为船只提供导航指示的人工光源。只要不要稳定性,怎么来都行,开发人员只要不让他把自己和前几任写的代码都重新写一遍也没有多大的问题的。其实不少都是框架完成的,有些变量都是抄来的改一改,甚至改都不改拿来就用。这个题目有点拗口,和最近有些话题有点关系,但是更多的还是我作为这些年过来的一些矛盾的阐述。
2024-01-08 22:50:01 419
原创 看看关系型数据库是怎么吊打Hadoop的
Hadoop在大家都是烂硬件的时代,依靠多机器全表IO打赢了单机器的全表IO(如果单机是用索引的话,那连20年前的单机也打不赢)。而对于现在HTAP或者说超融合的多模数据库来说,比如MySQL的HeatWave等列式存储的优势(这里包括MySQL Oracle PostgreSQL TiDB和OceanBase Polardb等等,不一一列举了),使得聚合运算场景上也是可以轻松分析。之所以不少系统还是用OLTP+OLAP的原因,主要是在线的数据库本身不支持列式存储,所以必须要有CDC传输的过程。
2024-01-02 20:13:02 362
原创 我的2023回顾
接着4月参加了恩墨的北京技术嘉年华的大会,和很多老朋友见面,也不断学习中。12月主持了组织了PingCAP的上海站活动,主持并且演讲。11月参加了OceanBase在北京的发布会,感受到了OB的攻城略地和虚心学习。12月中受邀参加了中国软件技术大会,并且做了主题演讲,也结识了史磊和张汉东两位老师。11月也参加和主持了SACC的第一次出北京的活动,我也是伴随着这个大会成长的。8月参加了DTCC,这个是连续十年参会的大会了。是这个大会带我成长的。接着3月参加了PG社区在杭州的大会,和胡辉、彭冲等也线下见面了。
2023-12-29 16:42:44 368
原创 DBA团队的规模应该是什么样的配置?
但是不幸的是,无论是故障分析还是SQL优化、还有数据治理、数据库设计甚至是需求管理,或多或少都有我的身影。我突发奇想在我的群里向各家知名公司的朋友问问他们的DBA的配置如何?阿里 估算1000人左右 这里要说明一下这里是包括(做数据库的,阿里腾讯华为这些公司自己做数据库研发),现在阿里云的DBA不多,据说都自动化了。更多的都是参与到业务的设计、分析、甚至是底层原理的研究上。3.与业务的复杂度合理性成正比,业务越复杂的、合理性越差,就需要较多的人来维护。有其他数据的也可以联系我,补充一下我的知识。
2023-12-25 20:36:28 25
原创 回忆一次时钟问题的解决(简单粗暴)
继续说2008年的时候,我实施过后又一天公安的甲方找我,让我查查为什么时间不对。那时候我还不懂NTP的对时,即使懂,那时候也没条件做。这个误差还真大,我做过了很多项目第一次遇到这个。我想如果我离开后没有人天天过来对时,时间一长必然误差很大。最后不得已我想到的一个办法是,既然一天24小时慢90多秒,那么平均每个小时大约慢4秒。于是我想到了一个思路,做了一个程序后台运行。当地公安在我们系统中查到了一个公安部A级通缉令的人和行车记录,从而判定了他的出逃路线。由于每次关灯时间都不一样,我徒弟说说这一看就是为人的。
2023-12-13 15:05:57 30
原创 开源既然不免费那么花钱了吗?
因为如果每个开源数据库的都是付费的(尊重知识产权以及付给尊重从事该数据库的人相应的收入),那么就一定用不起这么多开源软件。因为,考虑到开源是值钱的,那么付出昂贵的人力成本就会仔细考虑,把少量的技术栈用精。这主要是肤浅的仅仅觉得免费(白嫖)软件就是不要许可了,但是没有看到这些软件所在的硬件不能免费(但是就是故意不计入其中)。新任IT总监不懂IT只看成本,上任就直接干掉原来Oracle原厂招过来的两个DBA,从市面招便宜的DBA用数量来堆,然后业务系统经常中断。这个故事就说明了,使用开源,用的好其实不便宜。
2023-12-04 23:25:36 100
原创 说点JSON使用的注意事项
开发人员提出他的场景中需要使用JSON(这个之前我推荐过,现在Oracle和MySQL的JSON都普遍使用,毕竟有了这个减少了数据库的表的变更也是好的)。我的原则是不参与业务逻辑的、不参与运算的、不用来当where条件的可以放在JSON中,反之不要放进来。{"tel" : "137", "company": "ouyeel", "name" : "张","address":"宝山"}
2023-11-29 15:46:55 35
原创 SACC参会收获和心得
读过我公众号的朋友知道我是从2013年开始一次偶然的机会参加DTCC的,中国数据库技术大会。安排的嘉宾一个都不认识所以事先做了很多沟通,但是现场变数太多,导致很多安排也被打乱了。在多云专场我听到了许多不一样的视角的内容以及我从来没有思考过的多云问题。本次大会参与了向量的专场,多云数据库的专场以及我自己主持的FinOps的专场。
2023-11-26 21:58:22 28
原创 记OceanBase发布会, 叙旧、知新与分享
我在TiDB和OB的原厂交流中,这几个头部企业坦然说到了和Oracle的差距,也在学习。引用吕老师的话说,没搞过Oracle的,但又是数据库圈里的人,特别做数据库开发的,对Oracle的印象就是:集中式、落后、旧时代的产物,超过Oracle很简单,基于Poxos/Raft,随便上个分布式就可以了。反观Oracle的格局是什么:我接触过的Oracle的人听他们说,Oracle支持国产信创政策,但这不是一早一夕,需要很长一段时间,将会一直陪伴着客户走完国产信创之路,可能5年,可能10年,可能20年。
2023-11-18 19:04:42 27
原创 其实专家也有不少不会的
我自己说自己是十八般武艺样样稀松,因为不少厉害的专家是某个领域从源码都清楚的,我就是面广一点,每个都不精通。所以我还是有很多不会的。无一例外,每到一家公司,刚来时候就是处理过陈年旧账的问题或者迫在眉睫的问题,这些问题100%是应用开发的问题。不少朋友都说捧了我,其实我就是主动或者被动接触的数据库多一点,Oracle、MySQL、PostgreSQL、Redis、Elasticsearch、MongoDB、Hadoop全家桶、列式数据库、时序数据库、图数据库还有达梦、OB、TiDB等等都学习或者使用过。
2023-11-06 22:28:50 22
原创 替换数据库的代价与真假国产
即使是我这样学习了很多,但是作为企业员工要铭记,不能为了彰显自己会的多,会的数据库就都上。就我个人而言ACE是Database方向,即可以说是Oracle的也可以说是MySQL的,平心而论我的MySQL水平高于我Oracle的水平。而日常我看到不少手机用苹果的,笔记本用MAC的,开着特斯拉或者用IPad的,对我说要替换某某国产数据库。这些人可能不参与开发,不参与运维,不参与采购,属于站着说话不腰疼的。就是这个不被看好的时候就做的是还可以的,最起码不是骗人的。不止一个朋友和我说,他们买的是真贵,死贵死贵的。
2023-11-01 21:02:37 27
原创 用数字化说一下为什么很多时候报表其实不用大数据
之前我写过一篇《你没有大数据》那一篇被阅读的也很多。我这里说的是大部分企业,少数公司有这个场景的可以使用。不过即使大数据为未必使用Hadoop。Oracle和PG都有组件或者衍生途径去实现列式存储,那么对数据分析是有利的。MySQL当然也有只是目前在企业版中,在云上有。所以他相比较其他不太适合做分析。但是今天我就用这个不太适合做分析的数据来说一下为什么一般企业不用大数据。构造两个表,表big表示企业的业务主要数据。写了个脚本写入了几千万数据。
2023-10-25 23:00:15 22
原创 数据库性能的卖家秀和买家秀
这是因为官方的数据都是实验室的理想数据,而实际环境是非常恶劣的。基于以上的结论,乱写导致的性能问题,在分布式数据库上OB和TiDB等也会出现问题,这个和单机还是分布式没有关系。迪丽热巴穿的好看的衣服,一个200斤的人去穿,别说好看了,衣服会不会OOM被撑开都两说,这和单独上衣还是连衣裙没关系。我别的没有,这方面的血泪教训太多了,而这些在互联网公司是不多见的,这和企业的基因有关。这就是我说的数据库性能的卖家秀(认为设计师良好的,开发是高水平的),而实际上是只有厂商想不到的,没有开发人员做不到的。
2023-10-17 20:59:36 19
原创 一次Elasticsearch的问题分析
es作为搜索引擎数据库用作全文搜索是不错的,但是真正用到es的不多,不少场景可能用MySQL、PG甚至Oracle都可以很好的完成,只是缺乏专人的设计和把控。不过我的ES水平也有限,只能处理简单的场景。一样宕机,因为这个NoSQL的配置已经不低了,但是还是出现了问题。ES也是一样,它的命令虽然不能叫做SQL,但是也可以这样叫。因为现在的ES似乎是从6开始是支持的SQL。这就是典型的前后%在关系型数据库中禁止的,到这里来用硬件资源抗了。es数据库又名全文索引,它的索引其实就是传统数据库上的表。
2023-10-07 16:41:40 43
原创 单一数据库拆分成几十个数据库的意义
如果懂数据库的就知道任何一个关系型数据库,如果用户登录这种信息采用关系型数据做的话,就是一个点查的场景,建立好索引。领导尴尬的说,嗯,够用就行。为此有些经验丰富的人不仅感慨“一台一体机能搞定的事,有些人强行拆成几百台x86,不知道图的啥,收益是啥,投入产出比高不高?我了解了以后说你们几十个系统都是一个数据库实例,就是不同的schema,甚至有的还是一个schema。原文如下:慕容博道:“不错,其时我慕容氏建一支义旗,兵发山东,为大辽呼应,同时吐蕃、西夏、大理三国一时并起,咱五国瓜分了大宋,亦非难事。
2023-09-24 10:43:42 32
原创 一次执行10天的SQL
这5行是 A表的id=1扫描了1行, B表的count子查询计算时候扫描了2行,B表的sum子查询计算时候扫描了2行,B表需要name字段又扫描了2行。这25行是 A表的全表扫描了5行, B表的count子查询计算时候扫描了10行,B表的sum子查询计算时候扫描了10行。这5行是 A表的id=1扫描了1行, B表的count子查询计算时候扫描了2行,B表的sum子查询计算时候扫描了2行。比起带索引时候的25行多了4倍多的扫描行数正式环境的表如果行数多(全表5行,没有索引,多了4行就多4倍。
2023-09-14 17:22:36 21
原创 MySQL undo膨胀了怎么办?
首先需要新增加一个undo文件。因为默认有两个,收缩的时候需要两个在线工作。innodb_max_undo_log_size = 10M --回收后的初始状态一般是16M,即使这里设置是10M,最终通过实验测试得出也是16M。innodb_undo_tablespaces = 3 要保证至少有3个undo文件。以上设置到参数文件以后,需要重启数据库。默认配置不会自动收缩。检查undo002的文件已经收缩完成。将undo_002的undo文件设置成为不活动。按照提示处理后,增加了一个undo文件。
2023-09-13 09:16:18 101
原创 闪回冲突怎么办?
方案2:假设原始表是sh4,误删除以后。新建立了sh4,还写入了数据。那么闪回时候兼带改名字,一气呵成。从Oracle10开始就有闪回,这个功能多次起到力挽狂澜的作用。而如果被drop的表,重新建立了。那么在执行闪回时候就出错了。方案1:把新建的sh1改个名字,改成sh3.再闪回sh1.传统的误删除表后,执行闪回sh2表的数据被找回来了。此时sh1中有2行数据,sh2中有1行数据。有两个表,分别是sh1和sh2。方案2也是最近才在实际中用过。遇到这个问题有如下解决方案。
2023-09-12 21:03:45 29
原创 MySQL字符集带来的问题
可以看到两个表在这个字段上的字符集有一点差别,另外有差别的还有存储引擎都不是同一个。所以经常会有同一个系统中的不同的表会有不同的字符集,甚至一个表上不同的字段也有不同字符集(因为是多人协作的)。utf8mb4_0900_ai_ci 和utf8mb4_general_ci 这两种字符集区别在于带前者是带重音(一般不需要设置这种),后者是对大小写不敏感,如果需要大小写敏感。以上现象可以结合实际调整,很多人觉得自由度大可以随便调整,其实我个人觉得自由度太大也有很多不好的地方,这些设置规定好不要太过自由的发挥。
2023-09-04 16:33:43 46
原创 MySQL的特殊的表膨胀
再次写入insert into select写入,但是执行回退后。数据未能写入,但是表现在大小是163840字节。结果是表变大了,这个结果可能和大多数人想象中的不一样。大多数人可能觉得回退后,数据没有写入数据文件。这个迁移过程我知道,中途还有insert into select的动作。但是处理的数据有点大,导致处理失败。其实很多数据库即使处理大事务,但是提交会很快。因为这些过程的数据和日志也都一直在写,所以最后提交很快。那也就是这里可以证明,为什么案例实际导入10G,但是占用空间很大。
2023-08-15 14:04:58 114
原创 早就说了连接数别太多呀
一般来说,连接数据库以后use database以后会打开表(结构)缓存,Opened_tables(当前会话)新会话是0.use某个database以后,这个值会增加,目前是从0变到212。有了这个认识以后,那么假设连接会话对相应的database进行use的话,那么缓存的表就是连接数乘以表的数量。最多的连接用户分别是15和20,对应的表的数量分别是89和136.所以两个加起来基本是就是4000左右的样子。本次场景是MySQL问题,有人问我监控显示,表缓存使用率99%,当前为100.0%。
2023-08-13 20:04:35 34 1
原创 一次误解造成的问题
这里的T是同一个表,即,自己的一部分数据进行分组统计后再插入回到原本中。这里就是问题所在了,汇报的时候说写入数据是10几万。由于实际SQL写的复杂,都是多表连接的,背后select的都是乘以N倍的运算量。最后说一句,insert into table select 性别,count(*) from 中国人口,最终数据是2行,但是要知道这是扫描了14亿才出的2行啊。这个时候要打开问题来分析一下,否则容易出现误会,觉得的是数据库什么参数不对,或者数据库不行,才十几万就不行了。答复10万多数据,插入要很久。
2023-08-10 21:00:25 30 1
原创 这些SQL看着就违法
那用一个数据库几乎都解决了加班的问题,甚至加班解决不了的问题也解决了。他毫不客气地从生产线上抓起一个刚刚制造完成的降落伞包,砰的一声扔在了工厂的负责人脚下。他不明白,如此重要的装备怎会出现如此严重的问题,不禁愤怒不已。从那一天起,这个工厂的降落伞的质量发生了天翻地覆的变化。每一个零部件的检查,每一次装配的过程,每一次最后的成品测试,都严谨得像是在执行军事命令。因为他们知道,每一个不负责任的失误,都可能要求他们的负责人用自己的生命去付出代价。如果都有敬畏心,其实即使一个路口没有车,也会等着红的。
2023-08-08 22:20:10 54 1
原创 硬件一小步,软件一大步。
工作时间久了估计不少人也有同感,就是专业的给出解决方案有多种,有治标的也有治本的。) 治本的成本当然也不低,就是直接推倒重来,节约的是不断加固的人力物力和财力。既然是IO问题,硬盘IO不是简单加硬盘就能解决,我想的就是增加内存。小结一下:数据库的优化是要一开始做对成本最低,一开始做对要求专业的人来设计(这个人可能不便宜,但是比起后期返工成本算低的)或者是一堆精通数据库的开发人员(这个价格应该不比那个总监成本低)。我去年还参加了信通院主持的数据库一体机的标准制定,这个虽然是团体标准,至少也有了标准了。
2023-08-01 22:22:23 18
Pulsar问题无法调用SQL命令
2021-08-12
TA创建的收藏夹 TA关注的收藏夹
TA关注的人