-
从“存储过程变慢”到“异常 SQL”：先找事实，不急着猜原因
一次常规的分区 SPLIT，叠加索引重建和统计信息收集，可能让优化器基于错误基数重新选路。本文还原一个制造业生产案例，并给出可落地的变更检查清单。 在数据库运维里，最危险的事情往往不是一眼就能看出来的，而是“每一步单独看都合理，组合起来却出了问题”。 一次分区 SPLIT 就是典型场景。它看起来只是把一个分区拆成两个分区；但它同时会触发索引维护、游标失效、硬解析和统计信息变化。如果恰好有一项统计信
-
C 姐逛云栖｜从数据库到 Agent，今年大会上我们看到了...
C 姐逛云栖｜从数据库到 Agent，今年大会上我们看到了... 今年科技圈的固定节目云栖大会又来刷屏了，5 万多平场馆、超 10 万人报名，主题从去年的「碳硅共生」换成了「智以致用」。跟着 C 姐逛完一圈，最明显的感受是：前两年大家都在聊 AI 是什么、能做什么，今年全场都在讲怎么做、怎么落地。 第一站先扎进了数据库展区，毕竟这两年 AI 带火了存算赛道，Lakebase 的概念行业内讨论度一直
-
Oracle如何实现批量 DML 的手动并行
大批量 UPDATE、DELETE 的执行时间通常与行数成正比，串行跑到几个小时是常有的事。提高这类语句的速度，并行hint（`/*+ PARALLEL */``）对查询成熟，但对 DML，数据库默认只并行读、不并行写，真正要并行执行 DML 还得开启会话级并行 DML，粒度、资源都不可控。
-
差点翻车？TiDB 一线运维实战笔记，附全套排障闭环干货整理！
差点翻车？TiDB 一线运维实战笔记，附全套排障闭环干货整理！ 面对业务规模持续扩张，信创落地不断深化，不少团队都会遇到现实困境：集群能跑起来，但很难 “稳得住”——扩缩容操作踩坑引发数据风险、业务突发慢查询无从下手、备份任务跑完却无法真正恢复、分布式故障溯源找不到头绪... 本次我们邀请到 IFClub 星珩联盟智库星系专家李琪老师，结合金融行业 TiDB 一线落地实战经验，带来深度技术直播。
-
赢禾科技入选“2026中国新科技100强”
近日，DBC德本咨询发布“2026中国新科技100强”榜单。赢禾科技入选信创板块，核心领域为“智能灾备与运维领域”。此次入选，是赢禾科技深耕专业领域的一份鼓励和认可。从数据保护到业务恢复，从灾备建设到日常运维，赢禾科技始终关注技术在真实业务场景中的应用，致力于通过产品与服务，帮助客户提升业务连续性保障能力。01 信创走向核心业务，运行保障更加重要榜单发布介绍中提到以“深耕实体场景，回归科技的产业本
-
医院灾备建设：“等级评测遵循”与“数据价值引擎”的双重实现
引言：医院信息科的“四维围城”与破局之路电子病历、智慧医疗评级逐年加码，检查检验互认有了“死命令”，勒索病毒攻击更是把医疗机构列为了首要目标。今天的医院业务连续性，正遭受合规、政策与安全的三重极端拷问。对医院而言，灾备从来不是“可有可无的后备保险”——门诊早高峰 HIS 挂号与结算每卡顿一分钟，急诊救治每中断一秒，带来的都是难以挽回的医疗风险与医患信任损耗。行业共性痛点剖析“评级要达标、中台要数据
-
数据库“按调用计费”正在成为默认选项：一场定价权的迁移
过去十年，云数据库的竞争主线是“把数据库搬上云”；而过去两三年，竞争主线正在悄悄换轨——从“卖实例”转向“卖调用”。按调用计费（pay-per-call / consumption-based pricing）不再是少数 Serverless 数据库的营销标签，而是快速蔓延到事务型数据库、分析型数据库、向量数据库乃至数据库周边工具链的默认商业模型。这场变化表面上是计费单位的调整，实质上是数据库厂商与用户之间风险、成本和定价权的重新分配。 为什么“按调用计费”会在数据库领域快速普及 1. 工作负载形态变了，实例订阅的错配被放大 传统数据库按“实例规格 + 时长”售卖，隐含假设是负载相对平稳、可预测。但今天大量新增负载天然是波动的：面向 C 端的 API 后端、事件驱动的数据处理、AI 应用中的检索与向量查询、Io
-
模型会不会“吞掉”数据库？
过去两年，一个越来越常见的说法是：大模型正在“吃掉”软件栈。它先吞掉搜索框，再吞掉 BI 报表，接着吞掉低代码，最后会不会连数据库也一并吞掉？ 这个问题听起来像标题党，但它背后其实是一个严肃的技术判断：当 LLM 能够理解自然语言、生成 SQL、调用 API、编排 Agent，甚至直接读写结构化数据时，数据库作为“数据存储与查询中间层”的地位，是否会被削弱甚至取代？ 先说结论：模型不会吞掉数据库，但会重写数据库的使用方式、访问入口和价值分配。 数据库不会消失，反而会变得更重要，只是它不再只服务于人和应用程序，还要服务于模型与 Agent。 为什么“模型吞掉数据库”是个伪命题 1. 模型不存储事实，数据库才存储事实 LLM 的本质是概率模型，它擅长生成、归纳、推理和转换，但它并不擅长“记住事实”。即便有超长上下文
-
Agent-Native 数据：当数据基础设施开始为智能体而重建
过去两年，行业讨论 AI 数据时，焦点大多停留在“喂给模型多少 token”“清洗得多干净”“标注得多精细”。这套话语体系默认了一个前提：数据是给人看的，或者至少是给人训练模型用的。但当 Agent（智能体）从演示走向生产，这个前提正在失效。Agent 不是被动消费数据的模型，而是主动读写、持续交互、甚至自行生成数据的行动者。数据基础设施如果还停留在“为训练服务”的旧范式里，就会成为 Agent 落地的真正瓶颈。 为什么“Agent-Native 数据”是一个新命题 要理解 Agent-Native 数据，先要理解 Agent 与传统模型调用在数据行为上的根本差异。 传统 LLM 应用的数据流是单向的：用户输入 → 检索或拼接上下文 → 模型推理 → 输出结果。数据在这里是“只读素材”，用完即弃，状态不沉淀。而
-
Agent 到底怎么用数据库：从“查表工具”到“记忆与行动底座”
当 LLM 从聊天框走向业务系统，Agent 与数据库的关系正在被重新定义。它不再只是“写 SQL 的机器人”，而是把数据库当作感知、记忆、决策与执行的共同底座。依据现有素材判断，行业仍处在模式探索期，但几条关键路径已经清晰。 Agent 使用数据库的四种模式 1. 文本转 SQL：最直观，也最容易被高估 最容易被理解的模式，是让 Agent 把自然语言转成 SQL。用户问“上个月华东区退货率最高的品类是什么”，Agent 生成查询、执行、再把结果转成自然语言。 这条路的价值在于低门槛，但问题也很明显： Schema 理解成本高：真实库有几百张表、复杂外键、历史遗留字段，Agent 很容易“看起来查对了，其实口径错了”。 权限与安全边界模糊：让模型直接生成 SQL，等于把数据库暴露在自然语言攻击面之下。 结果不
-
Agent-Native 数据库：当数据库开始为 AI Agent 而重构
从“人查数据”到“Agent 用数据”：数据库的交互范式正在换轨 过去四十年，数据库的核心服务对象是人——更准确地说，是写 SQL 的开发者、看报表的分析师、点按钮的业务人员。所有的查询语言、索引结构、事务模型、权限体系，都是围绕“人类提出明确问题、数据库返回确定结果”这一范式建立的。 但 LLM 驱动的 AI Agent 正在打破这个前提。当一个 Agent 自主规划任务、调用工具、读写记忆、在多轮推理中反复查询和更新状态时，它对数据库的需求和人类用户截然不同： 查询是高频、碎片化、语义化的，而不是低频、批量化、结构化的； 读写边界模糊，Agent 既在消费数据，也在生产数据（记忆、中间结果、工具调用记录）； Schema 可能动态演化，因为 Agent 面对的任务域本身就不固定； 延迟敏感度极高，Agent
-
用了ORM就不用管数据库迁移了？我差点被这个观点坑死
一、一个被广泛误解的观点 在不少技术社区里，有一种说法流传很广：“只要项目用了ORM，换数据库就是改个方言配置的事，根本不需要什么迁移工具。”这个观点听起来很有道理。ORM确实屏蔽了大部分SQL差异，Hibernate、MyBatis、Entity Framework这些框架都提供了数据库方言抽象。如果项目从MySQL换到PostgreSQL，理论上只需要修改连接配置和方言，应用层代码几乎不用动。
-
Semantic View技术解析（三）：指标、关系与过滤规则如何约束查询结果
Semantic View 减少了临时生成 SQL 时的口径遗漏与实现差异，也为结果核验提供了可以检查的 SQL 和粒度信息。
-
MySQL数据库品牌推荐：云原生时代的选型指南
MySQL是全球使用最广泛的开源关系型数据库之一。过去，企业部署MySQL通常需要在物理服务器上自行安装、配置主从复制、编写备份脚本，并安排专职DBA值守。随着云计算的成熟，云数据库MySQL将运维工作下沉至平台层，企业只需关注业务与数据本身。在众多云数据库产品中，MySQL数据库品牌推荐的评判标准已从“功能多少”转向“稳定、弹性、成本可控与合规保障”的综合能力。天翼云关系数据库MySQL版正是在
-
瑞幸新加坡百店开业，以体系化能力稳步迈向世·界·级咖啡品牌
瑞幸新加坡百店开业，以体系化能力稳步迈向世·界·级咖啡品牌
-
图数据库与 GraphRAG：让 Agent 理解复杂关系
当大模型从“回答问题”走向“执行任务”，Agent 需要的不只是语义相似度，而是对实体、事件与因果链条的结构化理解。图数据库与 GraphRAG 正在成为补上这块能力短板的关键拼图。 一、为什么 Agent 需要“关系”而不只是“文本” 传统 RAG（Retrieval-Augmented Generation）的核心逻辑是：把文档切块、向量化，再按语义相似度召回若干片段拼接进上下文。这套方法在“找一段相关描述”时表现不错，但一旦任务涉及多跳推理，就会暴露短板。 典型场景包括： 多跳问答：A 公司的子公司 B 的负责人同时任职于 C 机构，这类问题需要跨多个实体跳转。 全局性总结：如“这批文档里反复出现的核心矛盾是什么”，向量召回只能拿到局部片段，难以覆盖整体结构。 Agent 任务规划：Agent 要调用工具
-
数据分析 Agent：自然语言驱动的智能洞察
当“提问即分析”成为可能，数据分析 Agent 正在把过去依赖 SQL、报表工具和专业分析师的流程，压缩成一次自然语言对话。它未必是万能答案，但很可能是数据消费方式的一次结构性变化。 一、从“查数”到“问数”：交互范式的迁移 传统数据分析链路通常是：业务人员提出需求 → 分析师理解口径 → 编写 SQL 或拖拽 BI 看板 → 产出图表与结论 → 反馈迭代。这个链路的问题不在于工具不强，而在于中间环节过多、反馈周期过长。 数据分析 Agent 试图改变的正是这一层：用户用自然语言描述问题，Agent 负责理解意图、定位数据、生成查询、执行计算、组织结果，并给出可读的洞察说明。交互入口从“工具操作”转向“对话表达”。 这一方向的核心价值可以概括为三点： 降低使用门槛：非技术角色不必掌握 SQL 或复杂 BI 操作
-
让AI读懂UI设计，友声科技获UI布局智能渲染发明专利
近日，杭州友声科技股份有限公司自主研发的“基于AI的UI布局信息智能渲染方法及系统”正式获得国家知识产权局发明专利授权，专利号：ZL 2026 1 1022775.8。该专利的取得，标志着友声科技在AI驱动的UI智能渲染、跨平台代码生成与智能软件研发领域取得重要技术突破，进一步彰显了公司的自主创新能力与技术领先实力。 在UI设计与界面
-
阿里云AnalyticDB PostgreSQL AI编剧助手，让短剧创作提速提
阿里云AnalyticDB PostgreSQL AI编剧助手，让短剧创作提速提
-
去 IOE 的最后一公里：IvorySQL 5.4 × RISC-V 实测
本文作者：付超，Oracle ACE 与 PostgreSQL ACE 双认证专家，PG 分会西安用户组核心成员。本文看点一句话结论：IvorySQL 5.4 在 openEuler riscv64 平台上可原生编译、稳定运行，软件层面无指令集兼容性缺陷，具备作为去 IOE 替代数据库的基础条件。而性能这一项，需要多说两句：本次压测跑出的 663 ~ 750 TPS，是在 128 核的机器上只点亮
