- 博客(1436)
- 资源 (8)
- 收藏
- 关注
RSS订阅原创 AI 很聪明，但就怕脑子失忆，记忆对AI很重要
这一切都意味着，下次当一个 AI 助手流畅地回忆起你上次的对话，或者根据你几周前提到的小习惯调整回答时，幕后都有一个数据库在默默地工作，充当着这个机器合成大脑的记忆库。通过用从数据库中获取的数据来增强提示，AI 系统可以随着时间的推移进行连贯的对话，并准确回答特定领域的问题，从而获得超越其固定模型参数的状态和长期记忆。这听起来不那么性感，但却是必不可少的。AI系统从讨论已经到了大家都在使用的阶段，而众所周知AI系统的关键问题，或者需要处理好的一个关键问题就是，连续提问的问题，因为AI聪明的，没有记忆。
2025-08-22 06:02:00
583
原创 从某数据库信任“危机”，简谈危机公关
但同时市场和危机公关他们不是“上帝”，市场和危机公关存在很多变幻莫测的部分，一个正常的操作，第一时间确认信息，并进行公告，任何沉默和逃避只会让信息传的越来越变味，透明处理，通过有效渠道对发生的问题，进行正面的应对，同时一般危机公关的窗口期在48小时，但在国内整体的媒体发达和自由以及多渠道的情况下，留给危机公关的时间会更短。尤其数据库付费的市场，党政企事业单位。2 制定策略，对马上到来的各种负面的猜测，友商的销售和企业营销的方式做出反应，预测即将到来的竞品的反向营销，以及制定预计的方法进行应对。
2025-08-21 06:01:09
672
原创 邦邦硬的PostgreSQL技术干货来了，怎么动态扩展PG内存 ！
我简短节说，本次将从里到外的把PG的内存部分给大家讲明白，王老师是负责 PolarDB for PostgreSQL的动态内存的核心开发负责人，所以PG内存是怎么个构造没有比他在明白的人了，然后他还把PG的内存改成了动态扩展的内存，否则我怎么用上的 PolarDB for PG的serverless，稍微用过PG的都知道，PG不能和MYSQL一样动态扩展buffer pool，王老师凭着自己的PG核心代码的能力，给你把PG改成了动态扩展内存，不重启，不reload的模式。（附送定期清理连接脚本）
2025-08-20 06:00:19
599
原创 数据库信创话题能碰吗？ 今天斗胆说说
这些例子都不用举了，电动汽车和高铁就是明显的例子，说到这类，应该有不同的观点，我也听到过这些观点，而这些观点产生的原因没有人分析。，国产数据库稳定格局产生后，有几个产品占领大部分国内的核心企业，满足国内政府和核心企业数据库安全的需求，信创政策红利就到了该收紧和后期退出的准备了，自由的市场和能力的角逐才是永恒的重点。5 数据库行业的内卷和竞争如果超出了国家的预期，内卷已经对整体国家数据库产业有影响的时候，国家会出手进行监管干预，如同现在的电动汽车的反内卷的国家介入方式。农业是国力的基础，提供粮食和税收。
2025-08-19 06:00:15
965
原创 企业出海数据库设计问题一角，与政策动荡下的全球数据库产品
这是非常，非常糟糕的。但是如果你出国了，你的服务器在新加坡，他和北京的时间一样都是+8：00,可你的客户在日本和越南的情况下，他们一个时区是+9:00，一个是+7:00，他们使用一张表，MySQL的表记录的时间是+8:00的时区，这就导致展示给日本和越南的客户的时间是+8:00的时间。从业务的角度，企业出海后，业务表中的时间存储是一个关键问题，比如日本，菲律宾，越南，新加坡，马来西亚等这些国家的时区是不同，不同的客户在不同的时间区域产生的数据记录的时间如何进行处理是一个大的业务逻辑问题。
2025-08-18 06:00:49
951
原创 《数据库江湖邪修门派：心法五式全解》
这就和坐地铁和公交一样，明明你做5站到地方正好，你不，你非要做10站地，技术修炼要有度，该你哪站下车，哪站下，甲方需要的是综合类的DB人员，公司的数据库不管是国产的，进口的，分布式的，嵌入式的，都可能归你，你要做的不是100%精通一个数据库，而是在熟悉一个数据库后，搭建自己的框架，可能网上看到的数据库难题你这辈子都遇不到，但你去在那个地方下功夫，而日常的，看日志，写脚本，明白业务流程，有处理故障的梳理方式都不懂，你在单位你是某个数据库的专家不重要，你能解决公司的各种问题才是你在公司活下去的根本。
2025-08-15 06:00:34
828
原创 微软动手了，联合OpenAI + Azure 云争夺AI服务市场
微软核心 AI 部门产品副总裁 Yina Arenas 在一篇博客文章中写道，这一研究自动化能力的整合得益于 Deep Research API 和 SDK，开发者可以借此将“深度研究即服务”嵌入、扩展并编排到企业生态系统中，包括现有的数据和系统。今天继续我们的境外新闻，让大家了解一下外面的世界都在干什么，天天光看自己这块地以为挺不错，只是政策阻隔了那些列强，如果他们还能回来，我们又会怎样。写了3750万字的我，在2000字的OB白皮书上了一课--记 《OceanBase 社区版在泛互场景的应用案例研究》
2025-08-14 06:01:52
889
原创 “当复杂的SQL不在需要特别的优化”，邪修研究PolarDB for PG 列式索引加速复杂SQL运行
1 通过 polar_csi.memory_limit 的方案默认这个memory_limit使用的是1024MB，这是指的向量化引擎可以使用的内存大小，我们将默认的1024改为2048后，我们在次查询，查询速度提高了224ms,占原有速度的25%，提高可4分之一的查询速度。写到结尾：作为一个邪修DBA架构，我就是愿意和别人不一样，走那些走烂的路，一条路别人走过，你在走只能叫尾随，如果是你第一个走，你叫开拓者，生存的意义最终都是在争夺第一次，不是吗？（附送定期清理连接脚本）Look my eyes!
2025-08-13 06:01:09
844
原创 “合体吧兄弟们！”——从浪浪山小妖怪看OceanBase国产芯片优化《OceanBase “重如尘埃”之歌》
OceanBase对内存管理优化，尤其在ARM平台中对缓存和内存的对齐更加敏感，OceanBase针对ARM L1/L2缓存进行了优化，使用更轻量的allocator进行slab级别内存的切分，通过通过LSM TREE存储部分针对ARM做了特定的适配。普通平凡人，每个人都很渺小，就像浪浪山的小妖怪们，四个小妖怪是无论如何都打不过“大肚弥勒佛”的童子。2 如同浪浪山小妖怪的合体的技术，也和我们经常说的一句话，人多力量大，通过分布式的技术来解决低端硬件带来的单体数据库性能差距的问题，交付给关键的环节使用。
2025-08-08 06:01:17
704
原创 境外传统云三巨头，迎来2个云刺客的“攻击”
CIO 或许能签署 Oracle 的云合同，但真正构建未来应用的开发者，往往选择的是自己熟悉、喜爱的开发平台。这些举措正逐步改变其“云落后者”的形象，尤其是对已有 Oracle 软件部署的客户而言，Oracle Cloud 成为了一个可信赖的升级路径。但境外的三大云厂商正在接受2个云刺客的攻击，一个是我们熟悉的ORACLE OCI，另一个是我们不熟悉的Cloudflare，而这两家云企业都在用不同的方式去抢夺自己的市场份额，到底是境外是云三国，还是5魁首，我们看看下面的境外分析。但这并不妨碍其价值。
2025-08-07 06:01:48
405
原创 数据压缩60%让“PostgreSQL” SQL运行更快，这不科学呀？
所以提出这个问题的同志的担心是有必要的，但这里需要说明PolarDB for PostgreSQL的压缩是硬件压缩，也就是磁盘本身有压缩的功能，基于存算分离的设计和特性，这里磁盘的压缩和计算CPU是无关的。在测试中出现了一个与大部分人想法相反的情况，压缩的PolarDB for PostgreSQL 要比不压缩的IOPS低，也就是执行同样的指令尤其在数据UPDATE的操作中，压缩的PolarDB for PostgreSQL IOPS要更低。（附送定期清理连接脚本）Look my eyes!
2025-08-06 06:00:17
835
原创 未知黑客通过SQL SERVER 窃取企业SAP核心数据，影响企业运营
💣利用 SAP 漏洞及其他公开漏洞 在 2025 年 7 月，EclecticIQ 披露 CL-STA-0048 是多个与中国相关的网络间谍组织之一，曾利用 CVE-2025-31324（SAP NetWeaver 中一个关键的未认证文件上传漏洞）建立反向 Shell，控制受害主机。这种技术在中国攻击组织中非常常见。威胁组织利用 SAP NetWeaver 严重漏洞，攻击扩展至巴西、印度和东南亚，受损企业的核心业务数据，财务数据以及营业数据将有可能被攻击和窃取，将给企业带来严重的运营风险。
2025-08-05 06:00:41
913
原创 那个MySQL大事务比你稳定，主从延迟低，为什么？ Look my eyes! 因为宋利兵宋老师
在使用行级复制的时候，我们难免遇到大事务，而大事务如果较大会导致超过了binlog_cache_size 的设置，最终产生磁盘的临时文件，而这个临时文件可是要跟着你的 binlog 文件的，这一个过程会占用磁盘空间，占用磁盘空间不怕，而更可怕的事会导致其他的事务提交慢，阻塞其他事务，产生MySQL的事务提交卡顿。着急的MYSQL RDS 至少解决了这个大事务不稳定和主从延迟的问题，不信你就试试，当然这只是人家宋老师的优化和改造的冰山一角。说这个问题前还的说那个外国的MySQL专家的这篇文章。
2025-08-04 06:01:00
672
原创 非“厂商广告”的PolarDB课程：用户共创的新式学习范本--7位同学获奖PolarDB学习之星
云数据库的确和传统数据库非常的不一样，以前我们在传统数据库上不敢想的事情，在云原生数据库上都不见得是难事，而云上数据库要做的更好，更稳定赢得更多客户的信任，努力和信任都是双向的，希望此次的课程能给双方搭起一座桥梁，共同进步，不会止步不前。课程中我们有很多的问题，比如一些技术的细节还不够精确，一些文字的部分，视频的部分，有很多需要雕琢的地方，但是这的的确确不是一次 “厂商”的广告，有很多地方在文章中，大家也可以看到，与普通广告有很大区别的地方。（附送定期清理连接脚本）用MySQL 分区表脑子有水！
2025-08-01 06:00:59
799
原创 国外MySQL“专家“剑指MySQL严重事务问题--国内MySQL专家阿里云宋利兵老师解决问题
这种行为解释了您在第一张图表中观察到的，在超过 60 分钟的时间里，数十 GiB 磁盘空间被缓慢持续消耗的现象。现在你大概已经猜出来了是一个大事务导致了大量的二进制日志生成这些 binlog 填满了磁盘空间，最终导致了 MySQL 的崩溃，不过在原版 MySQL（而非已做优化的分支中），二进制日志写入其实需要“双倍磁盘空间”！（提示：Binlog 写入机制） 如果你还不太理解上述现象，请阅读我上一篇博客，里面解释了大事务的 binlog 是如何写入的（先写临时文件，再复制），以及这如何导致空间占用翻倍。
2025-07-31 06:00:24
1016
原创 国外MySQL“专家“剑指MySQL严重事务问题--国内MySQL专家阿里云宋利兵老师解决问题
这种行为解释了您在第一张图表中观察到的，在超过 60 分钟的时间里，数十 GiB 磁盘空间被缓慢持续消耗的现象。现在你大概已经猜出来了是一个大事务导致了大量的二进制日志生成这些 binlog 填满了磁盘空间，最终导致了 MySQL 的崩溃，不过在原版 MySQL（而非已做优化的分支中），二进制日志写入其实需要“双倍磁盘空间”！（提示：Binlog 写入机制） 如果你还不太理解上述现象，请阅读我上一篇博客，里面解释了大事务的 binlog 是如何写入的（先写临时文件，再复制），以及这如何导致空间占用翻倍。
2025-07-31 06:00:24
703
原创 国外MySQL“专家“剑指MySQL严重事务问题--国内MySQL专家阿里云宋利兵老师解决问题
这种行为解释了您在第一张图表中观察到的，在超过 60 分钟的时间里，数十 GiB 磁盘空间被缓慢持续消耗的现象。现在你大概已经猜出来了是一个大事务导致了大量的二进制日志生成这些 binlog 填满了磁盘空间，最终导致了 MySQL 的崩溃，不过在原版 MySQL（而非已做优化的分支中），二进制日志写入其实需要“双倍磁盘空间”！（提示：Binlog 写入机制） 如果你还不太理解上述现象，请阅读我上一篇博客，里面解释了大事务的 binlog 是如何写入的（先写临时文件，再复制），以及这如何导致空间占用翻倍。
2025-07-31 06:00:24
710
原创 国外MySQL“专家“剑指MySQL严重事务问题--国内MySQL专家阿里云宋利兵老师解决问题
这种行为解释了您在第一张图表中观察到的，在超过 60 分钟的时间里，数十 GiB 磁盘空间被缓慢持续消耗的现象。现在你大概已经猜出来了是一个大事务导致了大量的二进制日志生成这些 binlog 填满了磁盘空间，最终导致了 MySQL 的崩溃，不过在原版 MySQL（而非已做优化的分支中），二进制日志写入其实需要“双倍磁盘空间”！（提示：Binlog 写入机制） 如果你还不太理解上述现象，请阅读我上一篇博客，里面解释了大事务的 binlog 是如何写入的（先写临时文件，再复制），以及这如何导致空间占用翻倍。
2025-07-31 06:00:24
658
原创 国外MySQL“专家“剑指MySQL严重事务问题--国内MySQL专家阿里云宋利兵老师解决问题
这种行为解释了您在第一张图表中观察到的，在超过 60 分钟的时间里，数十 GiB 磁盘空间被缓慢持续消耗的现象。现在你大概已经猜出来了是一个大事务导致了大量的二进制日志生成这些 binlog 填满了磁盘空间，最终导致了 MySQL 的崩溃，不过在原版 MySQL（而非已做优化的分支中），二进制日志写入其实需要“双倍磁盘空间”！（提示：Binlog 写入机制） 如果你还不太理解上述现象，请阅读我上一篇博客，里面解释了大事务的 binlog 是如何写入的（先写临时文件，再复制），以及这如何导致空间占用翻倍。
2025-07-31 06:00:24
941
原创 国外MySQL“专家“剑指MySQL严重事务问题--国内MySQL专家阿里云宋利兵老师解决问题
这种行为解释了您在第一张图表中观察到的，在超过 60 分钟的时间里，数十 GiB 磁盘空间被缓慢持续消耗的现象。现在你大概已经猜出来了是一个大事务导致了大量的二进制日志生成这些 binlog 填满了磁盘空间，最终导致了 MySQL 的崩溃，不过在原版 MySQL（而非已做优化的分支中），二进制日志写入其实需要“双倍磁盘空间”！（提示：Binlog 写入机制） 如果你还不太理解上述现象，请阅读我上一篇博客，里面解释了大事务的 binlog 是如何写入的（先写临时文件，再复制），以及这如何导致空间占用翻倍。
2025-07-31 06:00:24
724
原创 国外MySQL“专家“剑指MySQL严重事务问题--国内MySQL专家阿里云宋利兵老师解决问题
这种行为解释了您在第一张图表中观察到的，在超过 60 分钟的时间里，数十 GiB 磁盘空间被缓慢持续消耗的现象。现在你大概已经猜出来了是一个大事务导致了大量的二进制日志生成这些 binlog 填满了磁盘空间，最终导致了 MySQL 的崩溃，不过在原版 MySQL（而非已做优化的分支中），二进制日志写入其实需要“双倍磁盘空间”！（提示：Binlog 写入机制） 如果你还不太理解上述现象，请阅读我上一篇博客，里面解释了大事务的 binlog 是如何写入的（先写临时文件，再复制），以及这如何导致空间占用翻倍。
2025-07-31 06:00:24
254
原创 国外MySQL“专家“剑指MySQL严重事务问题--国内MySQL专家阿里云宋利兵老师解决问题
这种行为解释了您在第一张图表中观察到的，在超过 60 分钟的时间里，数十 GiB 磁盘空间被缓慢持续消耗的现象。现在你大概已经猜出来了是一个大事务导致了大量的二进制日志生成这些 binlog 填满了磁盘空间，最终导致了 MySQL 的崩溃，不过在原版 MySQL（而非已做优化的分支中），二进制日志写入其实需要“双倍磁盘空间”！（提示：Binlog 写入机制） 如果你还不太理解上述现象，请阅读我上一篇博客，里面解释了大事务的 binlog 是如何写入的（先写临时文件，再复制），以及这如何导致空间占用翻倍。
2025-07-31 06:00:24
950
原创 国外MySQL“专家“剑指MySQL严重事务问题--国内MySQL专家阿里云宋利兵老师解决问题
这种行为解释了您在第一张图表中观察到的，在超过 60 分钟的时间里，数十 GiB 磁盘空间被缓慢持续消耗的现象。现在你大概已经猜出来了是一个大事务导致了大量的二进制日志生成这些 binlog 填满了磁盘空间，最终导致了 MySQL 的崩溃，不过在原版 MySQL（而非已做优化的分支中），二进制日志写入其实需要“双倍磁盘空间”！（提示：Binlog 写入机制） 如果你还不太理解上述现象，请阅读我上一篇博客，里面解释了大事务的 binlog 是如何写入的（先写临时文件，再复制），以及这如何导致空间占用翻倍。
2025-07-31 06:00:24
865
原创 国外MySQL“专家“剑指MySQL严重事务问题--国内MySQL专家阿里云宋利兵老师解决问题
这种行为解释了您在第一张图表中观察到的，在超过 60 分钟的时间里，数十 GiB 磁盘空间被缓慢持续消耗的现象。现在你大概已经猜出来了是一个大事务导致了大量的二进制日志生成这些 binlog 填满了磁盘空间，最终导致了 MySQL 的崩溃，不过在原版 MySQL（而非已做优化的分支中），二进制日志写入其实需要“双倍磁盘空间”！（提示：Binlog 写入机制） 如果你还不太理解上述现象，请阅读我上一篇博客，里面解释了大事务的 binlog 是如何写入的（先写临时文件，再复制），以及这如何导致空间占用翻倍。
2025-07-31 06:00:24
911
原创 国外MySQL“专家“剑指MySQL严重事务问题--国内MySQL专家阿里云宋利兵老师解决问题
这种行为解释了您在第一张图表中观察到的，在超过 60 分钟的时间里，数十 GiB 磁盘空间被缓慢持续消耗的现象。现在你大概已经猜出来了是一个大事务导致了大量的二进制日志生成这些 binlog 填满了磁盘空间，最终导致了 MySQL 的崩溃，不过在原版 MySQL（而非已做优化的分支中），二进制日志写入其实需要“双倍磁盘空间”！（提示：Binlog 写入机制） 如果你还不太理解上述现象，请阅读我上一篇博客，里面解释了大事务的 binlog 是如何写入的（先写临时文件，再复制），以及这如何导致空间占用翻倍。
2025-07-31 06:00:24
664
原创 说我PG Freezing Boom 讲的一般的那个同学，专帖给你，看看这次可满意
所以为了保证数据的正确性，如果你让系统无法回收XID，那么就给你数据库冻结上，冻上的数据库不在工作，只能单用户工作，且进去你只能进行XID的回收的工作，直到你让卡主XID被回收，数据库才能再次可以工作。那我也问你一句话，你觉得在你出生的80,90年代，为什么有万元户这个名称，家里有几万块在那时就非常了得了，现在你有几万块的存款那叫穷光蛋，这叫未来的不可预见性，以及快乐的人生法则，我把现在的事情处理好就OK ，我有必要想那么远，所以我理解了PG的设计大师们都是快乐主义和够用就好的理念的实践者。
2025-07-30 06:01:00
586
原创 这个 PostgreSQL 让我有资本找老板要 鸡腿 鸭腿 !!
写到最后，DBA干到最后比拼的是什么，在大部分企业里面，成本的节省是证明一个甲方DBA，或数据库架构选择数据库成功的证明，在保证业务稳定，数据库稳定的基础上，向更先进的数据库进行发展和迁移是当代DBA的重要工作，历史创造机遇这恰恰是属于中国DBA的特殊历史时期。1 PostgreSQL本身的表膨胀的问题，这个问题我们可以通过即时的调整autovacuum的参数，或者类似我们公司，专门开发一套VACUUM自动识别和管理的系统，来在autovacuum不给力的时候，我们自己智能进行整理，避开业务高峰。
2025-07-28 06:01:03
480
原创 PolarDB 非官方课程第八节--数据库弹性弹出一片未来--结课
大家好，这是PolarDB的非官方数据库课的第八课，我们将开启最后一次课程之旅，这当然不是我们学习PolarDB的Ending，而恰恰是我们开始学习PolarDB的开始，今天将给大家带来的是云原生数据库最闪耀的ServerLess部分。
2025-07-24 06:00:24
837
原创 问三个礼拜PostgreSQL问题的那同学，希望这篇让你PG之路一切顺遂
PostgreSQL 数据库开源版本的使用中在归档中容易出现问题，这也是最近有同学在询问并且产生问题的地方，实际上他已经问了我3个礼拜了，各种各样的问题，本篇将针对这个问题进行梳理，方便同学在安装和设置PostgreSQL的工作中遇到问题进行问题对的排查，所以千万别拿PostgreSQL当MySQL，他比那个MySQL要难得多，关联性问题比较多，顾此失彼想问题的不少。第三个问题，WAL的归档为什么拷贝到了归档的目录，PG_WAL的文件数还是没有下来，PG_WAL的文件夹的文件数还是那么的多。
2025-07-23 06:01:59
606
原创 PolarDB 非官方课程第七节--数据备份还原瞬间完成是怎么做到的--答题领奖品
其实说到数据备份和恢复，这个问题大多使用开源数据库产品，且需要经常恢复数据的DBA是非常痛苦的，大库恢复数据无论是mysql,postgresql,都并不是一个轻松的工作，单线程的时间点的日志恢复，经常是数据恢复的噩梦。时间过得真快，已经是PolarDB 非官方的免费课第7节了，本节我们将说一说数据的备份和数据库的恢复，同时我们来说一说，PG的一个严重的问题在数据存储成本上，而PolarDB for PG不存在这个问题。3 没有拿到过奖品的同学，有更多在每次答题中有优先获奖的权利，对比拿过奖品的同学。
2025-07-22 06:01:11
974
原创 开源软件在China“是”一场“傻瓜”被“白嫖”的游戏
这要从历史和当前中国发展的角度来去看深层次的问题，我们借用上面一书一个外国人对于我们的早先的祖辈的看法是什么，他的看法是片面的，也不重要，他也仅仅代表一部分“开源”文化兴盛地带的人对这片土地的人片面的看法。2 开源软件的开发者，希望通过开源源代码的方式，将产品通过其他的开发者的参与为现有开源的软件进行整改或者添加功能，或修复软件的BUG等方式，提高开源软件的为客户服务的能力。开源是开发者将自己开发的软件产品，以无偿的方法将源代码进行公开的行为，但并不是说开源的软件产品是免费的，这二者没有对应的关系。
2025-07-21 06:00:38
843
原创 Oracle “嫁给” AWS-疯狂的Oracle 疯狂的计划 -- 另附DBA 招聘信息 附带薪资待遇
一位 Oracle 发言人表示：“我们现在已经在两个区域正式上线（GA）：AWS 美国东部（弗吉尼亚北部）和美国西部（俄勒冈）区域，提供 Oracle Exadata 数据库服务和 Oracle Autonomous Database（自治数据库），部署在 AWS 中的专用 OCI 基础设施上。Oracle Database@AWS 于去年 12 月进入有限预览阶段，首批注册客户可在美国东部（弗吉尼亚北部）区域试用部署在 AWS 中、基于 OCI 的 Oracle Exadata 数据库服务。
2025-07-18 06:00:23
759
原创 PolarDB 非官方课程第六节--数据库归档还能这么玩--答题领奖品
现在我们服务的甲方客户，经常提出数据库性能不要，要求数据归档，在归档中甲方提出，有的时候数据还要在恢复，因为归档的数据有一些不确定后面是否还要用，但是不确定的可能性比较低，但是要做好数据恢复的方案，同时要求数据恢复要快，能以最快的速度把数据读取，然后在删除。不应该使用PolarDB for PostgreSQL对字段进行存储分离的操作，这将大大影响表在使用该字段提取的效率，同时如果要删除表的情况下，表本身的的数据存储在两个地方，对于清理操作也有不便，所以数据库提出的功能和能正常进行使用是两个概念！
2025-07-17 06:00:35
736
原创 从MySQL不行了，到乙方DBA 给狗，狗都不干？ 我干呀！
2 技术资源：技术资源并不是说非要精通某项技术，而是对行业的大部分数据库技术都了解，作为一个数据库主板，你身上的插槽越多，你能接的活就越多，这也是很多乙方DBA ，成为考证侠的原因。说到数据库，说到乙方DBA，有句话叫给狗都不干乙方DBA，实际上DBA这个职业，不准确的估算至少60-70%的DBA都是乙方公司的，甲方的DBA其实并不多。我们愿意听到的是完整，全面，利弊都分析的看法。虽然没有干过乙方的DBA，但我还是知道加班，背锅，挨骂，等等存在的问题，但甲方的DBA也存在这样的问题，这里就不展开了。
2025-07-16 06:00:56
841
原创 PolarDB 非官方课程第五节--PolarDB代理很重要吗？--答题领奖品
视频中我们提出不建议大家使用全事务拆分，怕产生业务逻辑的错误的部分，这个地方需要更新，在任何的情况下全事务拆分是不会产生业务逻辑的问题，因为全拆分后，事务里面虽然有读和写，但不会有乱序的情况，也就是在一个事务里面从节点是基于MySQL的REDO Log 进行的物理的复制，不会和MySQL一样如果全部拆分后，会有逻辑业务乱序的问题，因为PolarDB默认如果从库读不到会直接切换到主库去读，又基于主从节点数据一致性的原理的驱动型，全事务拆分是不会出现业务逻辑错误的问题。（此问题不在视频中，而在文章的文字中找）
2025-07-15 06:01:13
978
原创 某云在 德国“柏林” SIGMOD大会放“大招” 与 DTCC 16年DB的变化
与主流云厂商不同的技术路径 Eigen+ 采用的是基于分类的内存管理方式，而 AWS、Azure 和 GCP 等云服务商主要依赖基于预测的内存管理策略。云是下一代IT工作者的主要阵地，基于前瞻性和未来的发展，尤其在数据库云化越来越严重的今天，世界性的企业上迁到云上的趋势非常的明显了，集约式的工作方式，你去问一个企业，你是愿意在经济前景不明朗的今天，自己的购买主机，网络设备，雇佣一堆的基础设施建设的人，还是只需要一根网线，就可以和世界进行连接，事实已经给我们答案了。尤其是在数据库领域，风险尤为严重。
2025-07-14 06:01:18
931
原创 DBA 的《天空没有极限》--IF Club 宣传片拍摄全过程--谁是钢铁玫瑰！
然后此时女汉子，高老师直接就上到了那个4米高的墙上，然后取景，因为这样才能没有人能打扰，且镜头“干净”，最后解释一下，为什么全程我都不露脸，并不是因为我长得不好看，主要是艺术风格，这不是一个介绍我个人的短片，介绍不介绍我并不重要，谁让我叫有趣的灵魂，从不循规蹈矩，我在这里代表的就是所有人，所有迷茫，焦虑，苦恼的人，我们不甘平庸，我们一直在寻找和自己同频的人，最终让一个不完美的自己，体会更多人生的乐趣，让IT人在IF CLUB这个自由的舞台，去展现自己，释放自己，去挑战我们每个人的天空极限。
2025-07-11 06:01:20
385
原创 PolarDB 非官方课程第四节--PG实时物化视图与行列数据整合处理--答题领奖品
PolarDB for PostgreSQL 从实际的应用性上改变了这个问题，在PolarDB for PostgreSQL 支持实时物化视图，提高了整体开发的针对复杂查询的灵活性和相关的数据库语句执行的性能。基于PostgreSQL的强大，越来越多的人使用PostgreSQL数据库产品，在从云下到云上的过程中，我们对于PostgreSQL存在的一些问题，能否解决还是延续需要做出抉择。如果不对哪里错误了？拿到奖品两次后，积极回答问题的同学，将进入下一个环节，学习之星的评选，我们将对这些同学有新的奖励模式。
2025-07-10 06:00:23
779
原创 OceanBase Hybrid search 能力测试，平换MySQL的好选择
小结：在进行OceanBase简短的Hybrid search 后，你的公司在云端或是有混合云的打算，且需要Hybrid search能力，但整体的系统希望在兼容MySQL数据库系统上，可以考虑平行迁移到OceanBase MySQL 兼容的云端系统上，因MySQL已经无法再混合搜索，向量搜索再有建树，未来的大量业务将需要向量和hybrid search的能力，如HNSW 等，建议有实力且业务想继续发展的公司可以考虑在往前走一步。从实例，业务，开发角度分析 PolarDB 使用不会像MySQL那么Low。
2025-07-09 06:00:19
696
原创 PolarDB 非官方课程第三节--MySQL+IMCI=性能怪兽--答题领奖品
这是PolarDB 的第三节课，这节课里面我们将开始接触技术，我们先从大家最感兴趣的提高MySQL的性能入手，针对复杂的SQL的问题如何解决，来切入PolarDB for MySQL的使用具体的方案。通过使用IMCI，数据压缩了，存储在列存中，还可以并行计算，将数据装入到内存中进行处理，列式的计算引擎+列式存储+可动态添加的列式节点，让PolarDB for MySQL 变成了性能小怪兽。我们对比一下在PolarDB for MySQL，三张表数据量分别在1百万，10万，1万，三个表进行关联操作。
2025-07-08 06:00:27
686
MYSQL percona server manual
2018-03-17
70-457 SQL SERVER 2012 考试真题 有效期2014 -6-15
2014-03-14
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人