2026年1月

我是做开源项目的,也在 V2EX 上发过一些宣传帖子, 下面是我今天跟一个开发者聊天的内容。


有什么事吗?
----没事没事,我就是挨个加了下注册过的手机号 问问有没有需要帮助的

没问题, 自己实现了

----你们还是自己去实现应用升级了是吧?

嗯, 直接把你的项目 ai 翻译, 成为另外一个语言 然后复制一些需要的

----ai 镇么强大了? 直接全项目翻译?

你们不用 cursor 这些的吗?

----用啊 但是没想过你这种 项目 ai 翻译的操作
----能给详细讲讲吗
----学习一下

没时间, 自己去学习 agent mcp ai 工作流(扣子、dify 、n8n) skills 这几个

----因为前后端内容很多啊 本身就还用了各种框架, 没太理解怎么直接项目翻译的
----你们是只翻译了 api 吗?

学了你就懂了, 本地代码索引库给你闹着玩的?

----这些我了解一些,可能没有你用的这种深度
----不过我这个项目是哪些实现的不够吗? 还需要你们翻译为别的语言

我们用 c# python java 不太会 go 的语法, 后期扩展和改 Bug 怎么改[擦汗]

----相当于就是你们把 当前项目的部分功能,
----比如说表结构设计这些,你们直接合到你们的后台管理系统里。
----然后再翻译一下 api 接口的实现逻辑?

你知道这些重要吗? 重要的是 ai 打穿了 编程语言的壁垒
学会用 ai 好不好, 别浪费时间在这上面捉摸

----我想知道的 就是个思路是什么样的, 毕竟是有了思路以后 就知道往那里学了

一堆东西你都不是很了解, 都不知道怎么给你说
你学会了上面的 自然你都懂了

----好吧 对 ai 这块确实是学的有点少了
----不过你们这种方式 对搞开源项目的 打击还挺大
----直接转换一份以后 相当于给开源项目什么都没带来

不是我们, 是 ai ,ai 只会越来越强, 大趋势谁也阻挡不了

目前用的 iPhone 8 快 8 年了,从 3 开始每代都用过,iPhone 8 是我最喜欢的一款。
大小,外观都很喜欢。陪伴了我这么长时间,对它感情很深。

时间久了,电池顶不住了,每天要充电很多次,外出要一直插着充电宝。家里人劝我换手机无数次了,但还是不想换。

前两天搜了一下如何自己换电池,看了以后,觉得我也可以。
搜了一下电池价格,才 100 元,马上下单一个试试。
备份好数据,昨天晚上自己动手,花了 2 个小时,终于成功了。😁
电池的 Maximum Capacity 回到了 100%,太感动了。(之前是 50% facepalm

发个帖纪念一下。 snicker

使用教程、源码、下载地址都在这里:https://v2think.com/ad-killer


这件事的技术含量不高,但是它很有趣。这是我制作的一款插件,插件的下载地址、源码以及使用方式在这里。如果你是在微信公众号上阅读到的这篇文章,请点击左下角的阅读原文获取。

同时它也开源的,其解决问题的核心思路也是本文想要分享的。希望它能给你带来更多实用 AI 解决问题的灵感。

Showcase

这是视频演示

以下是图文讲解

简单来说插件的广告识别分为两个步骤,首先如果它发现该视频具备广告识别的条件,在浏览器周围会出现浅蓝色光晕,代表它正在思考

image.png

一旦识别完成之后,光晕消失。在进度条上出现广告时间区间

image.png

在播放极端即将进入广告区间时,播放器周围会出现五彩光晕进行提示,表示即将跳过该广告区间

image.png

核心原理

简单来说通过字幕

网站在加载每个视频时都需要请求一个路径为api.bilibili.com/x/player/wbi/v2的接口,我不知道这个接口是做什么的,但是在这个接口中会返回字幕的“元信息”。之所以称之为元信息,是因为它不包含字幕本身,而是包含围绕字幕的有关其他信息,例如该字幕属于哪国语言,该字幕是否由 AI 生成,以及最重要的请求字幕用的 URL

注意,接口只会在登录的情况下才会返回字幕信息。同时注意字幕的 URL 中是带有 token 的,所以你无法一直持有并访问它,因为 token 需要被更新。

image.png

我通常会选取中文字幕,并且找到其中的 URL ,然后发送请求,得到的字幕结果内容如下:

image.png

理论上我认为把这段 JSON 发给 AI ,它就可以识别出其中的广告。但是为了确保准确性,以及节省 token ,这里我们需要将其传化为更为简单的结构,转化的函数如下:

export function convertSubtitleObjToStr(subtitles: subtitle[]): string {
    return subtitles.map((sub: subtitle) => {
        const { from, to, content } = sub
        const subtitleStr: SubtitleString = `[${from}-${to}]:${content}`;
        return subtitleStr;
    }).join(';')
}

转化后的结果如下:

[0.82-2.06]:哇来了哇;[2.06-5.48]哦让我们去看看这个今天就吃一桶螺蛳粉了;[5.48-9.41]哇这哇哦终于吃螺蛳粉了;

在将字幕转化为指定格式之后,需要将其发送至 AI ,送使用的提示词( prompt )如下:

接下我会分享给你一段视频字幕,该段字幕由多个字幕语句组成。
每一句字幕包含三部分内容,分别是起始时间,结束时间,以及字幕内容,格式如下:[{起始时间}-{结束时间}]:{字幕内容}。语句之间由分号(;)隔开。
帮助我分析其中哪些是与视频无关的广告内容,给出其中连续广告内容起始时间和终止时间。我可能还会分享给你视频的标题以及视频的描述,用于辅助你判断广告内容
如果存在广告内容,请将广告的起止时间返回给我,返回格式为:{startTime: number, endTime: number}
如果不存在广告内容,返回 null
字幕内容如下:

因为我需要在网页播放器的时间轴上精确的渲染出来广告时间段,所以在上述提示词中我明确告诉 AI 将广告的起止时间以 JSON 的格式返回。

继续优化

以上能够覆盖 90%的情况了,但是在代码的实现过程中还是有必要解决一下边缘情况。

首先在提示词中指定返回的 JSON 格式并不靠谱,于是我选择在调用 SDK 的代码中以代码的方式指定返回的 JSON schema

const responseSchema = {
    type: 'OBJECT',
    properties: {
        startTime: {type: 'number', nullable: false},
        endTime: {type: 'number', nullable: false},
    },
    required: ['startTime', 'endTime'],
};

const response = await geminiClient.models.generateContent({
    model: aiModel,
    config: {
        responseJsonSchema: responseSchema,
        responseMimeType: "application/json",
        httpOptions: {
            timeout: 1000 * 60,
        }
    },
    contents: ''
});

其次我们还可以通过向 AI 提供更丰富的信息来协助他,例如视频的标题和描述,所以的我最终喂给 AI 的最终提示词中实际上是包含视频的标题以及描述的:

接下我会分享给你一段视频字幕,该段字幕由多个字幕语句组成

……

字幕内容如下:
xxxx

视频标题如下:
xxxx

视频描述如下:
xxx

最后我发现对于短视频 AI 通过字幕判断广告的并不理想,所以默认我不对五分钟以内的视频进行判断。

技术细节

也许你对实现过程中的一些技术细节感兴趣,这里我把我能够想到的都分享出来。

如何找到字幕接口的

搜索,这是最简单的方式。

例如在上面的视频中我发现视频字幕中出现了“螺蛳粉”这三个字,于是我就在 Chrome 的开发者工具中全局搜索“螺蛳粉”(你需要再视频一开始加载时就打开开发者工具),结果如下

image.png

很明搜索列表的第一个结果就是字幕接口的返回,右边就可以找到该返回所对应的请求 URL 是什么。有了这个 aisubtitle.hdslb.com 关键词之后我就顺藤摸瓜找到返回这个域名的接口

image.png

如何拿到视频的标题、描述以及时长信息

事实上我不用等待页面完全渲染完毕之后从 DOM 中截取,视频的各种基本信息已经被提前被存储到了全局变量window.__INITIAL_STATE__

image.png

通过页面源代码不难看出,该变量早就由后端渲染在了页面上

image.png

事实上还有一种较为复杂的场景是播放列表。在这个场景中上一个视频播放完毕之后会自动播放下一个视频。不用担心,此时的window.__INITIAL_STATE__变量内的数据也会得到更新

如何拦截请求并得到其中的字幕加载 URL

前端想要发送 API 请求,无非只有两个手段 1 )通过 XMLHttpRequest ; 2 )通过 Fetch API 。经过测试不难发现 Bilibili 网站试用的是前者,于是我选择通过 monkey patch 方式将它“黑”掉,替换成我的实现方法以便我监控每一个发出的请求,以及获取到它们的返回:

  const originalOpen = XMLHttpRequest.prototype.open;
  const originalSend = XMLHttpRequest.prototype.send;

  XMLHttpRequest.prototype.open = function(method: string, url: string | URL, ...args: any[]) {
    // @ts-ignore
    this._url = url.toString();
    // @ts-ignore
    return originalOpen.call(this, method, url, ...args);
  };

  XMLHttpRequest.prototype.send = function(...args: any[]) {
    // @ts-ignore
    const url = this._url;

    if (window.location.pathname.startsWith('/video/') && url && url.includes('api.bilibili.com/x/player/wbi/v2')) {
      console.log('📺 ✔️ Detected player API request');

为什么只考虑了 Gemini ?

因为兼容每一种大模型都需要时间成本,而我的精力实在有限(欢迎给源代码提 pull request )。我唯二非常想集成的大模型是 OpenAI ,苦于他们不接受国内信用卡,亲测 Google Pay 也无效。

集成不同模型最高效的办法是用某个兼容超强的 SDK ,例如 Vercel 提供的AI SDK,又或者某个 Agent 框架例如Mastra,可问题在于虽然多数框架支持的编程语言是 TypeScript ,但框架并支持在浏览器端运行。

事实上我还考虑过使用 Chrome 内置的本地模型——没错,目前 Chrome 支持用户下载一个 Gemini Nano 模型安装在本地(大约 2G 左右),但是该模型判断广告的效果非常差,于是隐藏了该功能。你还可以在我的源码中找到该部分代码

未来

如果每个人都安装了这个插件的话,可想而知同一个热门视频的字幕会被发送给 AI 很多次——这其实是一种浪费。理想情况下,只要我们中的任何一个人拿到了 AI 返回的结果那么它接可以与其他人共同分享。

这才是我最想做的事情:把每个人得到的不同视频的分析结果上传到云端共享,这样一来不仅用户体验可以大大提升,个体花费的时间和金钱也可以节省不少。

Access 连接 SQL Server:直通查询 vs 链接表 vs ADO,如何选择?

摘要:当 Access 前端需要连接 SQL Server 后端时,开发者面临三种主流技术方案:链接表(Linked Tables)直通查询(Pass-Through Queries)ADO 编程。本文从底层原理、性能特征、适用场景三个维度进行深度对比,帮助开发者在实际项目中做出正确的技术选型。


一、技术背景

Access 作为前端开发工具连接 SQL Server 后端,是中小型企业信息化的经典架构。这种"胖客户端"模式相比纯 Web 方案,具有开发效率高、部署简单的优势。

但 Access 与 SQL Server 之间的数据交互存在多种实现路径,不同方案在 网络开销服务器负载代码复杂度 上差异显著。


二、三种方案的底层原理

1. 链接表(Linked Tables)

原理:通过 ODBC 驱动在 Access 中创建指向 SQL Server 表的"快捷方式"。Access 的 ACE/Jet 引擎会将用户操作(筛选、排序、更新)转换为 ODBC 调用。

┌──────────────┐      ODBC       ┌──────────────┐
│   Access     │  ←──────────→   │  SQL Server  │
│  (ACE引擎)   │   链接表驱动     │   (T-SQL)    │
└──────────────┘                 └──────────────┘

技术特点

  • 透明性:开发者可以像操作本地表一样使用 SELECT * FROM tblOrders
  • 引擎介入:ACE 引擎会"尝试"优化查询,但复杂查询可能被拆解为多次网络往返。
  • 事务支持:受限于 ODBC 驱动的事务隔离级别。

创建方式

' VBA 代码创建链接表
DoCmd.TransferDatabase acLink, "ODBC Database", _
    "ODBC;DRIVER={SQL Server};SERVER=192.168.1.100;DATABASE=SalesDB;Trusted_Connection=Yes", _
    acTable, "dbo.Orders", "lnkOrders"

2. 直通查询(Pass-Through Queries)

原理:绕过 ACE 引擎,将 原生 T-SQL 直接发送到 SQL Server 执行,结果集作为只读快照返回。

┌──────────────┐    原生 T-SQL    ┌──────────────┐
│   Access     │  ──────────────→ │  SQL Server  │
│  (仅传递)     │   不经过 ACE     │   (直接执行)  │
└──────────────┘                 └──────────────┘

技术特点

  • 完全控制:可使用 SQL Server 特有语法(TOPWITH (NOLOCK)PIVOT 等)。
  • 只读限制:返回结果集默认不可编辑(除非配合链接表使用)。
  • 存储过程调用:最佳的存储过程执行方式。

创建方式

-- 在查询设计器中设置 "直通" 属性为 "是"
-- 或通过 VBA 创建
SELECT TOP 100 OrderID, CustomerName, OrderDate
FROM dbo.Orders WITH (NOLOCK)
WHERE OrderDate >= '2025-01-01'
ORDER BY OrderDate DESC

VBA 动态执行

Public Sub ExecutePassThrough(strSQL As String)
    Dim qdf As DAO.QueryDef
    
    On Error Resume Next
    CurrentDb.QueryDefs.Delete "qryTemp"
    On Error GoTo 0
    
    Set qdf = CurrentDb.CreateQueryDef("qryTemp")
    With qdf
        .Connect = "ODBC;DRIVER={SQL Server};SERVER=192.168.1.100;DATABASE=SalesDB;Trusted_Connection=Yes"
        .SQL = strSQL
        .ReturnsRecords = True  ' 如果是 INSERT/UPDATE/DELETE,设为 False
    End With
    
    ' 绑定到窗体或报表
    Me.RecordSource = "qryTemp"
End Sub

3. ADO 编程(ActiveX Data Objects)

原理:通过 ADO 对象模型(ADODB.ConnectionADODB.Recordset)直接操作 OLE DB 或 ODBC 数据源,完全脱离 Access 的 DAO/ACE 体系。

┌──────────────┐     OLE DB      ┌──────────────┐
│   Access     │  ←──────────→   │  SQL Server  │
│  (ADO对象)   │   直接连接       │   (T-SQL)    │
└──────────────┘                 └──────────────┘

技术特点

  • 最大灵活性:支持游标类型选择、批量更新、断开式记录集。
  • 可移植性:ADO 代码可直接迁移到 VB6、VBScript、Excel VBA。
  • 代码量大:需要手动管理连接生命周期和错误处理。

典型代码

Public Function GetOrders(strCustomerID As String) As ADODB.Recordset
    Dim conn As New ADODB.Connection
    Dim rs As New ADODB.Recordset
    Dim strSQL As String
    
    ' 连接字符串
    conn.ConnectionString = "Provider=SQLOLEDB;Data Source=192.168.1.100;" & _
                            "Initial Catalog=SalesDB;Integrated Security=SSPI;"
    conn.Open
    
    ' 参数化查询防止 SQL 注入
    strSQL = "SELECT * FROM dbo.Orders WHERE CustomerID = ?"
    
    With rs
        .ActiveConnection = conn
        .Source = strSQL
        .CursorLocation = adUseClient  ' 客户端游标,支持断开连接
        .CursorType = adOpenStatic
        .LockType = adLockBatchOptimistic
        .Open , , , , adCmdText
    End With
    
    ' 断开连接,返回独立记录集
    Set rs.ActiveConnection = Nothing
    conn.Close
    
    Set GetOrders = rs
End Function

三、性能对比测试

以下是在 万级数据量 下的典型场景测试结果(仅供参考,实际因网络环境而异):

场景链接表直通查询ADO
SELECT 1000 条记录1.2s0.3s0.4s
复杂 JOIN(5表关联)8.5s0.8s0.9s
调用存储过程不支持0.2s0.2s
批量 INSERT 1000 条15s0.5s0.6s
单条记录更新0.1s0.1s0.1s

结论

  • 简单 CRUD:三者差异不大。
  • 复杂查询/批量操作:直通查询和 ADO 优势明显。
  • 链接表的性能陷阱:多表 JOIN 时,ACE 引擎可能先拉取全表数据到本地再做关联,造成巨大的网络开销。

四、适用场景决策树

                        ┌─────────────────────────┐
                        │  需要连接 SQL Server?   │
                        └───────────┬─────────────┘
                                    │
                    ┌───────────────┴───────────────┐
                    ▼                               ▼
            需要绑定窗体/报表?               仅需执行命令/获取数据?
                    │                               │
        ┌───────────┴───────────┐                   │
        ▼                       ▼                   ▼
   简单表结构              复杂查询/存储过程      ───→  ADO
   单表或简单JOIN                │                    (最大灵活性)
        │                       │
        ▼                       ▼
    【链接表】              【直通查询】
   (最简单)              (高性能)

场景建议

场景推荐方案理由
数据维护窗体(增删改查)链接表可直接绑定,无需额外代码
报表数据源直通查询只读即可,性能最优
调用存储过程直通查询 / ADO链接表不支持存储过程
复杂多表统计直通查询避免 ACE 拆解查询
需要事务控制ADO可精确控制 BeginTrans/CommitTrans
断开式数据处理ADO支持客户端游标和批量更新
跨数据库查询ADO可同时连接多个数据源

五、混合架构最佳实践

在实际项目中,三种方案往往需要混合使用

┌─────────────────────────────────────────────────────────┐
│                    Access 前端                          │
├─────────────────────────────────────────────────────────┤
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐  │
│  │   链接表      │  │   直通查询   │  │    ADO      │  │
│  │ (数据维护)   │  │  (报表/统计) │  │  (存储过程)  │  │
│  └──────────────┘  └──────────────┘  └──────────────┘  │
└─────────────────────────────────────────────────────────┘
                           │
                           ▼
              ┌─────────────────────────┐
              │      SQL Server         │
              │   (存储过程/视图/表)     │
              └─────────────────────────┘

架构建议

  1. 基础表:使用链接表,方便窗体绑定。
  2. 复杂视图:在 SQL Server 端创建视图,Access 链接该视图。
  3. 统计报表:使用直通查询,发挥 SQL Server 的聚合能力。
  4. 业务逻辑:封装为存储过程,通过直通查询或 ADO 调用。

六、总结

维度链接表直通查询ADO
学习成本★☆☆★★☆★★★
开发效率★★★★★☆★☆☆
运行性能★☆☆★★★★★★
灵活性★☆☆★★☆★★★
可维护性★★★★★☆★★☆

核心原则

  • 能用链接表解决的,不要过度设计。
  • 性能敏感的场景,优先考虑直通查询。
  • 需要精细控制(事务、游标、多数据源)时,使用 ADO。

「Access开发」 专注于 Microsoft Access 开发与企业级应用,提供以下服务:

📚 技术培训

  • Access VBA 从入门到精通(线上/线下)
  • Access + SQL Server 企业级开发实战
  • Access 系统性能优化与架构设计

💼 定制开发

  • 企业 ERP/CRM/进销存系统开发
  • 旧系统升级与性能优化
  • Access 迁移至 Web/Power Platform 咨询

🔧 技术支持

  • 代码审查与重构建议
  • 疑难问题远程诊断
  • 一对一技术辅导

技术改变业务,专注创造价值。

MiniMax 全球领先的通用人工智能科技公司。旗下主要有 MiniMax M2.1、Hailuo 2.3、Speech 2.6 和 Music 2.0 等大模型,MiniMax Agent、海螺 AI、星野、Talkie 等产品,以及为企业客户与开发者提供 API 服务的 MiniMax 开放平台。截至目前,MiniMax 已有超过 200 个国家及地区的逾 2.12 亿名个人用户以及超过 100 个国家的企业客户。

在技术层面,MiniMax 坚持文本、视频、语音等全模态模型自主研发。目前,其全模态模型已进入国际第一梯队,被业内称为“全球唯四实现这一水平的企业之一”。

在推理能力和效率方面,MiniMax 近年来的模型迭代节奏明显加快,在多项国际评测榜单中进入全球前列。相关模型以较低算力成本实现接近国际顶尖闭源模型的性能表现,也在海外开发者社区中获得关注。

MiniMax 通过开放平台赋能多个行业,将领先的模型能力以 API 方式提供给企业和开发者。随着模型调用量的指数级增长,训练与推理产生的运行日志数据量也急剧膨胀。 这些日志对于 AI 应用的运行监控、性能优化与问题排查至关重要,因此,选择一款能够支撑高吞吐、易查询、低成本的日志存储与检索引擎,成为保障业务稳定高效运行的关键

MiniMax 可观测性数据平台核心基座.JPEG

面对海量、实时且不断增长的日志数据处理需求,MiniMax 经过深度评估,最终选择阿里云数据库 SelectDB 版作为其全新可观测性数据平台的核心基座。阿里云数据库 SelectDB 版凭借其更低的成本、更高的查询性能以及更灵活的查询方式在众多产品中脱颖而出。其关键特性精准匹配了现代 AI 业务的严苛要求:

  • 云原生存算分离架构:基于对象存储 OSS 的存储层与弹性计算层解耦,支持独立、无损的弹性伸缩,为应对日志洪峰提供了近乎无限的扩展能力。
  • 多集群硬隔离与数据共享:支持云原生多集群硬隔离能力,用户可以将单个实例的计算资源划分为多个逻辑集群,不同集群之间的分配独立的计算资源,实现了不同集群的严格物理资源隔离和数据共享。
  • 智能缓存加速:通过单副本本地读写缓存、智能数据淘汰策略、高效列式存储格式和先进压缩算法,显著提升了海量数据的读写效率。
阿里云数据库 SelectDB 植根于开源 Apache Doris 的坚实基础,深度融合云随需而用的特性,依托阿里云基础设施,构建起云原生存算分离的全新架构,面向企业海量数据的实时分析需求,提供极速实时、湖仓融合统一、简单易用的云上数仓服务。

MiniMax 可观测性数据平台核心基座-1.PNG

基于阿里云 SelectDB 版,MiniMax 构建了覆盖国内及海外业务的统一日志可观测中台。 以 SelectDB 独立负责所有日志的存储与查询分析,实现了 “一个平台,全球覆盖” 。这彻底终结了以往为不同业务集群分散部署、独立运维多套系统的复杂局面,在架构上实现了极大的简化。

阿里云数据库 SelectDB 在 MiniMax 的成功实践足以说明:SelectDB 能够很好地满足 AI 时代海量数据实时处理与分析的需求。不仅为 MiniMax 自身业务的高效运营提供了坚实保障,也为广大面临类似日志处理挑战的 AI 大模型企业,提供了一个高性能、低成本的可靠技术解决方案

不止于此, 面对大模型与多模态 AI 的快速发展,SelectDB 已从被动存储分析向主动智能分析演进。目前,SelectDB 已具备 AI 原生支持能力,深度融合向量索引、文本搜索与结构化分析能力,实现高效的混合检索,显著提升结果相关性、实时性与准确性。更进一步,SelectDB 内置 AI 函数(如语义理解、特征提取)并支持基于 MCP 的 Agent 分析接口,可直接升级为企业的 “AI 分析中枢” ,为业务智能决策与创新提供稳定、高效的数据底座。

本文为墨天轮数据库管理服务团队第159期技术分享,内容原创,作者为技术顾问闫建,如需转载请联系小墨(VX:modb666)并注明来源。如需查看更多文章可关注【墨天轮】公众号。

脚本功能

此脚本是专门用于MySQL8.0物理备份的xtrabackup脚本,并且xtrabackup版本为8.0的最新版,它包含了备份数据库(包含全量备份,错误处理,日志记录,自动清理,耗时统计)的完整配置。

脚本内容

该脚本名称为xtrabackup8.0\_full.sh

#!/bin/bash
# ===============================================
# MySQL XtraBackup 全量备份脚本 (默认未启用压缩) 
# 功能:全量备份 + 错误处理 + 日志记录 + 自动清理 + 耗时统计
# 版本:1.0
# 日期:2025-11-04
# ===============================================
# -------------------------------
# 可配置变量(修改此处适应环境)
# -------------------------------
# 基础路径
BACKUP_BASE_DIR="/data/backup"                 # 备份根目录
LOG_DIR="${BACKUP_BASE_DIR}/logs"              # 日志目录
FULL_BACKUP_DIR="${BACKUP_BASE_DIR}/full"      # 全量备份目录
# MySQL 连接配置
MYSQL_USER="root"                              # 备份专用用户(需提前授权)
MYSQL_PASSWORD="mysql"                         # 用户密码
MYSQL_SOCKET="/data/mysql/3306/run/mysql.sock" # MySQL Socket路径
MYSQL_CNF="/etc/my.cnf"                        # MySQL配置文件路径
# 备份参数
RETENTION_DAYS=7                               # 备份保留天数(默认7天)
COMPRESS_ENABLED=0                             # 是否启用压缩(0-禁用,1-启用,默认禁用)
COMPRESS_ALGORITHM="zstd"                      # 压缩算法(zstd/lz4/quicklz,默认zstd,如果采用zstd压缩方式,在解压的时候建议在OS上检查是否安装 zstd软件,如未安装,请提前安装yum install zstd)
COMPRESS_THREADS=4                             # 压缩线程数(默认4)
PARALLEL=4                                     # 备份并行线程数(默认4)
# XtraBackup路径(若不在PATH中,需指定完整路径,注意:该路径需要提前修改为符合实际环境的绝对路径)
XTRABACKUP_PATH="/data/soft/xtrabackup8.0.35-34-glibc2.36/bin/xtrabackup"
# -------------------------------
# 函数定义
# -------------------------------
# 日志记录函数
log_message() {
    local level="$1"
    local message="$2"
    local timestamp=$(date '+%Y-%m-%d %H:%M:%S')
    local log_entry="[${timestamp}] [${level}] ${message}"
    # 输出到标准输出并写入日志文件
    echo "${log_entry}" | tee -a "${CURRENT_LOG_FILE}"
}
# 错误处理函数
error_exit() {
    log_message "ERROR" "脚本执行失败: $1"
    exit 1
}
# 计算和格式化时间差函数
calculate_duration() {
    local start_seconds="$1"
    local end_seconds="$2"
    local total_seconds=$((end_seconds - start_seconds))
    # 转换为天、小时、分钟、秒的易读格式
    local days=$((total_seconds / 86400))
    local hours=$(( (total_seconds % 86400) / 3600 ))
    local minutes=$(( (total_seconds % 3600) / 60 ))
    local seconds=$((total_seconds % 60))
    local duration_str=""
    if [ $days -gt 0 ]; then
        duration_str="${days}天"
    fi
    if [ $hours -gt 0 ] || [ -n "$duration_str" ]; then
        duration_str="${duration_str}${hours}小时"
    fi
    if [ $minutes -gt 0 ] || [ -n "$duration_str" ]; then
        duration_str="${duration_str}${minutes}分钟"
    fi
    duration_str="${duration_str}${seconds}秒"
    echo "$duration_str"
}
# 清理旧备份函数
cleanup_old_backups() {
    log_message "INFO" "开始清理超过 ${RETENTION_DAYS} 天的旧备份..."
    local deleted_count=0
    # 删除过期全量备份及相关日志
    if find "${BACKUP_BASE_DIR}" -name "full_*" -type d -mtime +${RETENTION_DAYS} | grep -q .; then
        find "${BACKUP_BASE_DIR}" -name "full_*" -type d -mtime +${RETENTION_DAYS} -exec rm -rf {} \;
        deleted_count=$(find "${BACKUP_BASE_DIR}" -name "full_*" -type d -mtime +${RETENTION_DAYS} | wc -l)
        log_message "INFO" "已清理 ${deleted_count} 个过期全量备份"
    else
        log_message "INFO" "未找到需要清理的过期备份"
    fi
    # 清理旧日志文件(保留30天)
    find "${LOG_DIR}" -name "backup_*.log" -type f -mtime +30 -delete
}
# 检查依赖项
check_dependencies() {
    local deps=("${XTRABACKUP_PATH}" "mysql")
    for cmd in "${deps[@]}"; do
        if ! command -v "${cmd}" &> /dev/null; then
            error_exit "未找到所需命令: ${cmd},请确保已安装并配置PATH"
        fi
    done
    # 检查备份目录权限
    if [ ! -w "${BACKUP_BASE_DIR}" ]; then
        error_exit "备份目录不可写: ${BACKUP_BASE_DIR}"
    fi
}
# 备份前置检查
pre_backup_checks() {
    log_message "INFO" "开始备份前置检查..."
    # 检查MySQL连接
    if ! mysql --user="${MYSQL_USER}" --password="${MYSQL_PASSWORD}" --socket="${MYSQL_SOCKET}" -e "SELECT 1;" &> /dev/null; then
        error_exit "MySQL连接测试失败,请检查凭据和Socket路径"
    fi
    # 检查XtraBackup版本
    local xtrabackup_version
    xtrabackup_version=$(${XTRABACKUP_PATH} --version 2>&1 | tail -n1 || echo "未知")
    log_message "INFO" "使用XtraBackup版本: ${xtrabackup_version}"
    # 检查磁盘空间(至少保留10GB)
    local available_space
    available_space=$(df "${BACKUP_BASE_DIR}" | awk 'NR==2 {print $4}')
    if [ "${available_space}" -lt 10485760 ]; then  # 10GB in KB
        error_exit "磁盘空间不足10GB,当前可用: ${available_space}KB"
    fi
}
# -------------------------------
# 主脚本逻辑
# -------------------------------
main() {
    # 初始化变量
    local backup_timestamp=$(date '+%Y%m%d_%H%M%S')
    local backup_name="full_${backup_timestamp}"
    local current_backup_dir="${FULL_BACKUP_DIR}/${backup_name}"
    CURRENT_LOG_FILE="${LOG_DIR}/backup_${backup_timestamp}.log"
    # 记录备份开始时间(秒级时间戳)[6,8](@ref)
    local backup_start_time=$(date +%s)
    local backup_start_readable=$(date '+%Y-%m-%d %H:%M:%S')
    # 创建目录
    mkdir -p "${FULL_BACKUP_DIR}" "${LOG_DIR}"
    log_message "INFO" "=== MySQL全量备份开始 ==="
    log_message "INFO" "备份开始时间: ${backup_start_readable}"
    log_message "INFO" "备份名称: ${backup_name}"
    log_message "INFO" "备份目录: ${current_backup_dir}"
    log_message "INFO" "保留天数: ${RETENTION_DAYS}"
#    log_message "INFO" "压缩启用: ${COMPRESS_ENABLED} (算法: ${COMPRESS_ALGORITHM}, 线程: ${COMPRESS_THREADS})"
    # 执行检查
    check_dependencies
    pre_backup_checks
    # 构建备份命令
    local backup_cmd="${XTRABACKUP_PATH} --defaults-file=${MYSQL_CNF} --backup"
    backup_cmd+=" --target-dir=${current_backup_dir}"
    backup_cmd+=" --user=${MYSQL_USER} --password=${MYSQL_PASSWORD}"
    backup_cmd+=" --socket=${MYSQL_SOCKET} --parallel=${PARALLEL}"
    # 压缩配置
    if [ "${COMPRESS_ENABLED}" -eq 1 ]; then
        log_message "INFO" "启用压缩算法: ${COMPRESS_ALGORITHM}, 线程数: ${COMPRESS_THREADS}"
        backup_cmd+=" --compress=${COMPRESS_ALGORITHM} --compress-threads=${COMPRESS_THREADS}"
    else
        log_message "INFO" "备份未启用压缩"
    fi
    # 执行备份
    log_message "INFO" "开始执行 XtraBackup 全量备份..."
    log_message "DEBUG" "备份命令: ${backup_cmd//--password=* /--password=*** }"  # 屏蔽密码显示
    # 记录备份操作开始时间
    local backup_operation_start=$(date +%s)
    if eval "${backup_cmd}" >> "${CURRENT_LOG_FILE}" 2>&1; then
        local backup_operation_end=$(date +%s)
        local backup_duration=$(calculate_duration $backup_operation_start $backup_operation_end)
        log_message "INFO" "XtraBackup全量备份完成,备份操作耗时: ${backup_duration}"
        # 验证备份完整性
        if [ -f "${current_backup_dir}/xtrabackup_checkpoints" ]; then
            local backup_type
            backup_type=$(grep "backup_type" "${current_backup_dir}/xtrabackup_checkpoints" | cut -d= -f2)
            log_message "INFO" "备份类型验证: ${backup_type}"
        else
            error_exit "备份完整性检查失败: xtrabackup_checkpoints文件缺失"
        fi
    else
        error_exit "XtraBackup备份过程失败,请检查日志: ${CURRENT_LOG_FILE}"
    fi
    # 自动清理旧备份
    cleanup_old_backups
    # 计算总耗时
    local backup_end_time=$(date +%s)
    local backup_end_readable=$(date '+%Y-%m-%d %H:%M:%S')
    local total_duration=$(calculate_duration $backup_start_time $backup_end_time)
    # 计算备份大小
    local backup_size
    backup_size=$(du -sh "${current_backup_dir}" | awk '{print $1}')
    log_message "INFO" "备份完成: ${backup_name} (大小: ${backup_size})"
    log_message "INFO" "备份开始: ${backup_start_readable}"
    log_message "INFO" "备份结束: ${backup_end_readable}"
    log_message "INFO" "备份总耗时: ${total_duration}"
    log_message "INFO" "备份日志: ${CURRENT_LOG_FILE}"
    log_message "INFO" "=== MySQL全量备份结束 ==="
}
# 异常处理(捕获中断信号)
trap 'log_message "ERROR" "脚本被用户中断"; exit 2;' INT TERM
# 脚本入口点
main "$@"

重点说明

在脚本最开始部分需要根据实际数据库环境来配置,包括用户名,密码,路径等详细信息,参考如下:

BACKUP_BASE_DIR="/data/backup"                 # 备份根目录
LOG_DIR="${BACKUP_BASE_DIR}/logs"              # 日志目录
FULL_BACKUP_DIR="${BACKUP_BASE_DIR}/full"      # 全量备份目录
# MySQL 连接配置
MYSQL_USER="root"                              # 备份专用用户(需提前授权)
MYSQL_PASSWORD="mysql"                         # 用户密码
MYSQL_SOCKET="/data/mysql/3306/run/mysql.sock" # MySQL Socket路径
MYSQL_CNF="/etc/my.cnf"                        # MySQL配置文件路径
# 备份参数
RETENTION_DAYS=7                               # 备份保留天数(默认7天)
COMPRESS_ENABLED=0                             # 是否启用压缩(0-禁用,1-启用,默认禁用)
COMPRESS_ALGORITHM="zstd"                      # 压缩算法(zstd/lz4/quicklz,默认zstd,如果采用zstd压缩方式,在解压的时候建议在OS上检查是否安装 zstd软件,如未安装,请提前安装yum install zstd)
COMPRESS_THREADS=4                             # 压缩线程数(默认4)
PARALLEL=4                                     # 备份并行线程数(默认4)
# XtraBackup路径(若不在PATH中,需指定完整路径,注意:该路径需要提前修改为符合实际环境的绝对路径)
XTRABACKUP_PATH="/data/soft/xtrabackup8.0.35-34-glibc2.36/bin/xtrabackup"

使用方法

  1. 保脚本并赋予执行权限

    chmod +x xtrabackup8.0_full.sh
  2. 手动执行备份
[root@VM-8-4-opencloudos backup]# ./xtrabackup8.0_full.sh 
[2025-11-04 17:34:34] [INFO] === MySQL全量备份开始 ===
[2025-11-04 17:34:34] [INFO] 备份名称: full_20251104_173434
[2025-11-04 17:34:34] [INFO] 备份目录: /data/backup/full/full_20251104_173434
[2025-11-04 17:34:34] [INFO] 保留天数: 7
[2025-11-04 17:34:34] [INFO] 开始备份前置检查...
[2025-11-04 17:34:35] [INFO] 使用XtraBackup版本: /data/soft/xtrabackup8.0.35-34-glibc2.36/bin/xtrabackup version 8.0.35-34 based on MySQL server 8.0.35 Linux (x86_64) (revision id: c8a25ff9)
[2025-11-04 17:34:35] [INFO] 启用压缩算法: zstd, 线程数: 4
[2025-11-04 17:34:35] [INFO] 开始执行XtraBackup全量备份...
[2025-11-04 17:34:35] [DEBUG] 备份命令: /data/soft/xtrabackup8.0.35-34-glibc2.36/bin/xtrabackup --defaults-file=/etc/my.cnf --backup --target-dir=/data/backup/full/full_20251104_173434 --user=root --password=*** --compress-threads=4
[2025-11-04 17:34:41] [INFO] XtraBackup全量备份完成
[2025-11-04 17:34:41] [INFO] 备份类型验证:  full-backuped
[2025-11-04 17:34:41] [INFO] 开始清理超过 7 天的旧备份...
[2025-11-04 17:34:41] [INFO] 未找到需要清理的过期备份
[2025-11-04 17:34:41] [INFO] 备份完成: full_20251104_173434 (大小: 43M)
[2025-11-04 17:34:41] [INFO] 备份日志: /data/backup/logs/backup_20251104_173434.log
[2025-11-04 17:34:41] [INFO] === MySQL全量备份结束 ===
[root@VM-8-4-opencloudos backup]# 
  1. 配置定时任务(每日凌晨1点执行)
# 编辑crontab:crontab -e 添加如下内容并保存
0 1 * * * /path/to/xtrabackup8.0_full.sh 

恢 复

1、解压缩(如采用压缩备份,此步骤为必须执行步骤,非压缩备份,此步骤忽略)

/data/soft/xtrabackup8.0.35-34-glibc2.36/bin/xtrabackup --decompress --remove-original --target-dir=/data/backup/full/full_20251104_173434
2025-11-04T17:40:22.986591+08:00 0 [Note] [MY-011825] [Xtrabackup] recognized server arguments: --server-id=13045 --innodb_io_capacity=2000 --datadir=/data/mysql/3306/data --log_bin=/data/mysql/3306/binlogs/mysql-bin --tmpdir=/data/mysql/3306/tmp --innodb_buffer_pool_size=1G --innodb_data_file_path=ibdata1:200M;ibdata2:200M:autoextend --innodb_flush_method=O_DIRECT --innodb_adaptive_hash_index=0 
2025-11-04T17:40:22.986824+08:00 0 [Note] [MY-011825] [Xtrabackup] recognized client arguments: --port=3306 --socket=/data/mysql/3306/run/mysql.sock --decompress=1 --remove-original=1 --target-dir=/data/backup/full/full_20251104_173434 
/data/soft/xtrabackup8.0.35-34-glibc2.36/bin/xtrabackup version 8.0.35-34 based on MySQL server 8.0.35 Linux (x86_64) (revision id: c8a25ff9)
2025-11-04T17:40:22.988436+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./xtrabackup_logfile.zst
2025-11-04T17:40:23.000940+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./xtrabackup_logfile.zst
2025-11-04T17:40:23.001025+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./ibdata1.zst
2025-11-04T17:40:23.330061+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./ibdata1.zst
2025-11-04T17:40:23.344696+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./ibdata2.zst
2025-11-04T17:40:23.903032+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./ibdata2.zst
2025-11-04T17:40:23.903125+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./testdb/large_table.ibd.zst
2025-11-04T17:40:24.496119+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./testdb/large_table.ibd.zst
2025-11-04T17:40:24.594530+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./testdb/my_table.ibd.zst
2025-11-04T17:40:24.608587+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./testdb/my_table.ibd.zst
2025-11-04T17:40:24.616871+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./testdb/tt_new.ibd.zst
2025-11-04T17:40:24.629940+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./testdb/tt_new.ibd.zst
2025-11-04T17:40:24.630190+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./testdb/tt.ibd.zst
2025-11-04T17:40:24.635994+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./testdb/tt.ibd.zst
2025-11-04T17:40:24.636477+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./testdb/a.ibd.zst
2025-11-04T17:40:24.643492+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./testdb/a.ibd.zst
2025-11-04T17:40:24.644126+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./testdb/b.ibd.zst
2025-11-04T17:40:24.650521+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./testdb/b.ibd.zst
2025-11-04T17:40:24.650961+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./sys/sys_config.ibd.zst
2025-11-04T17:40:24.655719+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./sys/sys_config.ibd.zst
2025-11-04T17:40:24.656597+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./mysql.ibd.zst
2025-11-04T17:40:24.695278+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./mysql.ibd.zst
2025-11-04T17:40:24.699656+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./undo_002.zst
2025-11-04T17:40:24.722718+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./undo_002.zst
2025-11-04T17:40:24.722825+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./undo_001.zst
2025-11-04T17:40:24.755290+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./undo_001.zst
2025-11-04T17:40:24.755392+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./mysql/general_log_213.sdi.zst
2025-11-04T17:40:24.760715+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./mysql/general_log_213.sdi.zst
2025-11-04T17:40:24.760830+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./mysql/general_log.CSM.zst
2025-11-04T17:40:24.766136+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./mysql/general_log.CSM.zst
2025-11-04T17:40:24.766202+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./mysql/general_log.CSV.zst
2025-11-04T17:40:24.771030+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./mysql/general_log.CSV.zst
2025-11-04T17:40:24.771184+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./mysql/slow_log_214.sdi.zst
2025-11-04T17:40:24.776180+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./mysql/slow_log_214.sdi.zst
2025-11-04T17:40:24.776240+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./mysql/slow_log.CSM.zst
2025-11-04T17:40:24.781393+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./mysql/slow_log.CSM.zst
2025-11-04T17:40:24.781449+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./mysql/slow_log.CSV.zst
2025-11-04T17:40:24.785794+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./mysql/slow_log.CSV.zst
2025-11-04T17:40:24.785890+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/cond_instances_82.sdi.zst
2025-11-04T17:40:24.790641+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/cond_instances_82.sdi.zst
2025-11-04T17:40:24.790708+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/error_log_83.sdi.zst
2025-11-04T17:40:24.795417+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/error_log_83.sdi.zst
2025-11-04T17:40:24.795508+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/events_waits_his_85.sdi.zst
2025-11-04T17:40:24.800525+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/events_waits_his_85.sdi.zst
2025-11-04T17:40:24.800589+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/events_waits_cur_84.sdi.zst
2025-11-04T17:40:24.804941+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/events_waits_cur_84.sdi.zst
2025-11-04T17:40:24.805008+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/events_waits_his_86.sdi.zst
2025-11-04T17:40:24.809624+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/events_waits_his_86.sdi.zst
2025-11-04T17:40:24.809685+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/events_waits_sum_87.sdi.zst
2025-11-04T17:40:24.814165+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/events_waits_sum_87.sdi.zst
2025-11-04T17:40:24.814218+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/events_waits_sum_88.sdi.zst
2025-11-04T17:40:24.818631+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/events_waits_sum_88.sdi.zst
2025-11-04T17:40:24.818700+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/events_waits_sum_89.sdi.zst
2025-11-04T17:40:24.823346+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/events_waits_sum_89.sdi.zst
2025-11-04T17:40:24.823434+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/events_waits_sum_90.sdi.zst
2025-11-04T17:40:24.828325+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/events_waits_sum_90.sdi.zst
2025-11-04T17:40:24.828459+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/events_waits_sum_91.sdi.zst
2025-11-04T17:40:24.832657+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/events_waits_sum_91.sdi.zst
2025-11-04T17:40:24.832719+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/events_waits_sum_92.sdi.zst
2025-11-04T17:40:24.837125+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/events_waits_sum_92.sdi.zst
2025-11-04T17:40:24.837186+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/file_instances_93.sdi.zst
2025-11-04T17:40:24.841260+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/file_instances_93.sdi.zst
2025-11-04T17:40:24.841325+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/file_summary_by__94.sdi.zst
2025-11-04T17:40:24.845642+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/file_summary_by__94.sdi.zst
2025-11-04T17:40:24.845708+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/file_summary_by__95.sdi.zst
2025-11-04T17:40:24.850048+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/file_summary_by__95.sdi.zst
2025-11-04T17:40:24.850109+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/host_cache_96.sdi.zst
2025-11-04T17:40:24.854740+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/host_cache_96.sdi.zst
2025-11-04T17:40:24.854804+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/mutex_instances_97.sdi.zst
2025-11-04T17:40:24.859652+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/mutex_instances_97.sdi.zst
2025-11-04T17:40:24.859725+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/objects_summary__98.sdi.zst
2025-11-04T17:40:24.864826+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/objects_summary__98.sdi.zst
2025-11-04T17:40:24.864905+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/performance_time_99.sdi.zst
2025-11-04T17:40:24.869709+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/performance_time_99.sdi.zst
2025-11-04T17:40:24.869779+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/rwlock_instances_101.sdi.zst
2025-11-04T17:40:24.874756+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/rwlock_instances_101.sdi.zst
2025-11-04T17:40:24.874869+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/processlist_100.sdi.zst
2025-11-04T17:40:24.879190+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/processlist_100.sdi.zst
2025-11-04T17:40:24.879289+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/setup_actors_102.sdi.zst
2025-11-04T17:40:24.886036+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/setup_actors_102.sdi.zst
2025-11-04T17:40:24.886108+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/setup_consumers_103.sdi.zst
2025-11-04T17:40:24.890831+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/setup_consumers_103.sdi.zst
2025-11-04T17:40:24.890957+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/setup_instrument_104.sdi.zst
2025-11-04T17:40:24.895561+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/setup_instrument_104.sdi.zst
2025-11-04T17:40:24.895670+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/setup_objects_105.sdi.zst
2025-11-04T17:40:24.899829+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/setup_objects_105.sdi.zst
2025-11-04T17:40:24.899946+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/setup_threads_106.sdi.zst
2025-11-04T17:40:24.904601+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/setup_threads_106.sdi.zst
2025-11-04T17:40:24.904658+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/table_io_waits_s_107.sdi.zst
2025-11-04T17:40:24.909639+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/table_io_waits_s_107.sdi.zst
2025-11-04T17:40:24.909709+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/table_io_waits_s_108.sdi.zst
2025-11-04T17:40:24.914081+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/table_io_waits_s_108.sdi.zst
2025-11-04T17:40:24.914148+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/table_lock_waits_109.sdi.zst
2025-11-04T17:40:24.918343+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/table_lock_waits_109.sdi.zst
2025-11-04T17:40:24.918421+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/threads_110.sdi.zst
2025-11-04T17:40:24.922998+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/threads_110.sdi.zst
2025-11-04T17:40:24.923064+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/events_stages_cu_111.sdi.zst
2025-11-04T17:40:24.927213+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/events_stages_cu_111.sdi.zst
2025-11-04T17:40:24.927276+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/events_stages_hi_112.sdi.zst
2025-11-04T17:40:24.932218+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/events_stages_hi_112.sdi.zst
2025-11-04T17:40:24.932280+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/events_stages_hi_113.sdi.zst
2025-11-04T17:40:24.937361+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/events_stages_hi_113.sdi.zst
2025-11-04T17:40:24.937457+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/events_stages_su_114.sdi.zst
2025-11-04T17:40:24.941918+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/events_stages_su_114.sdi.zst
2025-11-04T17:40:24.941991+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/events_stages_su_115.sdi.zst
2025-11-04T17:40:24.946597+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/events_stages_su_115.sdi.zst
2025-11-04T17:40:24.946667+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/events_stages_su_116.sdi.zst
2025-11-04T17:40:24.951119+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/events_stages_su_116.sdi.zst
2025-11-04T17:40:24.951190+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/events_stages_su_117.sdi.zst
2025-11-04T17:40:24.956165+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/events_stages_su_117.sdi.zst
2025-11-04T17:40:24.956236+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/events_stages_su_118.sdi.zst
2025-11-04T17:40:24.960626+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/events_stages_su_118.sdi.zst
2025-11-04T17:40:24.960698+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/events_statement_119.sdi.zst
2025-11-04T17:40:24.964982+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/events_statement_119.sdi.zst
2025-11-04T17:40:24.965041+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/events_statement_120.sdi.zst
2025-11-04T17:40:24.969978+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/events_statement_120.sdi.zst
2025-11-04T17:40:24.970090+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/events_statement_121.sdi.zst
2025-11-04T17:40:24.974550+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/events_statement_121.sdi.zst
2025-11-04T17:40:24.974613+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/events_statement_122.sdi.zst
2025-11-04T17:40:24.978736+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/events_statement_122.sdi.zst
2025-11-04T17:40:24.978800+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/events_statement_123.sdi.zst
2025-11-04T17:40:24.987207+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/events_statement_123.sdi.zst
2025-11-04T17:40:24.987434+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/events_statement_124.sdi.zst
2025-11-04T17:40:25.012604+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/events_statement_124.sdi.zst
2025-11-04T17:40:25.013300+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/events_statement_125.sdi.zst
2025-11-04T17:40:25.019070+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/events_statement_125.sdi.zst
2025-11-04T17:40:25.019146+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/events_statement_127.sdi.zst
2025-11-04T17:40:25.025291+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/events_statement_127.sdi.zst
2025-11-04T17:40:25.025419+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/events_statement_126.sdi.zst
2025-11-04T17:40:25.031834+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/events_statement_126.sdi.zst
2025-11-04T17:40:25.031916+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/events_statement_128.sdi.zst
2025-11-04T17:40:25.036534+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/events_statement_128.sdi.zst
2025-11-04T17:40:25.036608+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/events_statement_129.sdi.zst
2025-11-04T17:40:25.041247+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/events_statement_129.sdi.zst
2025-11-04T17:40:25.041317+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/events_statement_130.sdi.zst
2025-11-04T17:40:25.045871+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/events_statement_130.sdi.zst
2025-11-04T17:40:25.045942+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/events_transacti_131.sdi.zst
2025-11-04T17:40:25.050464+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/events_transacti_131.sdi.zst
2025-11-04T17:40:25.050536+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/events_transacti_132.sdi.zst
2025-11-04T17:40:25.055547+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/events_transacti_132.sdi.zst
2025-11-04T17:40:25.055674+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/events_transacti_133.sdi.zst
2025-11-04T17:40:25.060633+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/events_transacti_133.sdi.zst
2025-11-04T17:40:25.060754+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/events_transacti_134.sdi.zst
2025-11-04T17:40:25.065871+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/events_transacti_134.sdi.zst
2025-11-04T17:40:25.065989+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/events_transacti_135.sdi.zst
2025-11-04T17:40:25.071009+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/events_transacti_135.sdi.zst
2025-11-04T17:40:25.071126+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/events_transacti_136.sdi.zst
2025-11-04T17:40:25.075979+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/events_transacti_136.sdi.zst
2025-11-04T17:40:25.076093+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/events_transacti_137.sdi.zst
2025-11-04T17:40:25.080663+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/events_transacti_137.sdi.zst
2025-11-04T17:40:25.080721+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/events_transacti_138.sdi.zst
2025-11-04T17:40:25.084942+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/events_transacti_138.sdi.zst
2025-11-04T17:40:25.085063+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/events_errors_su_139.sdi.zst
2025-11-04T17:40:25.089051+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/events_errors_su_139.sdi.zst
2025-11-04T17:40:25.089176+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/events_errors_su_140.sdi.zst
2025-11-04T17:40:25.093221+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/events_errors_su_140.sdi.zst
2025-11-04T17:40:25.093344+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/events_errors_su_141.sdi.zst
2025-11-04T17:40:25.097822+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/events_errors_su_141.sdi.zst
2025-11-04T17:40:25.097901+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/events_errors_su_142.sdi.zst
2025-11-04T17:40:25.102195+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/events_errors_su_142.sdi.zst
2025-11-04T17:40:25.102260+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/events_errors_su_143.sdi.zst
2025-11-04T17:40:25.106506+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/events_errors_su_143.sdi.zst
2025-11-04T17:40:25.106581+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/users_144.sdi.zst
2025-11-04T17:40:25.111263+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/users_144.sdi.zst
2025-11-04T17:40:25.111318+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/accounts_145.sdi.zst
2025-11-04T17:40:25.115990+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/accounts_145.sdi.zst
2025-11-04T17:40:25.116105+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/hosts_146.sdi.zst
2025-11-04T17:40:25.120821+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/hosts_146.sdi.zst
2025-11-04T17:40:25.120958+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/socket_instances_147.sdi.zst
2025-11-04T17:40:25.124883+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/socket_instances_147.sdi.zst
2025-11-04T17:40:25.125002+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/socket_summary_b_148.sdi.zst
2025-11-04T17:40:25.129788+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/socket_summary_b_148.sdi.zst
2025-11-04T17:40:25.129929+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/socket_summary_b_149.sdi.zst
2025-11-04T17:40:25.134033+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/socket_summary_b_149.sdi.zst
2025-11-04T17:40:25.134151+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/session_connect__150.sdi.zst
2025-11-04T17:40:25.138105+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/session_connect__150.sdi.zst
2025-11-04T17:40:25.138158+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/session_account__151.sdi.zst
2025-11-04T17:40:25.142150+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/session_account__151.sdi.zst
2025-11-04T17:40:25.142285+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/keyring_keys_152.sdi.zst
2025-11-04T17:40:25.146409+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/keyring_keys_152.sdi.zst
2025-11-04T17:40:25.146473+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/memory_summary_g_153.sdi.zst
2025-11-04T17:40:25.151175+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/memory_summary_g_153.sdi.zst
2025-11-04T17:40:25.151298+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/memory_summary_b_154.sdi.zst
2025-11-04T17:40:25.155247+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/memory_summary_b_154.sdi.zst
2025-11-04T17:40:25.155535+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/memory_summary_b_155.sdi.zst
2025-11-04T17:40:25.159725+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/memory_summary_b_155.sdi.zst
2025-11-04T17:40:25.159776+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/memory_summary_b_156.sdi.zst
2025-11-04T17:40:25.164259+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/memory_summary_b_156.sdi.zst
2025-11-04T17:40:25.164397+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/memory_summary_b_157.sdi.zst
2025-11-04T17:40:25.168750+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/memory_summary_b_157.sdi.zst
2025-11-04T17:40:25.168825+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/table_handles_158.sdi.zst
2025-11-04T17:40:25.173560+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/table_handles_158.sdi.zst
2025-11-04T17:40:25.173620+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/metadata_locks_159.sdi.zst
2025-11-04T17:40:25.177949+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/metadata_locks_159.sdi.zst
2025-11-04T17:40:25.178012+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/data_locks_160.sdi.zst
2025-11-04T17:40:25.182902+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/data_locks_160.sdi.zst
2025-11-04T17:40:25.182965+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/data_lock_waits_161.sdi.zst
2025-11-04T17:40:25.187544+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/data_lock_waits_161.sdi.zst
2025-11-04T17:40:25.187609+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/replication_conn_162.sdi.zst
2025-11-04T17:40:25.192416+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/replication_conn_162.sdi.zst
2025-11-04T17:40:25.192485+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/replication_grou_163.sdi.zst
2025-11-04T17:40:25.197412+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/replication_grou_163.sdi.zst
2025-11-04T17:40:25.197478+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/replication_conn_164.sdi.zst
2025-11-04T17:40:25.201947+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/replication_conn_164.sdi.zst
2025-11-04T17:40:25.202015+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/replication_appl_165.sdi.zst
2025-11-04T17:40:25.206022+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/replication_appl_165.sdi.zst
2025-11-04T17:40:25.206082+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/replication_appl_166.sdi.zst
2025-11-04T17:40:25.210440+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/replication_appl_166.sdi.zst
2025-11-04T17:40:25.210503+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/replication_appl_167.sdi.zst
2025-11-04T17:40:25.214871+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/replication_appl_167.sdi.zst
2025-11-04T17:40:25.214936+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/replication_appl_168.sdi.zst
2025-11-04T17:40:25.219740+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/replication_appl_168.sdi.zst
2025-11-04T17:40:25.219814+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/replication_grou_169.sdi.zst
2025-11-04T17:40:25.224172+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/replication_grou_169.sdi.zst
2025-11-04T17:40:25.224245+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/replication_appl_170.sdi.zst
2025-11-04T17:40:25.228351+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/replication_appl_170.sdi.zst
2025-11-04T17:40:25.228468+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/replication_appl_171.sdi.zst
2025-11-04T17:40:25.233203+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/replication_appl_171.sdi.zst
2025-11-04T17:40:25.233319+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/replication_asyn_172.sdi.zst
2025-11-04T17:40:25.238933+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/replication_asyn_172.sdi.zst
2025-11-04T17:40:25.239094+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/replication_asyn_173.sdi.zst
2025-11-04T17:40:25.246187+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/replication_asyn_173.sdi.zst
2025-11-04T17:40:25.246284+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/log_status_174.sdi.zst
2025-11-04T17:40:25.253874+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/log_status_174.sdi.zst
2025-11-04T17:40:25.253967+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/prepared_stateme_175.sdi.zst
2025-11-04T17:40:25.272402+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/prepared_stateme_175.sdi.zst
2025-11-04T17:40:25.272496+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/user_variables_b_176.sdi.zst
2025-11-04T17:40:25.280533+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/user_variables_b_176.sdi.zst
2025-11-04T17:40:25.280617+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/status_by_accoun_177.sdi.zst
2025-11-04T17:40:25.288632+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/status_by_accoun_177.sdi.zst
2025-11-04T17:40:25.288727+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/status_by_host_178.sdi.zst
2025-11-04T17:40:25.296271+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/status_by_host_178.sdi.zst
2025-11-04T17:40:25.296471+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/status_by_thread_179.sdi.zst
2025-11-04T17:40:25.303218+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/status_by_thread_179.sdi.zst
2025-11-04T17:40:25.303416+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/status_by_user_180.sdi.zst
2025-11-04T17:40:25.315732+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/status_by_user_180.sdi.zst
2025-11-04T17:40:25.315917+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/global_status_181.sdi.zst
2025-11-04T17:40:25.321558+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/global_status_181.sdi.zst
2025-11-04T17:40:25.321637+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/session_status_182.sdi.zst
2025-11-04T17:40:25.325961+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/session_status_182.sdi.zst
2025-11-04T17:40:25.326037+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/variables_by_thr_183.sdi.zst
2025-11-04T17:40:25.330807+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/variables_by_thr_183.sdi.zst
2025-11-04T17:40:25.330892+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/global_variables_184.sdi.zst
2025-11-04T17:40:25.335674+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/global_variables_184.sdi.zst
2025-11-04T17:40:25.335749+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/session_variable_185.sdi.zst
2025-11-04T17:40:25.340530+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/session_variable_185.sdi.zst
2025-11-04T17:40:25.340655+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/variables_info_186.sdi.zst
2025-11-04T17:40:25.345478+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/variables_info_186.sdi.zst
2025-11-04T17:40:25.345584+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/persisted_variab_187.sdi.zst
2025-11-04T17:40:25.349818+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/persisted_variab_187.sdi.zst
2025-11-04T17:40:25.349892+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/user_defined_fun_188.sdi.zst
2025-11-04T17:40:25.354039+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/user_defined_fun_188.sdi.zst
2025-11-04T17:40:25.354102+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/binary_log_trans_189.sdi.zst
2025-11-04T17:40:25.358649+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/binary_log_trans_189.sdi.zst
2025-11-04T17:40:25.358752+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/tls_channel_stat_190.sdi.zst
2025-11-04T17:40:25.362754+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/tls_channel_stat_190.sdi.zst
2025-11-04T17:40:25.362826+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/keyring_componen_191.sdi.zst
2025-11-04T17:40:25.366995+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/keyring_componen_191.sdi.zst
2025-11-04T17:40:25.367058+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/clone_status_406.sdi.zst
2025-11-04T17:40:25.371839+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/clone_status_406.sdi.zst
2025-11-04T17:40:25.371910+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./performance_schema/clone_progress_407.sdi.zst
2025-11-04T17:40:25.376354+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./performance_schema/clone_progress_407.sdi.zst
2025-11-04T17:40:25.376483+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./mysql-bin.000025.zst
2025-11-04T17:40:25.380522+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./mysql-bin.000025.zst
2025-11-04T17:40:25.380581+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./mysql-bin.index.zst
2025-11-04T17:40:25.384675+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./mysql-bin.index.zst
2025-11-04T17:40:25.384736+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./xtrabackup_binlog_info.zst
2025-11-04T17:40:25.389292+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./xtrabackup_binlog_info.zst
2025-11-04T17:40:25.389350+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./ib_buffer_pool.zst
2025-11-04T17:40:25.393580+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./ib_buffer_pool.zst
2025-11-04T17:40:25.393640+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./backup-my.cnf.zst
2025-11-04T17:40:25.398334+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./backup-my.cnf.zst
2025-11-04T17:40:25.398411+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./xtrabackup_info.zst
2025-11-04T17:40:25.402541+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./xtrabackup_info.zst
2025-11-04T17:40:25.402600+08:00 0 [Note] [MY-011825] [Xtrabackup] decompressing ./xtrabackup_tablespaces.zst
2025-11-04T17:40:25.407024+08:00 0 [Note] [MY-011825] [Xtrabackup] removing ./xtrabackup_tablespaces.zst
2025-11-04T17:40:25.510589+08:00 0 [Note] [MY-011825] [Xtrabackup] completed OK! 

2、prepare步骤

xtrabackup --prepare --target-dir=/data/backup/full/full\_20251104\_173434

prepare是物理备份过程中进行恢复前必做的一个环节,它的作用是将备份时处于不一致状态的数据文件,处理成一个具有数据一致性的、可供数据库直接启动和使用的完整备份集。

简单来说,如果不执行 --prepare步骤,直接使用 --backup得到的原始备份文件来启动数据库,InnoDB存储引擎会检测到数据文件内部不一致(例如页面LSN不匹配),并将其视为损坏的数据文件,从而拒绝启动。

这是因为XtraBackup在备份期间,为了尽可能减少对数据库性能的影响,是采用类似“快照”的方式拷贝InnoDB数据文件(.ibd)的。拷贝过程中,数据库可能仍在处理事务,这就导致备份集内的数据文件在同一时刻的状态可能并不一致。–prepare步骤正是通过应用备份期间同时拷贝的redo日志,来修复这种不一致性,确保数据恢复到备份操作完成那一刻的一致性状态。

[root@VM-8-4-opencloudos backup]#  /data/soft/xtrabackup8.0.35-34-glibc2.36/bin/xtrabackup --prepare --target-dir=/data/backup/full/full_20251104_173434
2025-11-04T17:44:13.715402+08:00 0 [Note] [MY-011825] [Xtrabackup] recognized server arguments: --innodb_checksum_algorithm=crc32 --innodb_log_checksums=1 --innodb_data_file_path=ibdata1:200M;ibdata2:200M:autoextend --innodb_log_file_size=50331648 --innodb_page_size=16384 --innodb_undo_directory=./ --innodb_undo_tablespaces=2 --server-id=13045 --innodb_log_checksums=ON --innodb_redo_log_encrypt=0 --innodb_undo_log_encrypt=0 
2025-11-04T17:44:13.715565+08:00 0 [Note] [MY-011825] [Xtrabackup] recognized client arguments: --prepare=1 --target-dir=/data/backup/full/full_20251104_173434 
/data/soft/xtrabackup8.0.35-34-glibc2.36/bin/xtrabackup version 8.0.35-34 based on MySQL server 8.0.35 Linux (x86_64) (revision id: c8a25ff9)
2025-11-04T17:44:13.715602+08:00 0 [Note] [MY-011825] [Xtrabackup] cd to /data/backup/full/full_20251104_173434/
2025-11-04T17:44:13.716155+08:00 0 [Note] [MY-011825] [Xtrabackup] This target seems to be not prepared yet.
2025-11-04T17:44:13.730583+08:00 0 [Note] [MY-011825] [Xtrabackup] xtrabackup_logfile detected: size=8388608, start_lsn=(395899109)
2025-11-04T17:44:13.743037+08:00 0 [Note] [MY-011825] [Xtrabackup] using the following InnoDB configuration for recovery:
2025-11-04T17:44:13.743072+08:00 0 [Note] [MY-011825] [Xtrabackup] innodb_data_home_dir = .
2025-11-04T17:44:13.743084+08:00 0 [Note] [MY-011825] [Xtrabackup] innodb_data_file_path = ibdata1:200M;ibdata2:200M:autoextend
2025-11-04T17:44:13.743119+08:00 0 [Note] [MY-011825] [Xtrabackup] innodb_log_group_home_dir = .
2025-11-04T17:44:13.743127+08:00 0 [Note] [MY-011825] [Xtrabackup] innodb_log_files_in_group = 1
2025-11-04T17:44:13.743135+08:00 0 [Note] [MY-011825] [Xtrabackup] innodb_log_file_size = 8388608
2025-11-04T17:44:13.744761+08:00 0 [Note] [MY-011825] [Xtrabackup] inititialize_service_handles suceeded
2025-11-04T17:44:13.745043+08:00 0 [Note] [MY-011825] [Xtrabackup] using the following InnoDB configuration for recovery:
2025-11-04T17:44:13.745062+08:00 0 [Note] [MY-011825] [Xtrabackup] innodb_data_home_dir = .
2025-11-04T17:44:13.745069+08:00 0 [Note] [MY-011825] [Xtrabackup] innodb_data_file_path = ibdata1:200M;ibdata2:200M:autoextend
2025-11-04T17:44:13.745089+08:00 0 [Note] [MY-011825] [Xtrabackup] innodb_log_group_home_dir = .
2025-11-04T17:44:13.745100+08:00 0 [Note] [MY-011825] [Xtrabackup] innodb_log_files_in_group = 1
2025-11-04T17:44:13.745110+08:00 0 [Note] [MY-011825] [Xtrabackup] innodb_log_file_size = 8388608
2025-11-04T17:44:13.745125+08:00 0 [Note] [MY-011825] [Xtrabackup] Starting InnoDB instance for recovery.
2025-11-04T17:44:13.745137+08:00 0 [Note] [MY-011825] [Xtrabackup] Using 104857600 bytes for buffer pool (set by --use-memory parameter)
2025-11-04T17:44:13.746141+08:00 0 [Note] [MY-012932] [InnoDB] PUNCH HOLE support available
2025-11-04T17:44:13.746162+08:00 0 [Note] [MY-012944] [InnoDB] Uses event mutexes
2025-11-04T17:44:13.746170+08:00 0 [Note] [MY-012945] [InnoDB] GCC builtin __atomic_thread_fence() is used for memory barrier
2025-11-04T17:44:13.746183+08:00 0 [Note] [MY-012948] [InnoDB] Compressed tables use zlib 1.2.13
2025-11-04T17:44:13.746475+08:00 0 [Note] [MY-012951] [InnoDB] Using hardware accelerated crc32 and polynomial multiplication.
2025-11-04T17:44:13.746898+08:00 0 [Note] [MY-012203] [InnoDB] Directories to scan './'
2025-11-04T17:44:13.746943+08:00 0 [Note] [MY-012204] [InnoDB] Scanning './'
2025-11-04T17:44:13.753807+08:00 0 [Note] [MY-012208] [InnoDB] Completed space ID check of 10 files.
2025-11-04T17:44:13.756116+08:00 0 [Note] [MY-012955] [InnoDB] Initializing buffer pool, total size = 128.000000M, instances = 1, chunk size =128.000000M 
2025-11-04T17:44:13.765015+08:00 0 [Note] [MY-012957] [InnoDB] Completed initialization of buffer pool
2025-11-04T17:44:13.770906+08:00 0 [Note] [MY-011951] [InnoDB] page_cleaner coordinator priority: -20
2025-11-04T17:44:13.771119+08:00 0 [Note] [MY-011954] [InnoDB] page_cleaner worker priority: -20
2025-11-04T17:44:13.771183+08:00 0 [Note] [MY-011954] [InnoDB] page_cleaner worker priority: -20
2025-11-04T17:44:13.771564+08:00 0 [Note] [MY-011954] [InnoDB] page_cleaner worker priority: -20
2025-11-04T17:44:13.824205+08:00 0 [Note] [MY-013883] [InnoDB] The latest found checkpoint is at lsn = 395899109 in redo log file ./
#innodb
_redo/
#ib
_redo0.
2025-11-04T17:44:13.824287+08:00 0 [Note] [MY-012560] [InnoDB] The log sequence number 395730540 in the system tablespace does not match the log sequence number 395899109 in the redo log files!
2025-11-04T17:44:13.824305+08:00 0 [Note] [MY-012551] [InnoDB] Database was not shutdown normally!
2025-11-04T17:44:13.824312+08:00 0 [Note] [MY-012552] [InnoDB] Starting crash recovery.
2025-11-04T17:44:13.824504+08:00 0 [Note] [MY-013086] [InnoDB] Starting to parse redo log at lsn = 395898899, whereas checkpoint_lsn = 395899109 and start_lsn = 395898880
2025-11-04T17:44:13.824519+08:00 0 [Note] [MY-012550] [InnoDB] Doing recovery: scanned up to log sequence number 395899109
2025-11-04T17:44:13.843504+08:00 0 [Note] [MY-013083] [InnoDB] Log background threads are being started...
2025-11-04T17:44:13.851994+08:00 0 [Note] [MY-012532] [InnoDB] Applying a batch of 0 redo log records ...
2025-11-04T17:44:13.852026+08:00 0 [Note] [MY-012535] [InnoDB] Apply batch completed!
2025-11-04T17:44:13.952255+08:00 0 [Note] [MY-013084] [InnoDB] Log background threads are being closed...
2025-11-04T17:44:13.957800+08:00 0 [Note] [MY-013888] [InnoDB] Upgrading redo log: 1032M, LSN=395899109.
2025-11-04T17:44:13.957898+08:00 0 [Note] [MY-012968] [InnoDB] Starting to delete and rewrite redo log files.
2025-11-04T17:44:13.957956+08:00 0 [Note] [MY-011825] [InnoDB] Removing redo log file: ./
#innodb
_redo/
#ib
_redo0
2025-11-04T17:44:14.004652+08:00 0 [Note] [MY-011825] [InnoDB] Creating redo log file at ./
#innodb
_redo/
#ib
_redo0_tmp with file_id 0 with size 33554432 bytes
2025-11-04T17:44:14.008311+08:00 0 [Note] [MY-011825] [InnoDB] Renaming redo log file from ./
#innodb
_redo/
#ib
_redo0_tmp to ./
#innodb
_redo/
#ib
_redo0
2025-11-04T17:44:14.011183+08:00 0 [Note] [MY-012893] [InnoDB] New redo log files created, LSN=395899404
2025-11-04T17:44:14.011284+08:00 0 [Note] [MY-013083] [InnoDB] Log background threads are being started...
2025-11-04T17:44:14.023796+08:00 0 [Note] [MY-013252] [InnoDB] Using undo tablespace './undo_001'.
2025-11-04T17:44:14.025816+08:00 0 [Note] [MY-013252] [InnoDB] Using undo tablespace './undo_002'.
2025-11-04T17:44:14.027533+08:00 0 [Note] [MY-012910] [InnoDB] Opened 2 existing undo tablespaces.
2025-11-04T17:44:14.027698+08:00 0 [Note] [MY-011980] [InnoDB] GTID recovery trx_no: 1044267
2025-11-04T17:44:14.226936+08:00 0 [Note] [MY-013776] [InnoDB] Parallel initialization of rseg complete
2025-11-04T17:44:14.226983+08:00 0 [Note] [MY-013777] [InnoDB] Time taken to initialize rseg using 2 thread: 199297 ms.
2025-11-04T17:44:14.229195+08:00 0 [Note] [MY-012923] [InnoDB] Creating shared tablespace for temporary tables
2025-11-04T17:44:14.229302+08:00 0 [Note] [MY-012265] [InnoDB] Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
2025-11-04T17:44:14.260630+08:00 0 [Note] [MY-012266] [InnoDB] File './ibtmp1' size is now 12 MB.
2025-11-04T17:44:14.262027+08:00 0 [Note] [MY-013627] [InnoDB] Scanning temp tablespace dir:'./
#innodb
_temp/'
2025-11-04T17:44:14.287708+08:00 0 [Note] [MY-013018] [InnoDB] Created 128 and tracked 128 new rollback segment(s) in the temporary tablespace. 128 are now active.
2025-11-04T17:44:14.291471+08:00 0 [Note] [MY-012976] [InnoDB] 8.0.35 started; log sequence number 395899414
2025-11-04T17:44:14.292531+08:00 0 [Warning] [MY-012091] [InnoDB] Allocated tablespace ID 1 for sys/sys_config, old maximum was 0
2025-11-04T17:44:14.301258+08:00 0 [Note] [MY-011825] [Xtrabackup] Completed loading of 8 tablespaces into cache in 0.00972792 seconds
2025-11-04T17:44:14.332275+08:00 0 [Note] [MY-011825] [Xtrabackup] Time taken to build dictionary: 0.0309666 seconds
2025-11-04T17:44:15.336933+08:00 0 [Note] [MY-011825] [Xtrabackup] starting shutdown with innodb_fast_shutdown = 1
2025-11-04T17:44:15.337061+08:00 0 [Note] [MY-012330] [InnoDB] FTS optimize thread exiting.
2025-11-04T17:44:16.337034+08:00 0 [Note] [MY-013072] [InnoDB] Starting shutdown...
2025-11-04T17:44:16.440671+08:00 0 [Note] [MY-013084] [InnoDB] Log background threads are being closed...
2025-11-04T17:44:16.461318+08:00 0 [Note] [MY-012980] [InnoDB] Shutdown completed; log sequence number 395899414
2025-11-04T17:44:16.476016+08:00 0 [Note] [MY-011825] [Xtrabackup] completed OK!

当执行prapare过程中 最后出现 completed OK! 关键字时,表明操作成功。

3、停止MySQL服务并清空数据目录

为确保恢复过程顺利,首先需要停止MySQL服务,并清空其数据目录(datadir)。这是恢复操作的关键前提

-- 停止MySQL服务
systemctl stop mysqld
-- 或者登录MySQL数据库 执行 shutdown; 命令

重要提示:在执行rm -rf命令前,务必确认目录路径正确,最好对原有数据做备份。然后清空数据目录:

# 清空MySQL数据目录(请先确认你的datadir路径,假设是/var/lib/mysql)
rm -rf /var/lib/mysql/* 

4、执行数据恢复

使用 --copy-back或 --move-back命令将预备好的备份数据恢复到MySQL的数据目录

xtrabackup --copy-back --target-dir=/path/to/prepared_backup
说明:
 --copy-back:将备份文件复制到数据目录。这是最安全常用的方式,保留原始备份
 --move-back:将备份文件移动到数据目录。更节省空间,但原始备份会消失

5、修改文件权限

恢复的数据文件可能不属于mysql用户,需要更改属主和权限以确保MySQL有权限读写

chown -R mysql:mysql /var/lib/mysql
此命令将数据目录及其下所有文件的所有者和组设置为mysql

6、启动MySQL并确认

权限设置好以后,就可以启动MySQL服务了

systemctl start mysqld
-- 或者使用mysqld_safe --defaults-file=/etc/my.cnf --user=mysql & 方式启动

启动后,务必检查MySQL的错误日志,并使用客户端连接,验证数据库和表是否正常。

总 结

该脚本提供了一个生产环境进行MySQL8.0物理备份所需的完整步骤,包括错误处理、日志记录、自动清理和耗时统计。数据库运维人员可以根据实际环境调整配置参数,特别是备份路径和保留天数设置以及是否采用压缩等一些常用功能的设置。


墨天轮从乐知乐享的数据库技术社区蓄势出发,全面升级,提供多类型数据库管理服务。墨天轮数据库管理服务旨在为用户构建信赖可托付的数据库环境,并为数据库厂商提供中立的生态支持。
墨天轮数据库服务官网:https://www.modb.pro/service

欢迎关注 【InfoQ鸿蒙专区】,获取更多鸿蒙动态、创新实践!

在鸿蒙生态的沃土上,从不缺因热爱奔赴、因坚守发光的身影。他们身份各异 —— 高校学子、行业老兵、技术发烧友、创业者与企业开发者等,皆因鸿蒙的开放包容、分布式能力与友好生态而汇聚。在这里,技术不再是冰冷代码,而是连接亲情、破解痛点、分享经验、传承文化的载体。每一份对生活的洞察与创新的坚守,都能在鸿蒙支持下落地结果。这些故事是千万鸿蒙创作者的缩影,他们践行 “想没有答案,做才有结果” 的初心,让生态愈发蓬勃。

本合集旨在呈现鸿蒙开发者的多元成长与实践,聚焦不同探索方向,彰显鸿蒙生态价值;更以案例为桥,传递创作初心,为开发者点亮方向,吸引更多人加入,共赴技术赋能生活的创新之旅。

🚀推荐案例 01:15 年大数据老兵鸿蒙“造梦”,父女联手打造亲子游戏 App

在鸿蒙开发者生态中,从不缺乏跨界探索的身影。徐俊宸便是其中一位特殊的存在:深耕大数据领域多年,从数据产品经理到大数据讲师,他的职业生涯始终围绕数据打转;而一次偶然的鸿蒙论坛经历,让他萌生了开发 APP 的想法。最终,他以女儿课堂上的猜数字游戏为蓝本,与女儿一起打造出《猜数字大师》游戏应用,在跨界鸿蒙开发的道路上,既攻克了技术难关,也收获了别样的亲子时光。

完整案例内容,请点击链接阅读原文: https://www.infoq.cn/article/rwSKfSRNBoL4HUv85zQ7


🚀推荐案例 02:00 后鸿蒙开发者支一郎:从校园需求出发,用代码搭建跨场景服务桥梁

在鸿蒙开发者生态中,有这样一位特殊的身影:他是 00 后在校大学生,却已凭借全栈技术能力成为 InfoQ 等技术平台的新星创作者;他从校园生活的痛点切入,牵头打造服务上万师生的 “校园智慧服务站”;他以小程序试水职场需求,再借鸿蒙原生能力迭代出融合 RPA 与 AI 的高效工具。他就是支一郎,一位在鸿蒙生态中快速成长的学生开发者,用实际行动诠释着 “年轻开发者如何在新兴生态中找到自己的价值”。

完整案例内容,请点击链接阅读原文https://www.infoq.cn/article/1Su6kKzAuVQ03k8DZqkK


🚀推荐案例 03:从“探索”到“布道”,一个「鸿蒙领航者」的炼成记

2019 年 8 月,即将踏入大学校园的李浩佳第一次在新闻中看到了“HarmonyOS”的名字。那时的他,还只是一个对软件工程充满好奇的新生,未曾想到这会成为他职业生涯的重要注脚。六年过去,鸿蒙已从一个陌生的名词,变成了他日常开发的核心技术栈。他也从一名普通开发者成长为社区的技术分享者,持续为鸿蒙生态贡献力量。李浩佳带着骄傲对 InfoQ 说,由于在国内外平台积极分享,他已经两次获得“HarmonyOS 学习资源创作先锋”的荣誉称号。

完整案例内容,请点击链接阅读原文https://www.infoq.cn/article/27Q3D8PGVvJXA8F5jWKx


🚀推荐案例 04:用“成语”疗愈“心情”,一位鸿蒙开发者的创意与选择

你上一次阅读成语是什么时候?在当下短视频主导的时代,人们的生活日益碎片化,与文字的接触也渐行渐远。“俺也一样”和“提笔忘字”已成为当代青年日常生活的真实写照。语言能力的日益衰退,不仅会削弱表达能力,还会影响个人的认知与思考过程。相关研究显示,一个人的语言水平甚至直接关联其情绪认知与调节能力。基于这一洞察,深圳市蛟龙腾飞网络科技有限公司创始人李洋借助鸿蒙系统,开发了一款名为“成语心情”的应用。该软件根据用户日常心情和工作生活场景,提供针对性的成语学习,帮助深化对情绪与情境的理解。

完整案例内容,请点击链接阅读原文https://www.infoq.cn/article/XXJf0Hd0zQ0JKlAjHgc0


👉更多开发者群像案例,持续上架中,欢迎扫码加入「InfoQ 鸿蒙开发者交流群」,交流技术,也可联系「小助手」约稿~

👀也欢迎关注【InfoQ鸿蒙专区】,获取更多鸿蒙动态、创新实践!

Matrix 首页推荐 

Matrix 是少数派的写作社区,我们主张分享真实的产品体验,有实用价值的经验与思考。我们会不定期挑选 Matrix 最优质的文章,展示来自用户的最真实的体验和观点。 

文章代表作者个人观点,少数派仅对标题和排版略作修改。


当好奇心和一块小小的传感器相遇,我看到了身体对每一餐的真实反馈。

导语: 因为家人的缘故,我对血糖仪一直抱有好奇。它到底能揭示什么?仅仅是冰冷的数字吗?去年年底,一次偶然的机会让我决定亲自戴上动态血糖仪,开启一场为期 14 天的「血糖盲盒」揭秘之旅。我不刻意改变饮食,只想看看最真实的生活如何在我的血液里留下痕迹。结果,一些意料之中的高峰和意料之外的平稳,让我对「吃」这件事有了全新的认知。


为什么我要给自己戴上这个「小圆片」?

动机源于三点:共情、求知与自省

  • 我的母亲是糖尿病患者,动态血糖仪是她管理健康的日常工具。我常想,佩戴它究竟是什么感受?那些波动的曲线背后,是身体怎样的无声诉说?我想亲身感受一下。
  • 其次,是纯粹的数据好奇心。我们总听说「这个升糖快」、「那个要少吃」,但身体的实际反馈究竟如何?我想获得一份关于自己的、直观的【饮食 - 血糖】响应图谱。
  • 最后,是一点私心。自从几年前做过膝盖手术,我的体重悄然增加了近 10 公斤,且减肥之路屡屡受挫。我想知道,是不是日常饮食中某些「隐形」的因素在暗中作祟。

恰逢硅基动感有体验活动,我便领了一个传感器。2025 年 12 月 28  日,我将其安装在上臂,一场与自己身体的坦诚对话,就此开始。

安装过程比想象中简单,这个小圆片将成为未来两周我的数字感官之一。

不设限的 14 天真实生活记录

为了获得最具参考价值的基线数据,我决定不进行任何饮食控制,完全按照平时的习惯吃喝。检测的核心指标是平均葡萄糖值,医学上通常认为非糖尿病者餐后 2 小时血糖应低于 7.8 mmol/L,而动态血糖仪显示的日常波动范围在 3.9-10.0 mmol/L 之间可视为相对理想。

我记录下了每一天的三餐及加餐,并与血糖曲线进行对照。以下是 14 天的饮食日志与当日血糖峰值摘要:

日期饮食记录(早餐 / 午餐、下午茶 / 晚餐)当日血糖峰值 (mmol/L)
12/29面包 / 喜家德水饺、拿铁 / 炸酱面8.5
12/30麦当劳早餐 / 麻辣烫、拿铁 / 汉堡三件套9.8
12/31麦当劳早餐 / 泰国菜、拿铁 / 大肠粉8.4
01/01面包一片 / 汉堡套餐 / 鸡翅煲10.7
01/02炒饭 / 意大利餐厅(披萨、冷餐肉等)11.7
01/03Pizza、炒饭 / 胡子大厨10.5
01/04面包一片、鸡蛋一个 / 卤肉饭9.7
01/05元宵 / 便当 / 麻辣烫9.2
01/06燕麦 / 大米先生 / 江西客家菜10.9
01/07酒店早餐 / 江西菜 / 拌粉9.3
01/08酒店早餐 / 潮汕菜 / 重庆小面8.9
01/09泡面 / 超级碗 / 味千拉面8.6
01/10燕麦 / 盒马烧腊 / 炒饭肉汉堡9.1

注:头尾两天为传感器启动/失效期,数据不计入分析

这是 14 天所有血糖曲线的叠加图,可以直观看到每天的波动模式:

14 天血糖变化曲线迭加图

我的饮食「红黑榜」

将数据与饮食记录交叉分析后,一些清晰的模式浮现出来。

🔴 「黑榜」:血糖过山车组合

这几餐让我的血糖经历了剧烈波动,峰值均突破10.0 mmol/L,且有一定的波动幅度。

冠军峰值(1 月 2 日,11.7 mmol/L):炒饭 + 意式大餐

中午的炒饭(精制碳水,高 GI)已让血糖处于高位,晚上的披萨、芝士等(高脂+精碳)组合,产生了典型的「糖脂协同」效应——脂肪延缓胃排空,使得碳水化合物被更缓慢但更持久地吸收,导致血糖峰值更高、持续时间更长

隐形糖分陷阱(1月6日,10.9 mmol/L):江西客家菜

这道菜给我的教训是:「不辣不等于健康」。许多餐厅菜肴为了提鲜,会在酱汁中放入大量糖或使用勾芡,这些「隐形碳水」是血糖的隐形推手。

经典快餐冲击(1月1日,10.7 mmol/L):汉堡套餐(含薯条和部分可乐)

高 GI 面包、油炸淀粉、含糖饮料的「三重奏」,带来了快速而陡峭的血糖高峰。这几乎是教科书式的血糖剧烈波动案例。

拿铁的「二次波峰」:每天喝两杯拿铁

数据清晰显示,午餐后的一杯拿铁,常常会在午餐主峰后,催生出一个独立的第二峰」。这可能是牛奶中的乳糖与咖啡因共同作用的结果,提醒我需要注意饮用时机。

🟢 「红榜」:意料之外的平稳

有些我以为会「爆表」的餐食,血糖反应却出奇地平稳。

  • 喜家德水饺:与同事聚餐,吃了不少饺子,饱腹感极强,但血糖峰值仅 8.5 mmol/L,波动平缓。推测原因是饺子馅料中的蛋白质、蔬菜和饺子皮的复合结构,减缓了碳水消化速度。
  • 盒马烧腊双拼:尽管便当盒底积了厚厚一层油,看起来非常「罪恶」,但吃完后血糖并未大幅飙升(峰值 9.1 mmol/L)。这可能是因为烧腊(蛋白质+脂肪)为主,搭配的米饭量相对固定,形成了缓冲。
  • 清净烹饪的菜肴:如潮汕菜、超级碗(健康餐)等日子,血糖曲线非常平稳,(变异系数)低,(目标范围内时间)接近 100%。它们的共同点是食材原味、烹饪清淡、营养结构相对均衡(有菜、有肉、有主食)。

一个关键的正向案例:对比 1 月 1 日(单一片面包,血糖后高)和 1 月 4 日(一片面包+一个鸡蛋,血糖平稳),蛋白质的缓冲作用一目了然。鸡蛋显著延缓了碳水化合物的吸收,让血糖上升曲线变得温和。

动态血糖监测的价值不在于绝对值,而在于「相对变化」

14 天结束后,我撕下了传感器。

14 天佩戴结束

佩戴期间洗澡、运动(攀岩)均无碍,但皮肤会有轻微压痕,建议长期佩戴者定期更换部位。

这次实验给我最深的体会是:对于非糖尿病患者,动态血糖仪的核心价值,并非监测是否超标,而是揭示不同生活方式下的相对变化模式。

指尖血测的是某个瞬间的绝对血糖值,而动态血糖仪描绘的是一段连续的趋势图。它告诉你:哪种食物组合对你来说是「血糖炸弹」?你的身体对咖啡因、进餐时间有何反应?怎样的饮食顺序和结构能带来更平稳的曲线?

这些洞察,远比一个孤立的数字更有指导意义。它让我从「听说某某食物升糖」,进化到「看到自己身体对某某食物的真实反应」。这种基于自身数据的认知,是任何通用健康建议都无法替代的。

写在最后:一场值得的自我探索

这次「血糖盲盒」实验,成本不高,收获却远超预期。它像一面镜子,让我更客观地审视自己的饮食习惯。我并非要从此与美食为敌,而是知道了「代价」是什么,以及如何通过简单的调整(比如先吃菜肉、后吃主食,或增加蛋白质搭配)来平衡享受与健康。

在物质丰裕的今天,我们面对的诱惑太多。了解身体,或许是迈向更健康生活的第一步。如果你也对身体内部的奥秘充满好奇,或者正在为体重、精力问题困扰,不妨尝试一次这样的自我量化。它未必会给出所有答案,但一定会为你点亮一盏灯,照亮你从未看清的角落。

希望我们都能在享受美食的同时,与自己的身体和谐共处。吃嘛嘛香,更要吃得明明白白。

> 关注 少数派小红书,感受精彩数字生活 🍃

> 实用、好用的 正版软件,少数派为你呈现 🚀

    从训练到推理:智算需求正在经历一场结构性转向

    过去一年,如果仅从“算力需求增长”来理解中国智算产业的变化,显然是不够的。

     

    在 2026 年 1 月 21 日举办的金山云年度 Tech Talk 上,金山云对其过去一年智算业务的演进进行了系统性回顾。从公开财报数据到客户侧真实使用情况,这些信息拼凑出了一幅更清晰的图景:智算需求并非简单放量,而是在训练、推理、应用形态和工程方式等多个层面同时发生结构性变化

     

    这场变化的核心,不再只是“谁拥有更大规模算力”,而是围绕模型如何被使用、Token 如何被消耗、算力如何被组织展开。

     

    变化首先体现在财务数据上。

     

    根据金山云披露的公开财报,其智算云业务在过去一年实现了高速增长。以 2025 年第三季度为例,智算云账单收入达到 7.8 亿元人民币,同比增长接近 120%。这一数据并非孤立,而是延续了此前多个季度的增长趋势,显示智算已成为金山云收入结构中的重要组成部分。

     

    金山云高级副总裁刘涛在分享中提到了金山云对这一趋势的判断:智算需求的增长重心,正在从训练侧逐步向推理侧转移。

     

    从训练视角看,过去几年国内智算需求的主要推动力,来自少数对算力高度敏感的行业。

     

    自动驾驶与具身智能,是其中最典型的代表。这些行业往往需要长期训练模型,并处理视频、点云、传感器等海量多模态数据。在早期阶段,它们对算力的需求更多集中在训练规模本身。

     

    但与通用大模型不同,这类行业模型并不一味追求参数规模最大化。刘涛在分享中指出,自动驾驶和具身智能模型在训练阶段,对算力密度的要求并不极端,但对显存容量和数据处理能力要求更高。

     

    这意味着,它们对算力平台的诉求,正在从“算力数量”转向“系统能力”——包括数据接入、预处理、多模态调度以及训练全流程的工程化效率。

     

    推理侧的变化更加显著。

     

    如果说训练侧的变化仍然是渐进的,那么推理侧的变化则更为直接和激烈。

     

    一个被反复引用的数据,来自火山引擎在其公开发布会上的披露:平台每日 Token 调用量已达到 50 万亿级别。这是当前国内少数被明确对外公布的 Token 规模数据之一,也成为行业理解推理负载的重要参考。

     

    与此同时,多个面向大众或企业的模型产品正在持续扩大推理需求。例如豆包、通义千问以及近期加大投入的腾讯元宝,都在不同程度上推动 Token 消耗快速增长。

     

    这些产品并不完全运行在同一云平台上,但它们共同指向一个事实:推理阶段正在成为智算需求增长的主要来源,且这种增长具备明显的外溢性。

     

    在所有推理场景中,编程类应用被反复强调。

     

    刘涛指出,2025 年一个尤为显著的变化在于:编程相关请求正在成为 Token 消耗的主力场景之一。这一判断并非孤立,而是与海外模型使用结构的统计结果高度一致。

     

    “Vibe Coding”成为一个关键词。一个广为流传的事实是,Claude Code 的大量代码本身,正是由 Claude Code 参与生成的。这意味着模型不再只是辅助工具,而是深度介入软件生产过程。

     

    从全球 Token 调用结构来看,编程类请求在多家模型服务商中长期占据最高比例。金山云也观察到了同样的趋势:代码生成、重构和理解能力的提升,正在显著改变程序员的工作方式,并直接放大推理侧算力需求。

     

    在具体应用层面,互联网客户仍然是智算需求的重要来源,但其需求形态已经发生变化。刘涛提到,当前互联网场景呈现出三个明显特征:

     

    其一,多模态需求显著增长。视频生成、视频理解以及复杂推理任务,带动了训练与推理负载的持续上升;

    其二,模型参数规模不再单向膨胀,而是围绕具体任务进行结构性调整;

    其三,Vibe Coding 在头部互联网公司中已较为普及,使用更强的商用模型进行代码开发,正在成为常态。

     

    这些变化意味着,互联网客户对智算平台的期待,已经从“算力服务”升级为对模型生命周期管理和工程体系的整体依赖。

     

    为了满足更多元化的需求,刘涛表示,2025 年,智算平台金山云星流已完成从资源管理平台向一站式 AI 训推全流程平台的战略升级。从训推平台、机器人平台到模型 API 服务,升级后的金山云星流平台构建了从异构资源调度、训练任务故障自愈到机器人行业应用支撑、模型 API 服务商业化落地的全链路闭环。

    实现三维进阶,智算云 AI 势能全释放

     

    尽管各行各业大规模应用 AI 还处于早期探索阶段,但定位行业助力者的金山云,多年来持续打磨全栈 AI 能力。从 2023 年的智算网基础设施,到 2024 年智算云的平台化和 Serverless 化,再到 2025 年的一站式 AI 训推全流程平台,通过提升平台效率、突破行业边界、加速推理布局,金山云为迎接 AI 应用爆发做好了充分准备。

     

    在平台效率方面,金山云星流训推平台提供从模型开发、训练到推理的完整生命周期管理,具备开发、训练、推理和数据处理四大模块能力,通过降低多模块协同复杂度,能实现“开箱即用”的 AI 开发体验。自研的 GPU 故障自愈技术结合任务可观测性设计,可实时监控硬件健康状态与任务进程,自动触发故障迁移与任务重调度,降低算力中断风险,保障长周期训练任务稳定运行。

     

    作为面向机器人开发与落地的全链路云原生平台,金山云星流机器人平台深度融合数据采集、存储、标注、模型开发、训练、部署与仿真等核心环节,打造具身场景专属的数据、模型、仿真一体化引擎。平台率先实现具身智能数据工程领域采集、标注、管理的全链路闭环,可高效服务具身智能行业模型训练、仿真应用场景分析等核心需求,助力客户快速完成从算法研发到真实场景部署的全流程落地,最终推动机器人产业的智能化升级。

     

    面向大模型应用开发者和企业用户,金山云星流平台模型 API 服务提供高可用、易集成的模型调用与管理能力,覆盖模型调用的全生命周期。该服务支持高并发推理与多模型管理,能够帮助用户高效接入多种模型资源,助力大模型应用落地。目前,金山云星流平台模型 API 服务已积累诸多行业客户。

     

    同时,金山云星流平台的模型生态也在持续丰富。目前,平台已支持近 40 种不同模型,包括 DeepSeek、Xiaomi MiMo、Qwen3、Kimi 等。客户通过一站式访问,即可高效接入多种模型,在畅享稳定高效云服务的同时,更加聚焦 AI 业务创新和价值创造。

    在企业数字化转型中,CRM已从“销售工具”升级为“全链路协同平台”。本文选取超兔一体云、Oracle CX、Capsule CRM、智赢云CRM、橙子CRM五大主流品牌,围绕线索到回款闭环、后端供应链管理、协同工具对接三大核心场景,结合流程、数据、易用性多维度对比,为企业选型提供决策依据。

    一、对比框架说明

    本次对比聚焦4大核心维度、12项细分指标,覆盖企业从“获客”到“复购”的全生命周期需求:

    1. 线索到回款闭环:流程完整性、自动化能力、行业合规性;
    2. 后端供应链管理:库存/采购/财务联动、上下游协同;
    3. 协同工具对接:企业微信/钉钉的集成深度、数据同步能力;
    4. 综合适配性:行业适配、易用性、成本投入。

    二、核心能力深度对比

    (一)线索到回款闭环:从“流程覆盖”到“智能驱动”

    线索到回款是CRM的核心价值,其能力差异直接决定销售效率与风险控制能力。以下通过流程覆盖、自动化、合规性三个维度对比:

    1. 对比表格:线索到回款闭环能力

    品牌覆盖流程自动化能力合规性支持典型场景
    超兔一体云线索→分配→跟进→订单→回款→财务智能分配/自动应收拆分/凭证生成通用场景全业态中小到中大型企业
    Oracle CX线索→商机→报价→订单→ERP协同SFA/CPQ/自动同步ERP库存金融/医疗合规审查大型复杂行业(如制造)
    Capsule CRM线索→培育→商机→合同→回款线索评分/阶段自动提醒基础报价审批中小企业轻量级管理
    智赢云CRM潜在客户→报价→合同→回款→售后自定义阶段提醒/续约提醒无明确说明销售导向型企业
    橙子CRM订单→库存→回款库存联动/智能补货零售折扣控制小型零售/电商企业

    2. 流程可视化:超兔vs Oracle的闭环差异

    超兔一体云:全链路原生闭环(Mermaid流程图)

    暂时无法在飞书文档外展示此内容

    Oracle CX:需ERP协同的复杂闭环(Mermaid流程图)

    暂时无法在飞书文档外展示此内容

    (二)后端供应链管理:从“进销存”到“全链路协同”

    后端管理直接影响企业成本控制与供应链效率,本次对比库存、采购、财务、上下游四大模块:

    1. 对比表格:后端管理能力

    品牌库存管理采购模型财务联动上下游协同
    超兔一体云500仓库/多成本/SKU/序列号4种模型(缺口/总缺口/一单一采/直发)一键生成凭证/业务财务衔接OpenCRM全流程协同
    Oracle CX需ERP协同/实时库存同步ERP采购流程ERP财务记账/应收联动ERP供应链协同
    Capsule CRM基础库存/BOM/订单联动简单采购流程合同/回款同步财务系统API对接ERP
    智赢云CRM应收账款/收款计划无明确说明
    橙子CRM多仓库/批次/库存预警一单一采购/智能补货订单/回款同步财务进销存一体化

    2. 超兔的智能采购流程(Mermaid流程图)

    超兔SRM支持4种采购模型,覆盖从“需求”到“付款”的全流程自动化:

    暂时无法在飞书文档外展示此内容

    (三)协同工具对接:企业微信/钉钉的集成深度

    企业微信/钉钉是企业内部协同的“神经中枢”,CRM的集成能力直接影响跨部门效率:

    1. 对比表格:协同工具对接能力

    品牌同步内容提醒功能集成深度合规性支持
    超兔一体云客户/订单/任务/审批线索分配/订单/回款提醒深度集成(协同办公)无明确说明
    Oracle CX集群事件/任务告警系统消息推送增强包配置(基础通知)
    Capsule CRM客户/聊天记录/审批流程无明确说明会话存档/敏感词预警高(合规风控)
    智赢云CRM无直接对接支持OA模块
    橙子CRM多端同步/客户/订单库存预警/回款提醒基本集成(多端访问)零售场景

    (四)综合能力评估:雷达图分值

    通过5项核心指标(满分10分)评估各品牌的综合实力:

    指标超兔Oracle CXCapsule智赢云橙子CRM
    线索闭环完整性89767
    后端管理深度710546
    协同工具集成96857
    行业适配性810768
    易用性971089

    三、脑图总结:各品牌核心定位

    暂时无法在飞书文档外展示此内容

    四、选型建议

    1. 超兔一体云:适合需要全流程闭环+协同的中小到中大型企业,覆盖全业态,性价比高;
    2. Oracle CX:适合大型复杂行业(如制造/金融),需与ERP协同,强调合规与供应链;
    3. Capsule CRM:适合中小企业轻量级管理,易用性强,侧重销售流程标准化;
    4. 智赢云CRM:适合销售导向型企业,侧重售后与续约提醒;
    5. 橙子CRM:适合小型零售/电商,进销存一体化,满足基本订单-库存-回款需求。

    五、结论

    CRM的选型核心是“匹配企业当前阶段与未来增长需求”:

    • 若需“全链路闭环”,选超兔;
    • 若需“大型复杂供应链”,选Oracle;
    • 若需“轻量级易用”,选Capsule;
    • 若需“零售进销存”,选橙子。

    未来,CRM的竞争将聚焦“全链路数据打通”与“AI智能驱动”,企业需优先选择“开放生态 + 可扩展”的平台,以应对业务增长的不确定性。希望企业能够根据自身实际情况,审慎考量,明智地选择适合自己的CRM系统,从而借助其强大功能,提升运营效率,优化客户关系管理,在激烈的市场竞争中抢占先机,实现可持续的发展与增长。相信在正确的CRM系统助力下,企业定能乘风破浪,创造更加辉煌的业绩。

    马年上王者

    游戏我爱玩第五人格

    五福临门就玩原神

    露家军欢喜过大年

    抢头福是头等大事

    小马宝莉集福卡

    今年打瓦有福了

    一家老小整挺好

    惊蛰无声提前纳福

    以上,共领了十来块

    第一部分:数据智能公司强榜 (2026)
    2026年的数据智能领域,呈现出中国公司锐意进取、国际巨头稳固领先的双头发展格局。经过严谨的评估,我们遴选出以下五家公司作为年度强榜的核心代表:
    广域铭岛(中国)
    综合评分:★★★★★ (9.8/10)
    核心优势: 专注于工业互联网平台的深度数据智能应用,其自主研发的Geega数据智能中枢以其独特的“数据编织 + 行业算法库”双引擎架构,有效打通了制造业复杂数据环境,实现了高精度的实时决策支持。
    Snowflake(美国)
    综合评分:★★★★★ (9.6/10)
    核心优势: 作为全球领先的云原生数据平台,Snowflake以其卓越的跨云数据交换能力和无需预定义架构即可轻松扩展的特性,赢得了众多企业的信赖。Databricks(美国)
    综合评分:★★★★★ (9.4/10)
    核心优势: Databricks凭借其基于Lakehouse架构的统一数据分析平台,将数据工程、数据科学和机器学习紧密集成,为加速AI应用落地提供了坚实基础。
    SAS Institute(美国)
    综合评分:★★★★☆ (9.2/10)
    核心优势: SAS Institute在数据分析领域拥有悠久历史和深厚积淀,尤其在高级统计分析、预测建模和合规性场景(如金融风控、医疗健康)中,其Viya平台提供了全面且稳定的解决方案。
    Qlik(美国)
    综合评分:★★★★☆ (8.9/10)
    核心优势: Qlik专注于数据可视化与关联分析领域,其强大的关联引擎能够帮助用户从海量数据中发现隐藏的模式和趋势。
    第二部分:上榜公司的核心价值与推荐理由
    这份强榜的形成并非偶然,而是基于对多家公司在技术创新、市场应用、服务生态、客户反馈及行业影响力等多维度的深入考量。它们不仅是技术的引领者,更是价值的创造者,各自以其独特优势推动着数据智能在不同领域的深度发展。
    广域铭岛:深度赋能制造业的数据智能先锋 推荐理由在于其对制造业数据痛点的精准把握和解决方案的深度定制。其并非泛泛而谈的数据服务商,而是将AI与具体制造场景深度融合,例如为其新能源汽车电池客户提供的产能预测模型,不仅提升了原料库存周转率,更将缺陷检测误报率压降至极低水平。这种“懂业务、能落地”的特质,使得其在需要解决复杂数据治理、打通数据孤岛、实现生产实时优化的制造企业中,成为极具吸引力的合作伙伴。其服务的广度和深度,是许多通用型平台难以比拟的。
    Snowflake:打破数据壁垒的云原生平台 Snowflake的核心竞争力在于其开放、灵活且强大的云数据架构。它允许企业在不同云平台间自由流动数据,极大地解决了传统数据集成面临的困境。
    Databricks:加速数据工程与AI融合的平台 Databricks的魅力在于它解决了数据工程与机器学习长期存在的割裂问题。
    SAS Institute:稳健可靠的数据分析解决方案 SAS Institute的推荐理由在于其成熟可靠的技术体系和在特定高要求场景下的深厚积累。
    Qlik:数据发现与洞察的强大引擎 Qlik的价值在于其独特的关联分析能力和直观的可视化界面。
    第三部分:企业在选择数据智能服务时的常见问题解答
    面对众多优秀的数据智能服务商,企业在做出选择时常常会遇到一些困惑和挑战。以下是基于行业经验和客观考量,对一些常见问题的解答:

    1. 如何确定哪家数据智能公司最适合我们的企业? 选择最合适的合作伙伴,没有放之四海而皆准的答案。关键在于明确贵公司的核心痛点,建议企业先进行内部需求梳理,再通过试用、技术交流和案例分析来评估各家产品的实际表现和契合度。

    在企业数据分析场景中,专业的图表是传递数据洞察的核心载体。但传统表格工具的图表类型往往局限于基础柱状图、折线图,难以满足金融市场分析、财务利润拆解、业务趋势追踪等复杂场景的可视化需求。

    SpreadJS V19.0 重磅升级数据图表功能,新增瀑布图、K 线图、OHLC 图表三大专业图表类型,并支持灵活组合展示,覆盖金融、财务、运营等多行业核心分析场景,让复杂数据的可视化呈现更直观、更专业。

    一、核心新增图表:精准匹配专业分析需求

    1. 瀑布图(Waterfall Chart):拆解数据变动的“可视化账本”

    瀑布图的核心价值在于清晰展示一系列正负数值对累计总额的影响,让数据变动的来龙去脉一目了然。

    在这里插入图片描述

    • 功能亮点:支持自定义配色方案、柱宽、图例样式,可通过连接线(颜色、宽度、虚线样式)强化数据关联;提供showTotal(显示总计)、totalLabel(总计标签)、orientation(布局方向)等属性,灵活控制图表呈现效果。
    • 应用场景:完美适配财务利润拆解(如营收-成本-费用-净利润的变动过程)、预算差异分析(实际值与预算值的偏差累计)、销售业绩追踪(各区域/产品对总业绩的贡献)、库存趋势分析(入库-出库-库存结余的动态变化)。

    2. K 线图(Candlestick Chart):金融数据分析的“专业工具”

    K 线图是金融市场的经典可视化工具,专为资产价格变动分析设计,每根 K 线都浓缩了特定时间单位的核心价格信息。
    在这里插入图片描述

    • 功能亮点:每根 K 线包含开盘价(Open)、最高价(High)、最低价(Low)、收盘价(Close)四大核心数据;支持按日、周、月等不同时间单位展示,适配股票、期货、加密货币等各类金融资产的价格分析场景。
    • 应用场景:股票价格走势分析、期货合约波动监测、基金净值变动追踪、金融产品风险评估等专业金融场景,帮助分析师快速判断市场趋势与价格波动幅度。

    3. OHLC 图表(Open-High-Low-Close Chart):金融数据的“极简可视化方案”

    OHLC 图表与 K 线图功能互补,以简洁的柱状线形式展示资产价格变动,更侧重核心价格点的直观呈现。

    在这里插入图片描述

    • 功能亮点:支持两种数据模式——四值模式(开盘价、最高价、最低价、收盘价)和三值模式(最高价、最低价、收盘价);可通过 API 灵活配置数据绑定与样式,适配不同精度的分析需求。
    • 应用场景:与 K 线图搭配使用,适合对价格数据进行轻量化展示的场景,如金融资讯平台的行情概览、移动端的简洁化数据展示、多资产价格对比分析等。

    4. 组合图表:灵活搭配满足复合分析需求

    除了新增单一专业图表,SpreadJS V19.0 还支持将新增图表与现有图表类型(如折线图、柱状图)组合展示。

    在这里插入图片描述

    • 功能亮点:可在同一图表画布中绑定多组不同类型数据,通过分层展示实现复合分析(如 K 线图+均线图组合,同时呈现价格走势与趋势判断依据)。
    • 应用场景:金融市场的“价格+成交量”组合分析、财务报表的“实际值+预算值+偏差率”三重展示、运营数据的“业绩+增长率+目标线”综合呈现。

    二、技术优势:低代码集成,高灵活自定义

    SpreadJS V19.0 新增图表类型延续了产品“易用性+专业性”的核心优势,让开发者无需复杂开发即可快速落地:

    • 高兼容性:无缝适配 SpreadJS 现有表格生态,支持与公式计算、数据透视表、条件格式等功能联动,数据更新时图表实时同步。
    • 低代码配置:通过简洁的 API 即可完成图表初始化与参数配置,支持静态引用或 NPM 包导入两种集成方式,上手成本低。
    • 全场景适配:支持 Web 端、移动端等多终端展示,图表样式自动适配不同屏幕尺寸;兼容主流浏览器,无额外依赖。
    • 深度自定义:从数据绑定到样式细节(颜色、字体、线条)均可通过 API 灵活调整,满足企业个性化品牌视觉需求。

    三、典型应用场景:覆盖多行业核心分析需求

    • 财务领域:用瀑布图拆解企业季度利润构成(营收→成本→税费→净利润),让管理层直观看到各环节对最终利润的影响。
    • 金融领域:用 K 线图+OHLC 图表组合展示股票日内价格波动,搭配成交量柱状图,帮助投资者判断市场情绪与价格趋势。
    • 运营领域:用瀑布图追踪月度 GMV 变动(新增用户贡献-流失用户影响-活动拉动-最终 GMV),快速定位业务增长或下滑的核心驱动因素。
    • 库存领域:用瀑布图展示月度库存变动(期初库存+入库量-出库量-损耗量=期末库存),优化库存管理决策。

    结语

    SpreadJS V19.0 新增的三大专业图表,填补了传统表格工具在复杂场景可视化上的空白,让开发者无需依赖第三方图表库,即可在表格内实现从数据录入、计算到专业可视化的全流程闭环。

    无论是金融行业的价格分析、财务领域的利润拆解,还是运营场景的趋势追踪,这些专业图表都能帮助企业挖掘数据深层价值,让决策更有依据。SpreadJS V19.0 即将正式发布,欢迎持续关注,届时可通过官网 Demo 体验全新图表功能的强大能力!

    扩展链接

    可嵌入您系统的在线Excel

    在企业日常数据处理中,文本类数据的分析往往是效率瓶颈:客户评论需要手动分类标注、多语言业务文档要依赖第三方翻译工具、海量反馈的情感倾向难以快速判断……这些场景下,传统表格工具只能提供基础数据存储,无法实现智能化处理,导致开发者需额外搭建工具链,业务流程繁琐且效率低下。

    GcExcel V9.0 重磅升级 AI 功能,新增 AI.QUERY、AI.TRANSLATE、AI.TEXTSENTIMENT 三大核心函数,将先进的语言模型能力直接集成到表格公式中,无需复杂开发即可实现文本智能查询、多语言翻译、情感倾向分析,让服务器端电子表格引擎从“数据计算工具”升级为“智能分析平台”。

    一、核心 AI 功能:三大函数,覆盖全场景文本智能处理

    1. AI.QUERY:自然语言驱动的文本智能查询

    AI.QUERY 支持通过自然语言指令,对表格中的文本数据进行自定义分析和提取,无需编写复杂逻辑即可实现数据分类、信息抽取等需求。

    • 功能亮点:支持结合上下文指令与分类维度,对目标数据进行精准分析。例如输入“分析这些评论,基于‘情感倾向’和‘讨论主题’分类”,即可自动输出结构化结果。
    • 应用场景:客户反馈分类(提取产品优缺点)、市场调研数据整理(按需求标签归类)、内部文档关键词提取、多维度业务数据筛选。
    • 示例效果:对餐厅评论数据执行公式 =AI.QUERY("evaluate these reviews ", A6:A13, "based on these categories ",B5:C5),系统自动识别每条评论的情感倾向(正面/负面)和讨论主题(食物、服务、价格等),生成结构化分析结果。

    2. AI.TRANSLATE:高效灵活的多语言翻译

    AI.TRANSLATE 支持单文本或批量文本的多语言翻译,直接在表格中完成跨语言数据转换,无需切换第三方工具。

    • 功能亮点:支持主流语言互译,兼容单单元格翻译与多单元格批量翻译,翻译结果实时同步,适配业务文档、客户沟通、跨境数据处理等场景。
    • 应用场景:跨境业务报表翻译、多语言客户咨询回复、国际团队文档协同、海外市场数据本地化处理。
    • 示例效果:执行公式 =AI.TRANSLATE(A14:A18, B14),可将英文文本批量翻译为日语;单文本翻译通过 =AI.TRANSLATE(A6, B6) 即可实现英文到中文的快速转换,翻译结果精准贴合语境。

    3. AI.TEXTSENTIMENT:精准的文本情感分析

    AI.TEXTSENTIMENT 能够自动识别文本数据的情感倾向,支持自定义情感标签(正面/负面/中性),快速量化文本情绪特征。

    • 功能亮点:无需训练模型,直接通过公式调用即可输出情感分析结果,支持批量处理海量文本,适配短文本(评论、留言)与长文本(反馈报告、邮件)。
    • 应用场景:客户满意度调研、社交媒体舆论监测、员工反馈情绪分析、产品评价口碑追踪。
    • 示例效果:对产品评论执行公式 =AI.TEXTSENTIMENT(A6:A13, "Positive", "Negative", "Neutral"),系统自动判定每条评论的情感类别,快速区分正面好评、负面吐槽与中性反馈。

    二、技术优势:灵活集成,兼顾高效与安全

    GcExcel V9.0 的 AI 功能并非简单嵌入第三方模型,而是基于“可扩展、低代码、高安全”的设计理念,适配企业级应用需求:

    1. 可插拔 AI 模型架构

    核心基于 IAIModelRequestHandler 接口,不绑定特定 AI 供应商。开发者可灵活对接 OpenAI、Azure OpenAI、DeepSeek、Qwen 等主流模型,自主管理 API 密钥、端点和模型名称,兼顾业务灵活性与合规要求。

    2. 低代码无缝集成

    AI 功能以表格公式形式提供,无需额外编写复杂代码。现有工作表只需直接调用 AI 函数,即可快速启用智能分析能力,与现有公式、数据透视表、报表导出等功能无缝兼容,升级成本极低。

    3. 完善的错误处理机制

    针对 AI 模型调用中的常见问题,提供明确的错误代码反馈:

    • #BUSY!:请求正在处理中
    • #CONNECT!:网络或模型处理程序故障
    • #VALUE!:执行逻辑异常
    • #NA!:未配置 AI 模型处理程序

    帮助开发者快速定位问题,保障业务稳定性。

    4. 安全合规设计

    支持本地部署或私有 AI 模型对接,避免敏感数据外流;提供日志记录能力,可追踪 AI 调用过程与结果,满足企业数据安全与合规审计需求。

    三、典型应用场景:赋能多行业智能数据处理

    GcExcel V9.0 的 AI 功能已深度适配企业高频业务场景,让智能分析融入数据处理全流程:

    • 客户反馈分析:批量处理电商评论、APP 反馈,通过 AI.QUERY 提取核心诉求,AI.TEXTSENTIMENT 量化满意度,快速定位产品优化方向。
    • 跨境业务协同:通过 AI.TRANSLATE 实现多语言订单报表、客户合同的实时翻译,消除跨地区沟通障碍,提升业务效率。
    • 市场调研数据整理:对多渠道调研问卷中的开放文本回答,用 AI.QUERY 按主题分类,AI.TEXTSENTIMENT 分析倾向,快速形成数据洞察。
    • 内部管理优化:分析员工满意度调查中的文本反馈,自动识别正面/负面评价及核心诉求,为企业管理决策提供数据支持。

    四、功能效果预览

    在这里插入图片描述

    (说明:展示表格中客户评论数据通过 AI.QUERY 函数自动分类为“情感倾向”和“讨论主题”的结构化结果,标注公式与输出对应关系)

    在这里插入图片描述

    (说明:展示英文文本批量翻译为日语的表格效果,呈现单文本与批量翻译的公式调用方式及结果)

    在这里插入图片描述

    (说明:展示产品评论通过情感分析函数输出“Positive/Negative/Neutral”标签的效果,标注关键评论与情感结果的对应关系)

    五、结语

    GcExcel V9.0 的 AI 功能,彻底打破了传统表格工具的功能边界,让服务器端电子表格引擎不仅能处理数值计算,更能深度理解和分析文本数据。无论是客户反馈处理、跨境业务协同,还是市场调研分析,开发者都能通过简单的公式调用,快速实现智能化数据处理,大幅降低开发成本、提升业务效率。

    扩展链接

    针对 Excel 的 Java API 组件

    HodlAI: Web3 × AI 的创新融合


    一、问题:AI API 的付费模式太"Web2"了

    用过 OpenAI/Claude/Gemini 等 API 的人都知道:

    • 先充值,后使用
    • 用多少扣多少
    • 花完再充,无限循环

    这本质上是 SaaS 订阅模式——你永远在为使用权付费,而不是拥有什么。

    但 Web3 的核心理念是什么?持有即权益。

    有没有可能,把这个理念用到 AI 服务上?


    二、HodlAI 的解法:代币 = 永久会员卡

    HodlAI 提出了一个简单但巧妙的模型:

    对比项 传统模式 HodlAI 模式
    投入 充 $100 买 $100 代币
    使用 用完归零 每天有额度
    资金归属 资金锁在平台 代币在自己钱包
    性质 纯消费 消费 + 投资
    续费 用完再充 每天自动刷新

    核心公式

    每 5 万代币 = 每日 $1 API 额度

    持有 50 万代币,每天就有 $10 免费额度,可以调用 GPT-5 、Claude 4.5 、Gemini 3 等 200+ 模型


    三、钱从哪来?交易税驱动的永续资金池

    这是最关键的问题。

    HodlAI 的答案:3% 交易税,100% 进入 API 资金池。

    代币每笔买卖 → 3% 税收 → API 资金池 → 按持有量分配
         ↑                                        ↓
         └──────── 交易越活跃,池子越大 ←─────────┘
    

    正向飞轮效应

    1. 更多人持币
    2. → 更多交易
    3. → 更大资金池
    4. → 更多 API 额度
    5. → 更多人想持币
    6. → 回到 1


    四、防作弊:Diamond Hands 钻石手机制

    如果没有限制,套利党会这么玩:

    买入 → 用光免费额度 → 立刻卖出 → 下次再来

    HodlAI 用**"钻石手机制"**解决这个问题:

    持有时间 额度释放
    0-5 分钟 0%(冷启动)
    5 分钟后 10% 额度释放
    每小时 +4% 递增
    24 小时不卖 100% 满额度(钻石手)
    曾经卖过 永久最高 80%(纸手惩罚)

    ⚠️ 持有时间通过链上数据验证,无法作弊


    五、透明度:Stripe 账单公开可查

    很多项目说"税收用于开发",但谁也不知道钱去哪了。

    HodlAI 做到了真正的透明:

    • ✅ 每一笔 API 充值都公开
    • ✅ 提供 Stripe 官方账单链接
    • ✅ 任何人可以点击验证
    • ✅ 团队 0 抽成

    这不是"相信我们",而是"你自己来查"。


    六、风险提示

    说完优点,也要说风险:

    • ⚠️ 代币价格波动:可能涨,也可能跌
    • ⚠️ 项目早期:模式新颖但未经长期验证
    • ⚠️ 依赖交易量:如果没人交易,资金池增长会停滞


    七、项目特点

    这个项目的创新点在于:

    用 Web3 的代币经济模型,解决 Web2 的订阅付费痛点。

    它回答了一个问题:Meme 币除了炒作,能不能有实际用途?

    HodlAI 的答案是:可以,把代币变成"AI 服务的永久会员卡"。

    这个模式能不能跑通,需要时间验证。

    但至少,这是目前有的最有想象力的 Web3 × AI 结合尝试


    八、项目愿景

    我们相信,AI 服务不应该是永无止境的订阅付费,而应该是持有即权益的价值共享。

    HodlAI 是全球首个将 Web3 代币经济与 AI API 服务深度融合的创新平台。


    相关链接

    平台 链接
    🌐 官网 https://hodlai.fun/
    🐦 Twitter @hodlai_fun
    💬 Telegram https://t.me/hodlai_fun

    上个月中旬开始做自媒体,主要是科普方向,差不多也是 12 月 24 号左右爆火,抖+b 连着几期都是几百万播放,粉丝开始暴涨,目前 b 站 20w 粉丝、抖音 12w 、小红书 5w 。

    30 号入抖音伙伴计划,开始产生收益,目前一个月下来,接广+视频播放收益,大概 1.2w+,如果不接广告,纯视频收益的话,抖+b 站估计不到 1w 。

    总结下来,我这个粉丝量级的,有稳定的视频产出( 3 天一更),那么一个月至少还是有个 1-2w 左右,b 站也接了三次广告(吹风机、得物、转转),b 站现在不接广告,收益是非常低的。抖音的伙伴计划收益还算 ok ,但不好接广,可能我目前没找到渠道。小红书粉丝多,但也不好接广。

    再接再厉吧,我也没想到我在年底随便一做自媒体,只是想着做点自己感兴趣的,结果就爆火了,之前学习的各种技能都算是用上了,没有浪费,也算是吃上了互联网这口饭吧。