RNN 简介

RNN（Recurrent Neural Network，循环神经网络）一般以序列数据为输入，通过网络内部的结构设计有效捕捉序列之间的关系特征，一般也以序列形式输出。

RNN 的循环机制使模型隐层上一时间步产生的结果，能够作为当下时间步输入的一部分（当下时间步的输入除了正常的输入外还包括上一步的隐层输出）对当下时间步的输出产生影响。

• 结构：三层（输入层、隐藏层、输出层；循环发生在隐藏层）
  

1.1 RNN 模型的作用

因为 RNN 结构能够很好利用序列之间的关系，因此针对自然界具有连续性的输入序列，如人类的语言、语音等进行很好处理，广泛应用于 NLP（自然语言处理）领域的各项任务，如文本分类、情感分析、意图识别、机器翻译等。

语言处理示例

2.1 PyTorch 中传统 RNN 的使用

位置：在 torch.nn 中，通过 torch.nn.RNN 可调用。

import torch
import torch.nn as nn

rnn = nn.RNN(5, 6, 2)  # 实例化 rnn 对象
# 参数1：输入张量 x 的维度 - input_size
# 参数2：隐藏层的维度（隐藏层神经元个数）- hidden_size
# 参数3：隐藏层的层数 - num_layers

# torch.randn - 随机产生正态分布的随机数
input1 = torch.randn(1, 3, 5)  # 设定输入张量 x - 序列长 1，批次 3，维度 5
# 参数1：输入序列长度 - sequence_length
# 参数2：批次的样本 - batch_size（表示：3 个样本）
# 参数3：输入张量 x 的维度 - input_size

h0 = torch.randn(2, 3, 6)  # 设定初始化的 h0
# 第一个参数：num_layers * num_directions（层数 * 网络方向数（1 或 2））
# 第二个参数：batch_size（批次的样本数）
# 第三个参数：hidden_size（隐藏层的维度）

output, hn = rnn(input1, h0)
# 最后输出和最后一层的隐藏层输出

print(output)
print(output.shape)
print(hn)
print(hn.shape)

1.2 RNN的局限：长期依赖（Long-TermDependencies）问题

RNN的关键点之一就是他们可以用来连接先前的信息到当前的任务上，例如使用过去的视频段来推测对当前段的理解。如果RNN可以做到这个，他们就变得非常有用。但是真的可以么？答案是，还有很多依赖因素。

有时候，我们仅仅需要知道先前的信息来执行当前的任务。例如，我们有一个语言模型用来基于先前的词来预测下一个词。如果我们试着预测这句话中“the clouds are in the sky”最后的这个词“sky”，我们并不再需要其他的信息，因为很显然下一个词应该是sky。在这样的场景中，相关的信息和预测的词位置之间的间隔是非常小的，RNN可以学会使用先前的信息。

1.2 传统 RNN 优缺点

• 优势：内部结构简单，对计算资源要求低；相较 LSTM/GRU 参数总量更少；在短序列任务上性能与效果表现优异。
• 缺点：在长序列关联上表现较差；反向传播时易发生梯度消失或爆炸。

NaN 值（Not a Number，非数）：是计算机科学中数值数据类型的一类值，表示未定义或不可表示的值。

2.1 LSTM 模型简介

Long ShortTerm 网络——一般就叫做LSTM——是一种RNN特殊的类型，可以学习长期依赖信息。当然，LSTM和基线RNN并没有特别大的结构不同，但是它们用了不同的函数来计算隐状态。

LSTM的“记忆”我们叫做细胞/cells，你可以直接把它们想做黑盒，这个黑盒的输入为前状态和当前输入。这些“细胞”会决定哪些之前的信息和状态需要保留/记住，而哪些要被抹去。实际的应用中发现，这种方式可以有效地保存很长时间之前的关联信息。

2.2 PyTorch 中 LSTM 的使用

import torch
import torch.nn as nn

lstm = nn.LSTM(5, 6, 2)  # 实例化 lstm 对象
# 参数1：输入张量 x 的维度 - input_size
# 参数2：隐藏层的维度（隐藏层神经元个数）- hidden_size
# 参数3：隐藏层的层数 - num_layers

input1 = torch.randn(1, 3, 5)  # 设定输入张量 x - 序列长 1，批次 3，维度 5
# 参数1：输入序列长度 - sequence_length
# 参数2：批次的样本 - batch_size
# 参数3：输入张量 x 的维度 - input_size

h0 = torch.randn(2, 3, 6)  # 设定初始化的 h0（隐藏层）
c0 = torch.randn(2, 3, 6)  # 设定初始化的 c0（细胞状态）
# 第一个参数：num_layers * num_directions（层数 * 网络方向数（1 或 2））
# 第二个参数：batch_size（批次的样本数）
# 第三个参数：hidden_size（隐藏层的维度）

output, (hn, cn) = lstm(input1, (h0, c0))
# 最后输出和最后一层的隐藏层输出

print(output)
print(output.shape)
print(hn)
print(hn.shape)
print(cn)
print(cn.shape)

全文链接：https://tecdat.cn/?p=44893
原文出处：拓端数据部落公众号
关于分析师

在此对Chang He对本文所作的贡献表示诚挚感谢，他在中国中医科学院完成了中医信息学专业的硕士学位，专注中医临床数据挖掘领域。擅长Python、深度学习、临床数据采集与挖掘。Chang He曾参与多项中医临床数据研究项目，聚焦慢性胃炎等常见消化类疾病的中药配伍规律挖掘，通过数据技术赋能传统中医用药研究，积累了丰富的临床数据处理与模型构建经验。

专题名称：慢性胃炎中药用药规律数据挖掘与AI预测实践

引言

中医治疗慢性胃炎注重辨证施治与中药配伍，传统用药经验多依赖医师传承，难以快速提炼普适性规律并实现精准指导。随着大数据与人工智能技术的发展，通过数据挖掘解析病历中的中药配伍逻辑，结合神经网络构建用药预测模型，成为赋能中医临床诊疗的重要方向。本文围绕慢性胃炎住院病历数据，整合多种数据分析方法与AI模型，系统探索中药使用规律与用药预测路径，为临床合理用药提供数据支撑。
本文内容改编自过往客户咨询项目的技术沉淀并且已通过实际业务校验，该项目完整代码与数据已分享至交流社群。阅读原文进群，可与800+行业人士交流成长；还提供人工答疑，拆解核心原理、代码逻辑与业务适配思路，帮大家既懂 怎么做，也懂 为什么这么做；遇代码运行问题，更能享24小时调试支持。
本研究以两家医疗机构的慢性胃炎住院病历为核心数据，采用人工、VBA宏与大语言模型结合的方式提取并规范数据，通过SPSS系列工具与Python库实现频数分析、聚类分析、关联规则挖掘，同时构建含Resblock模块的神经网络模型，实现基于临床症状的中药预测。全文将先梳理数据处理与分析流程，再逐一呈现各环节结果，最后总结方法适用性与实际应用价值，同步配套核心代码供落地复用，兼顾理论性与实操性。

项目文件目录

研究方法与技术准备

数据来源与处理

本研究选取两家医疗机构的慢性胃炎住院病历作为研究对象，其中一家机构数据时间范围为2016年1月至2024年5月，聚焦中药配伍规律挖掘；另一家机构数据时间范围为2013年1月至2021年10月，用于神经网络模型构建，数据集含2214个样本、364种临床特征及469种中药。
数据提取采用人工、VBA宏与大语言模型协同模式，既保障人工校验的准确性，又通过工具提升效率。数据规范化依据《中药学》新世纪版标准，统一中药名称、剂量等关键信息，为后续分析奠定基础。

核心工具与方法说明

1. 分析工具：SPSS Modeler 18.0、SPSS Statistic 26.0、Python 3.11.5（Sklearn、Scipy、Pytorch 2.0.1模块），上述工具国内均可正常访问使用，无替代需求，其中Python相关模块可通过镜像源快速安装。
2. 分析方法：频数分布分析（提炼高频中药与临床特征）、聚类分析（K-means、AGNES，对比不同距离与连接法适用性）、关联规则挖掘（挖掘中药联用规律）、BP神经网络（含Resblock模块，优化症状到中药的预测精度）。

核心代码适配与说明（数据提取环节）

以下代码用于中药名称提取与数据清洗，优化变量名与语法结构，适配中文文本处理需求，省略部分重复数据校验代码：

import pandas as pdimport re# 读取Excel格式的病历数据文件input_excel = '病历数据.xlsx' # 替换为实际数据文件路径data_df = pd.read_excel(input_excel)# 定义汉字提取函数，过滤非中文内容（保留中药名称）def get_chinese_content(text): # 正则表达式匹配中文汉字范围 chinese_characters = ''.join(re.findall(r'[\u4e00-\u9fff]+', str(text))) return chinese_characters# 对中药名称列应用提取函数，清洗数据data_df['中药名称'] = data_df['中药名称'].astype(str).apply(get_chinese_content)# 保存清洗后的数据至新文件output_excel = '清洗后病历数据.xlsx'data_df.to_excel(output_excel, index=False, engine='openpyxl')print(f"数据清洗完成，结果已保存至 {output_excel}")

代码功能：针对病历数据中的中药名称列进行清洗，提取纯中文内容，剔除符号、数字等干扰项，保障后续分析数据的规范性。省略部分为数据去重、空值填充逻辑，可根据实际数据质量补充。

研究结果与分析

频数分析结果

本次分析共涉及281种中药、7375个用药实例，平均每张处方开具15种中药。其中甘草使用频次最高，达341次，占比71.49%，平均剂量7.8g；黄精、升麻等51种中药仅使用1次，频次最低。
频次排名前20的中药如下表所示，高频中药多集中在理气、健脾、清热类别，符合慢性胃炎脾胃失调、气滞热蕴的常见病机。
表4 药物频次统计前20位

中药频次分布如下图所示，呈现明显的长尾分布特征，少数中药在临床中广泛应用，多数中药针对性使用。

相关文章

Python预测二型糖尿病：逻辑回归、XGBoost、CNN、随机森林及BP神经网络融合加权线性回归细化变量及PCA降维创新

原文链接：https://tecdat.cn/?p=43572

聚类分析结果

聚类分析核心目标是挖掘中药联用的内在规律，对比K-means与AGNES两种聚类方法，结合不同距离计算方式与连接法，从轮廓系数、临床可解释性等维度评估适用性。

K-means聚类

簇数设置为1-20时，通过WSS图（组内平方和）观察簇数适配性，拐点虽不明显，但簇数为2、3、5、9时WSS下降趋势变缓，簇数适中。

表5 不同簇数的K-means聚类平均轮廓系数

当簇数设为9时，各簇样本轮廓系数表现较好，通过PCA降维可视化聚类结果如下：

K-means聚类结果临床可解释性较强，平均评分4.67分，仅簇2可解释性较低（2分）。各簇对应不同病机的用药方案，如簇0含延胡索、砂仁等，与香砂六君子汤核心组分契合，适配脾气虚兼气滞证；簇1含黄芩、干姜等，对应气血阳虚、湿热蕴结的复杂病机。
表6 K-means聚类结果

AGNES聚类（不同连接法对比）

1. 欧氏距离+最长距离法：簇数设为9时，平均轮廓系数0.0803，临床可解释性评分4.11分，部分簇中药组合对应明确诊疗需求，如簇0含香附、紫苏梗等，侧重理气活血。
2. 欧氏距离+最短距离法：簇数设为12时，平均轮廓系数0.0637，但临床可解释性仅1.33分，多数簇仅含单味药，难以提炼联用规律。
3. 欧氏距离+组间平均连接法：簇数设为12时，平均轮廓系数0.0901，临床可解释性3分，兼顾聚类效果与规律提取，如簇1（枳实、厚朴）、簇2（白芍、柴胡）均为临床常用配伍。

聚类分析核心代码（AGNES方法）

以下代码优化变量名与注释，适配聚类分析需求，省略部分图表美化与结果导出代码，同时提供24小时应急修复服务，代码运行异常可快速响应，效率较自行调试提升40%：

import numpy as npimport matplotlib.pyplot as pltfrom sklearn.cluster import AgglomerativeClusteringfrom scipy.cluster.hierarchy import dendrogram, linkagefrom sklearn.metrics import silhouette_scoreimport pandas as pd# 读取预处理后的中药数据data_path = '中药数据.xlsx'df = pd.read_excel(data_path, usecols="A:RJ", nrows=41)labels = df.iloc[:, 0].values # 提取样本标签（中药名称）data = df.iloc[:, 1:].to_numpy() # 提取特征数据cluster_num = 12 # 设定簇数try: print(f"开始聚类分析，簇数设置为 {cluster_num}") # 初始化AGNES聚类器，欧氏距离+组间平均连接法 agnes_cluster = AgglomerativeClustering(n_clusters=cluster_num, affinity='euclidean', linkage='average') cluster_results = agnes_cluster.fit_predict(data)# 计算平均轮廓系数，评估聚类效果 avg_silhouette = silhouette_score(data, cluster_results, metric='euclidean') print(f"簇数{cluster_num}时，平均轮廓系数：{avg_silhouette}")# 绘制树状图 linked_matrix = linkage(data, method='average', metric='euclidean') plt.figure(figsize=(12, 6)) dendrogram(linked_matrix, orientation='top', labels=labels, show_leaf_counts=True) plt.title('层次聚类树状图') plt.xlabel('样本标签') plt.ylabel('距离阈值') plt.show() ... # 省略轮廓系数分布图绘制与结果保存代码except Exception as e: print(f"聚类分析过程中出现异常：{e}")

关联规则挖掘结果

设置最小前项支持度0.1、最小置信度0.8，共得到451条关联规则，最高项数6项，其中项数4的规则最多（210条），项数2的规则最少（10条）。规则支持度与置信度前10名的关联规则临床可解释性均为满分，契合中医用药理论。
支持度前5的关联规则中，“党参→甘草”支持度最高（29.560%），二者为临床健脾益气常用配伍；“茯苓、陈皮→半夏”支持度25.367%，对应痰湿内阻型慢性胃炎的用药方案。
置信度前5的关联规则中，“吴茱萸、陈皮→黄连”置信度达98.276%，吴茱萸温肝暖胃，黄连清热燥湿，二者配伍符合寒热错杂证的诊疗逻辑；“延胡索、茯苓、半夏→陈皮”置信度98.077%，体现理气止痛、健脾化痰的联用思路。

神经网络构建与结果

模型设计

基于临床特征预测中药使用，构建含2个Resblock模块与1个全连接层的BP神经网络，Resblock模块通过跳跃连接缓解梯度消失问题，提升模型训练效果。模型输入为364种临床特征，输出为469种中药的预测概率，Resblock输出采用Leaky ReLU激活函数，最终输出采用Sigmoid激活函数，适配多标签分类需求。

特征与标签选择

临床特征频次前3位为烧心（63.69%）、口干（61.92%）、夜寐欠安（61.34%），均为慢性胃炎常见症状；中药标签选取覆盖高、中、低频药物，共12种，验证不同频次药物的预测效果。

模型结果与评估

采用二折交叉验证评估模型性能，F1值为43.54%，多数标签F1值波动幅度控制在0.017以内，模型稳定性较强。其中“黄芩”“陈皮、柴胡”等标签F1值超过50%，预测效果较好；“佩兰、黄芩”标签预测稳定性较差，可能与该组合临床应用场景差异较大有关。
高频药物黄芩预测F1值最高（53.42%），特征明确易被模型捕捉；白芍虽为高频药物，但召回率仅0.0799，呈现“高精低召”特征，提示其应用场景多样性导致模型难以全面识别；低频药物（占比<1%）因样本量极少，模型多预测为阴性，F1值无法计算，需通过数据扩充优化。

总结与应用建议

本研究通过多种数据分析方法与AI模型，系统挖掘了慢性胃炎中药用药规律，构建了症状到中药的预测模型，核心结论与建议如下：

1. 用药规律：甘草、陈皮、半夏等为慢性胃炎核心用药，多以理气、健脾、清热类中药联用为主，关联规则挖掘出的高频组合可作为临床用药参考。
2. 方法适配：K-means聚类在临床可解释性上优于AGNES，欧氏距离+组间平均连接法可作为AGNES聚类的优选参数，为同类研究提供方法借鉴。
3. 模型优化：Resblock优化的BP神经网络可实现中药预测，但需针对低频药物扩充样本，优化标签设计，提升模型泛化能力。
4. 临床应用：研究结果可辅助医师快速制定用药方案，尤其为年轻医师提供配伍参考，同时模型可作为中医用药教学的辅助工具。
   本研究所有代码与数据已同步至交流社群，提供人工答疑与24小时代码调试服务，助力临床数据挖掘爱好者快速落地实践。后续可结合更多医疗机构数据，优化模型参数，进一步提升结果的临床适配性。

如果你正在自己搭建交易或行情系统，大概率遇到过类似的情况：
你能拿到行情，但总觉得延迟不可控；
接口能用，但一旦标的数量上来，系统开始变得不稳定。
当你从“看行情”转向“用行情”，数据接入方式本身就会成为系统瓶颈。

从使用场景看实时行情的真实需求

在个人专业交易或高频策略场景中，你对行情数据的要求通常包括：

• 数据能够持续推送，而不是频繁请求
• 支持多标的同时订阅
• 延迟与推送频率可预期

• 数据结构清晰，可直接进入策略或缓存层
  这类需求，本质上已经超出了传统 HTTP 轮询的适用范围。

  实时行情的常见工程痛点

  很多系统在早期阶段看起来“能跑”，但随着负载上升，问题会逐渐显现：

• 高频轮询带来不必要的连接与资源消耗
• 多标的管理复杂，订阅逻辑难以维护
• 数据字段不统一，解析成本增加

• 延迟不稳定，影响策略执行一致性
  这些问题并不来自策略，而是行情接入模型本身不合理。

  用数据流的方式理解实时行情

  在工程上，更合理的思路是把实时行情视为一条持续的数据流。
  WebSocket 的核心优势在于：

• 连接建立一次，长期保持
• 服务端主动推送数据

• 天然适合多标的订阅与高频更新
  在这种模型下，行情 API 更像是数据源，而你的系统只是负责接收、分发和消费数据。

  选择实时行情 API 时应关注什么

  在真正接入之前，你可以从以下几个关键点快速判断一个 API 是否适合生产系统：

• WebSocket 连接方式与鉴权是否清晰
• 订阅指令是否支持批量标的
• 推送频率与数据粒度是否明确

• 返回数据结构是否稳定、规范
  这些因素决定了接口能否在系统中长期、稳定运行，而不仅仅是“能连上”。

  Python 接入示例

  下面给你一份 Python 示例，它展示了典型的 WebSocket 接入流程：

import websocket
import json

def on_message(ws, message):
    data = json.loads(message)
    # 实时行情高频，先打印结构
    print(data)

def on_open(ws):
    subscribe_msg = {
        "cmd": "subscribe",
        "args": ["US.AAPL"]
    }
    ws.send(json.dumps(subscribe_msg))

def on_error(ws, error):
    print("error:", error)

def on_close(ws):
    print("connection closed")

ws = websocket.WebSocketApp(
    "wss://stream.alltick.co/ws",
    on_open=on_open,
    on_message=on_message,
    on_error=on_error,
    on_close=on_close
)

ws.run_forever()

数据结构比价格本身更重要

当你把实时行情真正接入系统后，会发现一个有趣的现象：
最先带来安全感的，往往不是价格变化，而是数据结构的整洁程度。
常见的实时行情字段通常包括：

• 标的标识（symbol）
• 毫秒级时间戳
• 最新成交价与成交量

• 买卖报价（bid / ask）
  结构清晰的数据可以直接进入策略模块、内存缓存，或作为统一行情源提供给下游服务，几乎不需要额外加工。
  AllTick的美股实时行情 API 在接口设计上就偏向这种工程友好型结构，无论是多标的订阅还是持续推送，都更容易融入现有系统。

  实时行情在系统中的典型流向

  在一个相对完整的交易系统中，实时行情数据通常会被：

• 推送给策略引擎进行实时计算
• 写入缓存，用于低延迟查询

• 转发给其他服务，作为统一行情入口
  当接入方式合理时，行情数据会在系统中自然流动，而不是成为需要频繁“救火”的模块。

  总结

  如果你正在设计或重构行情接入层，建议优先从系统视角思考：

• 数据是否以“流”的方式进入系统
• 接口是否足够稳定，能长期运行
• 数据结构是否能直接服务于策略与缓存
  当这些问题被解决后，技术实现反而会变得简单。
  行情每天都在变化，但一个设计合理的实时行情接口，往往能让整个系统保持长期稳定。这也是 WebSocket 美股实时 API 在交易系统中被广泛采用的原因。
  

在生成式人工智能向 AI 智能体（AI Agent） 演进的过程中，技术社区往往将目标放在更高的自主性、更强的推理能力上。

但当智能体真正进入 电力、制造、金融、能源、医药等传统行业 时，一个反直觉却极其现实的结论浮现出来：

传统企业并不优先追求“最聪明的智能体”，而是“最可控的智能体”。

这并非技术保守，而是由 物理风险、合规压力与业务确定性 共同决定的理性选择。

一、核心定义：什么是传统行业语境下的“智能体可控性”？

在工业与严肃商业环境中，智能体的可控性（Controllability） 并不等同于“能不能关掉它”，而是一个系统级概念：

可控性 = 行为可预测 + 决策可解释 + 异常可接管

具体可拆解为三个维度：

1️⃣ 边界可控（Boundary Control）

• 智能体能做什么 / 不能做什么是明确的
• 工具权限、数据访问范围、操作级别均被限制

2️⃣ 逻辑可控（Logic Transparency）

• 决策过程可以被复现与审计
• 不只是“给结果”，而是能说明依据了什么规则 / 文档 / 条款

3️⃣ 安全可控（Fail-safe Control）

• 在异常输入、极端场景下
• 系统可自动降级，或由人工即时接管（Human Override）

二、为什么“可控性”是传统行业的生命线？

1️⃣ 容错成本具有极端非对称性

在互联网产品中，智能体犯错的代价通常接近于零；
而在传统行业中，一次错误可能意味着：

• 设备损坏
• 生产事故
• 合规违规
• 财务或人身风险

因此现实选择是：

智能体更适合作为“决策辅助者”，而非“最终执行者”。

这也是为什么多数传统企业会保留人类终审权。

2️⃣ 合规与审计要求无法妥协

金融、医药、能源等行业的共同特点是：

• 每一个决策必须可追溯
• 每一个结论必须有明确依据

但大模型天然存在随机性与幻觉风险（Hallucination）。

因此：

如果智能体无法解释“为什么这么做”，
那它在合规体系中就是不可用的。

3️⃣ 传统业务偏好“确定性而非创造性”

传统企业的竞争力，往往来源于：

• 数十年沉淀的 SOP
• 高度结构化的业务流程

他们真正需要的不是“灵光一现”，而是：

**90% 场景下像老员工一样稳定，
10% 场景下才体现智能。**

在实践中，一些团队会选择成熟的智能体平台，通过低代码工作流 + 强规则约束的方式，让智能体“聪明但不越界”，显著降低落地风险。

三、实践范式：如何构建“可控的智能体系统”？

当前行业的共识路径是构建一种：

“受限自主系统（Constrained Autonomy）”

核心做法包括：

✅ 1. RAG（检索增强生成）

• 将企业私有知识库作为唯一可信信息源
• 限制智能体输出范围，降低幻觉概率

✅ 2. 工作流编排（Workflow Orchestration）

• 用 DAG 工作流 拆解任务
• 每一步都有明确输入、输出与校验规则

✅ 3. 人在回路（Human-in-the-Loop）

• 在关键节点设置人工审核断点
• 涉及资金、合规、客户沟通时必须人工确认

四、核心结论：可控性不是限制，而是入场券

对传统行业而言：

• 没有可控性，就没有规模化
• 没有审计能力，就没有商业落地

可控性决定了：
智能体是“实验玩具”，还是“生产工具”。

本质上，这是一种新的人机契约关系：

• 人类定义规则与边界
• 智能体承诺在规则内高效执行

未来传统企业的真正竞争力，不在于谁的模型参数更大，而在于谁先构建出一套“可控、可审计、可接管”的智能体体系。
（本文章由AI辅助生成）

您的 iPad 或 iPhone 内部存储空间不足，无法存储照片？或者想备份照片？您可以将照片从 iPad 或 iPhone 传输到电脑。根据您的偏好和可用的工具，共有 5 种方法可以实现此操作。无论您喜欢基于云的解决方案、专用软件，还是简单的拖放操作，您都能找到适合您需求的方法。

快速看一下这些方法的优缺点：

第 1 部分：如何通过 iCloud 照片将照片从 iPad/iPhone 传输到计算机？

iCloud Photos 是 Apple 的云端照片同步服务，让您可以轻松地在所有设备（包括电脑）上访问您的照片。请先确保您的 iCloud 帐户有足够的云存储空间。

要通过 iCloud Photos 将图片从 iPad 移动到 PC：

在您的 iPad 上，请前往“设置”>“ [您的姓名] ”>“ iCloud ”>“照片”。开启“同步此 iPad ”功能（如果尚未启用）。这会将您的 iPad 照片上传到 iCloud。请确保您的 iPad 已连接到 Wi-Fi。

在 Windows PC 上，从 Apple 网站或 Microsoft Store 下载并安装适用于 Windows 的 iCloud。或者，访问 iCloud Photos 网站并登录您的 Apple 帐户。


单击“照片”选项，将您想要的照片下载到您的电脑。

注意：在 Mac 电脑上，iCloud 照片已内置于 macOS 中。请确保您在 Mac 和 iPad 上使用相同的 Apple ID 登录。只需在 Mac 上打开“照片”应用。前往“照片”>“设置”（或“偏好设置”）>“iCloud”。确保已勾选“iCloud 照片”。您的 iPad 照片将同步到 Mac 的照片图库。然后，您可以根据需要将它们拖放到其他文件夹。

第 2 部分：如何通过 iReaShare iPhone Manager 将照片从 iPad/iPhone 传输到 PC？

作为一款一体化 iOS 管理工具， iReaShare iPhone Manager提供了实用的功能来传输数据，包括照片、视频、音乐、联系人、短信等。如果您想将照片从 iPad 或 iPhone 无缝导出到 Windows 或 Mac 电脑，它将满足您的要求。

iReaShare iPhone Manager的主要功能：

• 将图片从 iPad 以无损质量传输到计算机。
• 不会改变您的图像格式。

*将各种文件从 iOS 设备传输到计算机。

• 立即将您的 iOS 数据备份到您的计算机。
• 将备份数据从您的计算机恢复到您的 iPad 或 iPhone。
• 支持 iOS 5.0 及更高版本，包括 iOS 26。

以下是通过该软件将图片从iPad导出到PC的方法：

在电脑上下载并安装 iReaShare iPhone Manager，然后使用 USB 数据线将 iPad 连接到电脑。启动软件。它应该会检测到你的 iPad。


如果出现提示，请点击“信任此电脑”，在 iPad 上授予访问权限。然后即可建立连接。


点击界面上的“照片”部分。接下来，选择要传输的照片，然后点击“导出”图标。然后在电脑上选择一个目标文件夹来保存照片。软件将开始传输过程。

第 3 部分：如何通过照片应用程序将照片从 iPad 或 iPhone 传输到计算机？

macOS 和 Windows 操作系统上的“照片”应用是管理设备上照片的主要工具，包括从 iPad 直接传输照片。对于 Windows 用户，只要您的电脑运行的是 Windows 10 或更高版本，您就可以使用“照片”应用从 iOS 设备导入照片。

将 iPad 照片导入 PC：

请将 iPad 通过 USB 连接到电脑。然后点击“搜索”，并输入“照片”即可启动照片应用。


点击右上角的“导入”，点击“从USB设备”。


选择你的 iPad，然后选择要传输的图片。选择后，点击“添加 X 个项目”，选择电脑上的文件夹，然后点击“导入”。

将 iPad 照片导入 Mac：

使用 USB 数据线将 iPad 连接到 Mac。在 Mac 上打开“照片”应用。如果它没有自动打开，请在“应用程序”文件夹或 Dock.p 中找到它。


你的 iPad 应该会出现在照片应用侧栏的“设备”部分下。点击它。如果这是你第一次连接，iPad 可能会询问你是否信任这台电脑。点击“信任”并输入你的密码。


照片应用会显示 iPad 上的所有照片和视频。您可以选择“导入所有新照片”，或选择特定照片，然后点击“导入所选”。导入后，这些照片将出现在 Mac 的照片图库中。

提示：您可以轻松地将联系人从iPhone或iPad同步到Mac电脑。如果您需要有用的解决方案，请查看。

第 4 部分：如何通过 Google Photos 将图片从 iPad 或 iPhone 导出到 PC？

Google Photos 是一款流行的跨平台云服务，它提供了一种极好的方式，可以将照片从 iPad 或 iPhone 备份并传输到您的计算机，无论使用哪种操作系统。

将照片从ipad下载到电脑：

从 App Store 下载 Google 相册应用并将其安装在 iPad 上。打开 Google 相册应用，然后使用你的 Google 帐户登录。


点击右上角的个人资料图标。前往“照片设置”>“备份和同步”。开启“备份和同步”功能。您的 iOS 照片将开始上传到 Google 相册（请确保您的 Wi-Fi 连接良好）。

在你的电脑（Windows PC 或 Mac）上，打开网络浏览器并访问 photos.google.com。然后使用你在 iPad 上使用的 Google 帐户登录。


您 iPad 上所有备份的照片都会显示在这里。选择您想要的照片，点击右上角的三个点菜单图标，然后选择“下载”。照片将被下载到您电脑的下载文件夹中。

第 5 部分：如何通过文件资源管理器将图像从 iPad/iPhone 传输到计算机？

对于 Windows PC 用户，您的 iOS 设备可以被识别为数码相机，从而可以使用文件资源管理器进行简单的拖放传输。如果您的 PC 运行的是 Windows 7/8 系统，且没有“照片”应用，您可以使用这种方式将照片从 iPad 复制到 PC。

具体操作如下：

使用 USB 数据线将 iPad 连接到 Windows PC，然后在 iPad 上单击“信任”。


在电脑上打开“文件资源管理器”（可以按 Windows + E）。在左侧边栏中，您应该会在“便携式设备”或“设备和驱动器”下看到您的 iPad。它可能会显示为“ Apple iPad ”或类似的名称。


双击 iPad/iPhone 将其打开，然后导航至“内部存储”>“ DCIM ”。在 DCIM 文件夹中，您会找到一个或多个文件夹（例如，100APPLE、101APPLE），其中包含您的照片和视频。


打开这些文件夹查看图片。现在，您可以选择要传输的照片。将选定的照片拖放到电脑上的任何文件夹中，或者复制粘贴到您想要的位置。

第 6 部分：有关将照片从 iPad/iPhone 传输到计算机的常见问题

问题 1：将照片从 iPad 或 iPhone 传输到电脑的最简单方法是什么？

本指南中的方法都很简单易用。哪种方法最简单取决于您的需求。如果您想无线传输照片，可以使用 iCloud Photos 和 Google Photos。如果您想要稳定且批量的传输，那么使用 iReaShare iPhone Manager 将是最佳选择。

问题 2：我可以使用 iTunes 将照片从 iPad/iPhone 传输到 PC 吗？

不可以，通常情况下，您无法使用 iTunes 将照片从 iPad 传输到 PC。iTunes 主要用于将 PC 上的媒体（音乐、视频等）同步到 iPad 以及备份 iPad。它实际上并没有直接的“将照片从 iOS 设备传输到 PC”功能。

Q3：我可以使用 AirDrop 在 iPad 和电脑之间传输照片吗？

是的，你完全可以使用 AirDrop 在 iPad 和 Mac 电脑之间传输照片（以及其他文件）。但如果你的电脑是 Windows 系统，则无法使用 AirDrop 传输图片。

结论

无论选择哪种方法，都可以轻松地将照片从 iPad 或 iPhone 传输到电脑。使用iReaShare iPhone Manager可以高效、高质量地传输照片，并轻松管理您的 iPad 数据。无论如何，请考虑您个人对云存储和直接连接存储的偏好，并选择最适合您工作流程的方法。
​

通义深度搜索限时免费中，快来使用吧!

 应用开通

1.在阿里云百炼控制台的应用广场中点击通义深度搜索卡片，进入应用详情。

2.首次试用时，点击右上角免费开通完成应用开通。

应用管理

点击我的应用进入应用管理页面。页面展示所有已创建的应用和应用key等信息，首次使用需要新增应用。

应用配置

点击应用卡片或新增应用进入应用配置界面。

1.场景选择

根据实际需求选择使用场景，当前可选通用场景、法律场景。

2.互联网检索配置

开启后支持实时互联网全栈信息检索，提升模型回答准确性及时效性。

2.1检索策略

在检索策略上，您可以在‘标准版本’和‘自定义版本’中选择一种

标准版本

标准的检索策略，选择标准版本时，可以进一步根据对于搜索效果与搜索耗时的偏好选择不同的性能版本。

• Max版本：效果优先，检索更深入，结果更全面，但响应时间较长
• Turbo版本：速度优先，响应时间短，适合对实时性要求高的场景

自定义版本

选择自定义检索策略时，有更多的配置进行更细化的配置。

• 支持限定检索时间范围
• 支持限定网站范围，最多添加20个网站，配置后优先从此范围网站检索信息，如果无匹配信息则会扩展到全网检索，网站录入时会自动去重
• 支持配置recall数量，数量越高信息越全，但会占用更多资源，增加耗时
• 支持配置网页读取开关，开启后搜索结果更详细但是耗时增加

2.2策略选择

可根据搜索效果与rt偏好选择max版本和turbo版本。

3.自有知识库配置

支持接入非百炼的自有知识库作为搜索来源，开启选项后可进行配置，点击添加知识库配置

输入知识库名称、知识库描述、服务地址、授权信息，点击“服务测试”，验证通过后点击“保存”以完成添加。可参考示例文档进行知识库对接配置。

4.百炼知识库

支持接入百炼知识库，选择已配置的知识库，如无百炼知识库，需要先在百炼控制台创建知识库。并添加知识库描述，知识库描述需要认真填写易于模型理解。

5.code\_interpret

开启后提升对于复杂计算问题的效果。

6.动态文件解析

开启动态文件解析后，支持在输入query同时添加本地文件作为临时上下文知识。一次对话最多可上传10个文件，单文件不超过10MB，支持.docx/.doc/.pdf/.txt/.md等格式。

7.生成配置

开启输出报告后，对话最终会生成报告文件。关闭则不生成报告。

应用测试

配置完成后，可在输入框输入query进行测试，对话框展示chat内容、计划规划、思考过程、检索过程、工具调用过程等多个深度搜索研究步骤。最终生成报告文件。右侧报告区域支持‘预览’模式和‘源码’模式。切换到‘源码’模式可查看用于生成报告的Markdown原文。提供文件下载。

重要

请注意，在配置页面测试也会计算使用量并产生费用。

应用发布

配置测试完成后，可以点击发布，将应用发布后可正式使用。

点击访问：通义深度搜索应用

点击：更多讨论交流

上个帖子已经分享了如何在润云进入ComfyUI界面。

下面我来具体分享ComfyUI的使用方法

一、文生图

界面上的节点和整个画布都可以拖动，也可以放大缩小。

ComfyUI 为我们提供了一个默认的文生图工作流。直接点击右边的 Queue Prompt 就能够触发生图流程，你可以看到有个绿色的边框会随着流程的进展在不同的节点上显示。

整个工作流由两个基本的部分组成：节点（Nodes）和边（Edges）。

• 每一个矩形块就是一个节点，比如 Load Checkpoint CLIP Text Encoder 等。可以把每个节点看成是函数，它们都具有输入、输出和参数三个属性。

• 连接每个节点的输入和输出的线就是边。

其他还有很多的细节和概念，我将会在接下来的内容中逐步解释。

我们直接从这个默认工作流开始，它包含了下面这些步骤。

1.1 选择模型

首先需要在 Load Checkpoint 这个节点中选择一个模型，这里的模型选项就是在上文中下载的那些模型文件。比如我这里就放置了多个可选的模型，我可以根据自己的需求选择我想要使用的模型。

1.2 构造提示词

选择完模型，下一步就是构造提示语了。

在界面上，有两个 CLIP Text Encode (Prompt) 节点，这两个节点都是用来构造我们的提示语的。

其中，上面一个节点用来输入正向提示语（Positive Prompt），即告诉模型做什么，而下面一个节点则用来输入负面提示语（Negative Prompt），即告诉模型不要做什么。

如果觉得容易混淆，可以像我这样直接双击节点名称改成它对应的功能的名称，就像下面这样。

下面的节点也可以看出哪个是正向哪个是负向

CLIP Text Encode 节点的作用是将提示语转换为标记，然后通过文本编码器将它们处理为嵌入（Embeddings）。

你可以使用 (关键词:权重) 的这样的语法来控制关键词的权重。

比如，使用 (keyword:1.4) 来增强效果，或 (keyword:0.9) 来减弱效果。

1.3 生成图像

点击下方的 Run，等待一会儿就能够看到有一张图像生成完成了。

二、ComfyUI 的工作机制

ComfyUI 的强大之处就在于它的高度可配置性。熟悉每个节点的功能之后可以让我们轻易地根据需求来定制化操作。

在介绍图生图工作流之前，我需要先向你详细介绍一下 ComfyUI 的工作机制。

Stable Diffusion 的生图过程可以总结为以下三个主要步骤：

• 文本编码：用户输入的提示语通过一个称为文本编码器（Text Encoder） 的组件编译成各个单词的特征向量。这一步将文本转换为模型可以理解和处理的格式；
• 潜在空间（Latent space）转换：来自文本编码器的特征向量与一个随机噪声图像一起被转换到潜在空间。在这个空间中，随机图像根据特征向量进行去噪处理，得到一个中间产物。这一步生图过程的是关键所在，因为模型会在这里学习将文本特征与视觉表现相联系。
• 图像解码：最后，潜在空间中的中间产物由图像解码器（Image Decoder） 进行解码，转换为我们可以看到的实际图像。

了解了 Stable Diffusion 层面的生图流程之后，接下来我们深入了解一下 ComfyUI 在实现这个过程中的关键组件和节点。

2.1 Load Checkpoint 节点

Load Checkpoint 节点会加载一个模型，一个 Stable Diffusion 模型主要包含以下三个部分：

• MODEL

MODEL 组件是一个在潜在空间（Latent Space）中运行的噪声预测模型。

这句话的意思是 Stable Diffusion 模型在潜在空间中对图像的生成过程进行建模，并通过预测和去除噪声逐渐还原图像的过程。

具体来说就是，在 Stable Diffusion 中，图像生成首先在潜在空间中引入随机噪声，然后模型通过一系列步骤逐渐去除这些噪声，生成符合提示语的图像。

这种逐步去噪的过程由噪声预测模型来完成。潜在空间是图像的一个简化、高度抽象化的表示，可以降低模型的计算复杂度，可以让模型在生成图像时更高效。

在 ComfyUI 中，Load Checkpoint 节点的 MODEL 输出连接到 KSampler 节点，KSampler 节点执行反向扩散过程。

KSampler 节点利用 MODEL 在潜在表示中进行迭代去噪，逐步优化图像，直到它符合给定的提示语。

• CLIP (Contrastive Language-Image Pre-training)

CLIP 其实是一个负责预处理用户提供的正向和负面提示语的语言模型。它将文本提示转换为 MODEL 可以理解的格式，指导图像生成过程。

在 ComfyUI 中，Load Checkpoint 节点的 CLIP 输出连接到 CLIP Text Encode 节点。CLIP Text Encode 节点获取用户提供的提示语，并将它们输入到 CLIP 语言模型中，转换为向量嵌入。

这些向量嵌入可以捕捉单词的语义，为 MODEL 生成符合提示语的图像提供更多的指导。

• VAE (Variational AutoEncoder)

它包含一个编码器和一个解码器，其中，编码器用于将图像压缩为低维的潜在表示，而解码器用于从潜在表示中重建图像。

在文生图的过程中，VAE 仅在最后一步使用，它的作用就是将生成的图像从潜在空间转换回像素空间。

ComfyUI 中的 VAE Decode 节点获取 KSampler 节点的输出，并利用 VAE 的解码器部分将潜在表示转换为最终的像素空间图像。

VAE 与 CLIP 语言模型是独立的组件。CLIP 主要处理文本提示语，而 VAE 负责在像素空间和潜在空间之间进行转换。

2.2 CLIP Text Encode 节点

在上文中有提到，在 CLIP Text Encode 节点中我们可以输入生成图像的提示语，而这个节点的作用就是获取我们提供的提示语，并将其输入到 CLIP 语言模型中。

CLIP 是一个强大的语言模型，能够理解单词的语义并将其与视觉概念相关联。当提示语输入到 CLIP Text Encode 节点后，它会将每个单词转换为向量嵌入。向量嵌入是高维的数字表示，包含了单词的语义信息，模型能够根据这些信息生成符合提示语的图像。

2.3 Empty Latent Image 节点

在 ComfyUI 的文生图的过程中，它首先会在潜在空间中生成一个随机图像，这个图像会作为模型处理的初始状态，它的大小与实际像素空间中的图像尺寸成比例。

在 ComfyUI 中，我们可以调整潜在图像的高度和宽度来控制生成图像的大小。此外，我们还可以设置批处理大小来确定每次运行生成的图像数量（batch_size）。

潜在图像的最佳尺寸取决于所使用的 Stable Diffusion 模型版本。

对于 v1.5 模型，推荐的尺寸是 512x512 或 768x768；对于 SDXL 模型，最佳尺寸是 1024x1024。ComfyUI 提供了多种常见的宽高比可供选择，但是需要注意的是，潜在图像的宽度和高度必须是 8 的倍数，这样才能确保与模型架构的兼容性。

2.4 VAE 节点

在界面中我们能看到 Load Checkpoint 节点的 VAE 属性就直接连接到了 VAE 节点。所以，这里的 VAE 节点其实就是上文中所提到的负责在像素空间和潜在空间之间转换图像的 VAE。

2.5 KSampler 节点

在 ComfyUI 中，生图过程的核心节点就是 KSampler 节点。它负责在潜在空间中对随机图像进行去噪，让生成的图像符合我们提供的提示语。KSampler 使用的是一种称为反向扩散的技术，可以迭代地去除噪声，并根据 CLIP 向量嵌入添加有意义的细节。

KSampler 节点提供了多个参数，让我们可以微调图像的生成过程：

• Seed

  Seed 值控制了初始噪声和最终图像的构图。设置特定的 Seed 值，我们可以获得可重复的结果，可以保持多次生成的一致性。

• Control_after_generate

  这个参数决定了每次生成后 Seed 值的变化方式，可以设置为随机化（每次运行生成新的随机 Seed）、递增、递减或者固定不变。

• Step

  采样步数决定了优化过程的强度。如果设置步数较大，则会产生更少的伪影和更精细的图像，但也会增加生成时间。

• Sampler_name

  这个参数用于选择 KSampler 所使用的特定采样算法。不同的采样算法可能会产生略有不同的结果，且生成速度也会有所不同。

• Scheduler

  这个参数用于控制在去噪过程中的每一步中噪声水平的变化速率，它决定了从潜在表示中去除噪声的速度。

• Denoise

  这个参数用于设置去噪过程应消除的初始噪声量。值为 1 表示去除所有噪声，从而生成干净且细节丰富的图像。

通过调整这些参数，我们可以微调图像的生成过程，从而获得理想的图像。

至此，我花了大量篇幅向你介绍了 ComfyUI 中的所有节点以及其对应的功能，希望到目前为止能够帮助你对 ComfyUI 有一个较为全面的认知和理解。

后续我会使用图生图、图片扩展等流程的教学。点点关注，之后会持续更新哦~~~

如意玲珑是⼀种新型的独⽴包管理⼯具集旨在解决Linux系统下传统软件包格式因复杂依赖关系导致的兼容性问题，以及权限管控松散带来的安全⻛险。通过容器化技术提供应⽤隔离运⾏环境，⽀持应⽤增量更新，从⽽提升软件包管理的效率和安全性。

本⽂主要讲述如意玲珑的发展与架构的演进 ，这包括以下⼏个⽅⾯：
Linux软件包管理器的演进；
如意玲珑架构设计
如意玲珑使⽤场景；
如意玲珑关键组件设计；
如意玲珑性能测试与对⽐；
如意玲珑的发展成果；
如意玲珑未来展望。

Linux软件包管理器的演进
Linux操作系统以其开源特性和灵活性著称，⽽软件包管理器是确保Linux系统能够顺利安装和运⾏所需软件的关键组件。
顾名思义，Linux 软件包管理器是⼀种在 Linux 操作系统上⽤于安装、更新和卸载软件包的⼯具。 它的历 史可以追溯到上世纪 90 年代，此时 Linux 正处于起步阶段，软件的安装必须⼿动下载源代码并编译，这对⾮技术⽤户来说是⼀项繁琐且困难的任务。
这种情况下，先后催⽣了 dpkg 和 rpm ，然⽽由于不能⾃动解决依赖关系，其使⽤起来依旧不便。
直到 Debian 的 apt、Red Hat 的 up2date 的发布，包管理器可⽤性有了很⼤的提升。它们采⽤了⼀种被称为 “依赖关系解决器” 的算法，能够⾃动解决软件包之间的依赖关系，从⽽简化软件的安装和升级过程。但这也在另⼀⽅⾯⼤⼤增加了系统复杂度，维护者们需要⾮常谨慎⼩⼼地处理，稍有不慎就会陷⼊“依赖地狱”，导致软件包系统发⽣故障。
此外，还有许多其他的软件包管理器，如 yum、portage 和 pacman 等。包管理器的多样性给⽤户带来了更多选择，但缺点也⼗分显著： 它们的软件包⽆法互通，这意味着⼀款软件要在其他发⾏版上使⽤ ，可能需要被重复打包。
随着Linux内核对容器的⽀持、Docker的诞⽣，Snap、Flatpak 等⼀批容器思想的包管理器也开始崭露头角。这类格式的软件包与系统环境⼏乎完全解耦，不再依赖系统上的库⽂件（AppImage 也是如此），应⽤分发开始逐步变得简单起来。但磁盘、 内存占⽤较⾼，启动时间被不断延⻓等问题也随之⽽来，⾄今仍未被解决。

如意玲珑架构设计 

如意玲珑的核⼼设计原则是兼容和安全 ，主要为了解决以下问题：

1. 解决Snap、Flatpak包管理器应⽤体积过度膨胀 ，Runtime乱⽤导致占⽤过度膨胀、应⽤打开速度过慢 的问题；
2. 解决应⽤安装时权限过⼤问题 ，严格规范应⽤权限；
3. 解决应⽤运⾏依赖问题。
   基于以上设计原则 ，整体架构如下图所⽰： 
   

如意玲珑整体采⽤分层设计 ，最底层是硬件平台 ，⽀持不同的CPU架构 ，上层是系统平台也就是各个 Linux发⾏版操作系统。

再上层是运⾏环境 ，这⼀层就是我们单独抽离出的runtime ， 当前是选取桌⾯应⽤最常⽤的库和依赖包，这样应⽤只需要依赖这个统⼀的稳定的runtime ，⽆需考虑下层的系统平台 ，⽽不在runtime⾥的独有的依赖可以直接打包在应⽤包⾥⾯ ，⽽且runtime也会持续演进 ，演进的原则是兼容性第⼀ ，即在不影响兼容 性的前提下会持续修复缺陷和修复安全漏洞 ，⽽因为新的功能属性的要求导致需要更新⼤版本⽆法保障 兼容性时 ，会新增runtime ，新旧runtime共存互不⼲扰 ，且我们采⽤⽂件共享的⽅式来减少多个runtime对磁盘资源的占⽤ 。
再上层就是玲珑的主要组件 ，包括虚拟化容器、命令⾏接⼝ 、包仓库、⽤户会话辅助服务等组件 ，提供 包管理相关的能⼒ ，⽀持软件包的下载、安装、更新、卸载、运⾏与托管等功能。⽽在最上层 ，还为软 件开发者提供了便捷的包构建⼯具和转换⼯具 ，以及提供了应⽤商店供软件开发者分发应⽤ ，供⽤户下载安装应⽤ 。

如意玲珑使⽤场景

解决兼容性冲突问题.  现在企业的应⽤与系统、应⽤与应⽤之间需要完成适配、测试确保⽆兼容性冲突 ，⼀旦应⽤升级或系统或系统升级都有可能导致系统或应⽤⽆法使⽤ ，需要重新适配、测试 ，耗时耗⼒ ，严重影响企业办公和业务运转。
如意玲珑应⽤使⽤隔离技术 ，将系统和应⽤完全解耦 ，客户可随意升级系统或应⽤ 。⼤幅提⾼了易 ⽤性 ，降低了企业维护成本。

解决恶意软件可能窃取数据问题

恶意软件可通过多种渠道窃取企业核⼼业务数据 ，若被不法分⼦加以利⽤ ，可能会导致企业数据安全⾯临巨⼤风险 ，甚⾄遭受巨额损失。
如意玲珑提供沙箱让应⽤运⾏在隔离的环境下 ，对设备和数据的访问需要得到授权 ，从⽽保护了企业数据安全和个⼈隐私。

解决应⽤⽣态适配碎⽚化问题

传统包管理器在Linux下打包流程复杂 ，开发者需要为不同发⾏版分别打包DEB/RPM等格式 ，甚⾄同⼀发 ⾏版的不同版本也需要单独打包。各包管理器之间的软件包互不兼容 ，导致Linux应⽤⽣态碎⽚化严重。
如意玲珑通过提供统⼀的打包格式和⼯具 ，简化了软件打包流程 ，开发者只需关注应⽤本⾝ ，⽆需考虑 底层系统的差异 ，从⽽降低了打包难度 ，提⾼了开发效率。
如意玲珑通过提供统⼀的应⽤商店 ，⽤户可以⽅便地浏览、搜索和安装应⽤ ，提升了⽤户体验 ，促进了应⽤⽣态的发展。

如意玲珑关键组件设计

ll-cli：如意玲珑命令⾏管理⼯具
提供⽤户与如意玲珑包管理器交互的命令⾏⼯具。负责解析⽤户命令、调⽤ D-Bus ⽅法、处理⽤户交互 请求以及与 OCI 运⾏时直接交互（如 run, exec, ps, kill等）。ll-cli⽀持丰富的⼦命令和选项 ，例如 install(安装 包)、uninstall(卸载包)、upgrade(更新包)、search (搜索包)、list(列出包)、run (运⾏应⽤)、exec(在容器内执⾏ 命令)、ps(列出运⾏中容器)、kill(发送信号给容器)、prune(清理⽆⽤运⾏时)、repo(管理仓库配置)、info(显 ⽰包信息)、content(列出包导出⽂件)。为了提升⽤户体验 ，ll-cli提供 bash 和 zsh 的⾃动补全功能 ，通过⾃⾝命令动态获取补全列表。
ll-package-manager：如意玲珑包管理⼯具
如意玲珑包管理器模块主要为ll-cli提供DBus接⼝调⽤ ，它提供ll-cli的任务管理 ，并负责和ostree仓库进⾏交 互 ，最后将结果返回给ll-cli。完整流程图如下：
ll-box：如意玲珑沙箱
如意玲珑沙箱主要负责应⽤的隔离运⾏环境 ，基于OCI规范实现。ll-box负责创建、启动、停⽌和销毁容器 ，并管理容器的⽣命周期。它还负责配置容器的资源限制、 ⽹络设置和⽂件系统挂载等参数 ，以确保 应⽤在隔离的环境中安全运⾏。 完整流程如下：

如意玲珑性能测试与对⽐
⽬前主流的软件包管理体系有两类 ，⼀类是传统的包管理体系（例如debian、redhat的包管理体系），另⼀ 类是已有独⽴包格式（例如Flatpak、snap）。两种软件包管理体系各有优势 ，但前者有兼容性和安全的隐患 ，后者有性能和资源占⽤的问题 ，⾄今没有得到解决。玲珑在实现软件包管理的同时 ，更关注企业场景中的实际需求 ，在解决兼容性和安全问题的同时提⾼性能 ，降低资源占⽤ 。以下是对⽐表：

如意玲珑的发展成果

如意玲珑⾃项⽬启动以来 ，已经取得了显著的发展成果：
⼴泛的应⽤⽀持：如意玲珑已⽀持5200余款常⽤桌⾯和终端应⽤ ，涵盖办公、开发、设计等多个领域 ，满⾜⽤户的多样化需求。

多架构⽀持：如意玲珑⽀持x86_64、arm64、龙芯LoongArch64等多种CPU架构 ，确保在不同硬件平台 上都能顺利运⾏。
多Linux发⾏版⽀持：如意玲珑兼容主流Linux发⾏版 ，包括Debian、Ubuntu、Fedora等 ，确保⽤户在不 同系统环境下都能享受如意玲珑带来的便利。

活跃的社区和⽣态系统：如意玲珑拥有⼀个活跃的开发者社区和多个SIG组 ，定期举办线上线下活 动 ，促进开发者之间的交流与合作。 同时 ，越来越多的软件开发者选择将他们的应⽤打包为如意玲珑格式 ，进⼀步丰富了应⽤⽣态。

如意玲珑未来展望
如意玲珑将继续致⼒于提供更好的⽤户体验和更⼴泛的应⽤⽀持。计划：

扩展应⽤⽣态：进⼀步增加对更多应⽤的⽀持 ，特别是热⻔的开发⼯具和设计软件 ，以满⾜⽤户的 多样化需求。

更好的兼容性：通过灵活的配置⽅式、更好的 xdg-desktop-portal 协议⽀持 ，以提升如意玲珑与不同 Linux发⾏版和桌⾯环境的兼容性 ，确保⽤户在各种环境下都能顺利使⽤如意玲珑。.  优化性能：持续优化如意玲珑的性能 ，提升应⽤启动速度和运⾏效率 ，为⽤户提供更流畅的体验。

加强社区建设：通过举办更多的开发者活动和培训 ，吸引更多的开发者参与到如意玲珑的⽣态中，共同推动项⽬的发展。

探索新技术：关注前沿技术的发展 ，探索将其应⽤到如意玲珑中的可能性 ，以保持项⽬的创新性和竞争⼒。

如果您想清理安卓手机，或者只是想删除旧的、不需要的联系人，或者删除多个联系人，有三种有效的方法可供选择。无论您是想手动删除安卓手机上的联系人，还是使用专用工具，都可以按照以下步骤操作。

快速浏览一下这三种方法：

方法1：如何通过“联系人”应用手动删除Android上的联系人

删除联系人最直接的方法是直接通过安卓设备内置的“通讯录”应用。此方法非常适合一次性删除部分或全部联系人。但是，如果“通讯录”应用中有垃圾箱或回收站，则删除联系人后需要清空垃圾箱，因为已删除的联系人会被移至垃圾箱并保留 30 天。

手动删除 Android 上的联系人：

在安卓手机上找到并点击“通讯录”应用。它通常位于主屏幕或应用抽屉中。


点击要删除的联系人。点击并按住一个联系人，直到出现复选框或选择选项。然后点击要删除的其他联系人以将其选中。


寻找类似垃圾桶的图标，或者标有“删除”或“移除”的选项。这些选项通常位于屏幕顶部或三点菜单内（通常标记为“更多选项”）。


系统可能会提示您确认删除操作。点击“删除”>“确定”即可完成删除。如果应用将您已删除的联系人移至内置回收站，请前往回收站重新删除联系人。之后，您将无法在 Android 设备上访问已删除的联系人。

方法2：如何通过Google通讯录删除Android上的联系人

大多数 Android 手机都会将联系人同步到您的 Google 帐户。这意味着您可以直接在 Google 通讯录中管理和删除联系人，然后 Google 通讯录会将更改同步回您的 Android 设备。如果您更喜欢通过电脑管理联系人，或者希望确保所有同步设备上的联系人信息一致，此功能尤其实用。

以下是通过 Google 通讯录从 Android 中删除联系人的方法：

在您的计算机或手机上打开网络浏览器并导航至contacts.google.com。


使用与您的 Android 手机关联的同一 Google 帐户登录。


点击要删除的联系人。在联系人详情中，点击三点菜单（更多操作），然后选择“删除”。


要删除多个联系人，您可以将鼠标悬停在联系人的个人资料图片或姓名首字母上，直到出现复选框，然后勾选该复选框；重复此操作，删除所有要删除的联系人。然后点击“更多”>“删除”>“移至垃圾箱”。

已删除的联系人将被移至“已删除邮件”，除非您恢复，否则 30 天后这些联系人将被删除。您也可以清空已删除邮件来移除联系人。

方法3：如何通过iReaShare Android Manager删除Android上的多个联系人

如果您想在电脑上用大屏幕管理安卓联系人，并轻松删除多个或全部联系人，您可以使用iReaShare Android Manager ，这是一款功能全面的安卓数据管理工具。有了它，您可以在桌面上编辑和删除安卓联系人，并快速将联系人备份到电脑。

iReaShare Android Manager的主要功能：

• 允许您在计算机上预览您的 Android 联系人。
• 轻松从 Android 删除特定联系人。
• 使您能够一次选择多个或所有联系人，然后删除它们。

*将您的联系人从 Android 导出到 PC或 Mac 进行备份。

• 一键备份您的 Android 数据，并将备份恢复到 Android，不会丢失数据。
• 支持Android 6.0或更高版本，包括Android 16。

以下是使用联系人管理器删除 Android 上的多个联系人的方法：

以下是使用联系人管理器删除 Android 上的多个联系人的方法：

下载并安装后，在您的计算机上启动 Android Manager 软件。


使用 USB 将 Android 手机连接到电脑，并在 Android 设备上激活 USB 调试模式。连接后，点击“通讯录”继续。

选择您不再需要的联系人，然后点击“删除”菜单将其从您的 Android 设备中删除。

提示：如果您要出售或赠送手机，或者担心数据隐私，仅仅从“通讯录”应用中删除联系人是不够的。这些联系人通常可以使用数据恢复软件恢复。对于真正无法恢复的删除，建议使用像iReaShare Android Data Eraser这样的专业数据擦除工具。

提示：关于在 Android 上删除联系人的常见问题解答

问题 1：如果我清空 Android 手机上的“通讯录”应用中的垃圾箱，我是否就完全删除了这些联系人？

不一定。虽然清空 Android 手机的垃圾箱后恢复的几率会大大降低，但有人可能会使用专门的恢复应用来恢复您已删除但未被新数据覆盖的联系人。如果您想彻底删除联系人，则需要覆盖已删除的联系人。此外，如果您在手机上启用 Google 联系人同步功能，则可以轻松地通过您的帐户恢复联系人。

Q2：为什么已删除的联系人不断出现？

如果出现以下情况，则可能会发生这种情况：

Google 或其他帐户已同步。
联系人存储在只读帐户中（如 WhatsApp 或 Facebook）。
您没有从正确的帐户中删除联系人。

要修复此问题，请关闭联系人同步：设置>帐户> [帐户名称]>同步>关闭联系人。

结论

在 Android 上删除联系人非常简单，无论您是喜欢手动操作，还是通过数据管理工具iReaShare Android Manager或 Google 帐户操作，都能轻松完成。每种方法都能满足不同的需求——从快速删除到在大屏幕上管理联系人。选择最适合您需求的方法，让您的联系人列表保持整洁有序。
​

一、开发痛点：为什么我们需要AI编程辅助？

核心发现： AI编程工具正在重塑开发流程，但真正的价值不在于替代开发者，而在于构建人机协作的新型开发范式。Claude Code通过精准对话流设计、模块化任务分解和专业化子代理协作，在提升开发效率的同时，也面临着上下文管理、协作边界和质量控制等实际挑战。

作为一线开发者，我们每天都在与复杂的业务逻辑和不断迭代的技术栈打交道。不知道你是否也遇到过这些场景：刚理清一个复杂业务流程，被打断后又得重新梳理思路；接手一个老项目，花了半天还没搞懂其中某个模块的设计思路；或者在不同项目间切换时，总要重新适应不同的编码规范和架构风格。

日常开发的三个"拦路虎"：

• 上下文切换成本高： 需求理解→技术选型→代码实现→质量验证的切换过程中，每次都要重新构建认知框架。
• 知识传递效率低： 项目规范、架构经验分散在文档和个人经验中，新成员上手或跨模块开发时处处碰壁。
• 开发流程割裂： 需求→设计→编码→审查各环节串行传递，信息易失真且反馈滞后。

这些问题不是简单的"加人"或"加班"能解决的。我们需要的是一种新的开发范式，而Claude Code这类AI编程工具正是在这样的背景下进入了我们的视野。它的价值不在于替我们写代码，而在于成为我们的"认知放大器"和"流程协作者"。

二、Claude Code核心功能解析：从工具到方法论

Claude Code构建了一套完整的AI辅助开发方法论。接下来将结合团队实际使用经验，从功能特性、使用场景和设计初衷三个维度，详细介绍其核心功能：

精准对话流设计：控制AI思考的艺术

第一次用Claude Code时，就像面对一个热情但经验不足的实习生——如果不明确告诉他要做什么、怎么做、有什么要求，他很可能会给你一个"惊喜"。对话流设计就是解决这个问题的关键。

设计初衷： 对话流设计的本质是将人类的编程思维模式转化为AI可理解的结构化交互方式，通过明确的上下文管理和约束条件设置，引导AI生成符合预期的代码结果。

核心功能

对话流设计通过三个关键机制控制AI的思考过程：

• 上下文聚焦： 要求单次对话仅处理一个功能模块，避免多任务混合导致的AI注意力分散。我们曾经试过在一个对话里同时让AI处理多个模块，结果它把两个模块的错误处理逻辑混在了一起。
• 约束明确化： 通过具体指令减少AI的自由度，比如"仅修改X包下文件"、"必须复用Y工具类"。这些约束要尽可能具体，比如不说"遵循项目规范"，而是说"使用ResultDTO作为统一返回格式，错误码规则参考ErrorCodeEnum"。
• 增量式提问： 采用"先框架后细节"的提问策略，先让AI生成接口定义和整体框架，待确认后再逐步深入实现细节。这种方式很像我们带新人时"先搭骨架再填肉"的指导方法。

使用心法

启动新功能开发时，我们会创建专用对话线程，并在初始prompt中明确四件事：

1. 当前任务的功能边界和目标（做什么，不做什么。）
2. 必须遵守的技术约束和规范（用什么技术栈，遵循什么标准。）
3. 期望的输出格式和交付物（要代码？要文档？还是两者都要？）
4. 分阶段的实现计划（先设计接口，再实现逻辑，最后写测试。）

真实踩坑经验

处理跨模块依赖时，我们发现AI很容易"忘记"之前设定的约束。后来我们总结出一个技巧：每开始一个新的实现阶段，就简要回顾一下关键约束。比如："现在我们要处理任务交接流程，请记得：1. 使用Redis分布式锁；2. 需要修改商运关系和新商成长任务；3. 异常处理要符合规范。"

Plan模式：复杂任务的系统化分解

面对"实现一个完整的拜访任务系统"这样的复杂需求，直接让AI生成代码就像让一个刚入行的开发者独立负责整个项目——结果往往是逻辑混乱、漏洞百出。Plan模式就是解决这个问题的"项目管理工具"。

现状与问题：我们早期使用Claude Code时，经常犯一个错误：把一个复杂需求一股脑丢给AI，然后期待它给出完美解决方案。结果通常是：

• 实现逻辑不完整，有些边界情况根本没考虑到。
• 模块间接口设计不一致，调用起来磕磕绊绊。
• 技术选型不合理，用了个"看起来很酷但项目中并不适用"的方案。

这其实不能怪AI，人在面对过于复杂的问题时也会手足无措。我们需要一种方法把大问题拆分成小问题，而Plan模式正是借鉴了项目管理中的WBS（工作分解结构）思想。

我们的解决方案：Plan模式使用三步法分解需求：

1. 需求分析与模块划分：把整体需求分解为独立的功能模块。
2. 技术方案设计：为每个模块确定实现思路和技术选型。
3. 任务优先级排序：根据依赖关系和重要性确定实现顺序。

实际操作示例：拜访任务需求

拜访任务是一个简单的企业内部任务需求，在实现"拜访任务需求"时，我们通过Plan模式生成的任务清单是这样的：

---
拜访任务线上化 - 模块清单
M1: 任务创建模块
- 功能: 创建拜访任务,包含基本信息、拜访对象、参与人员
- 复杂度: Medium (需要处理多表关联和事务)
M2: 任务审批模块
- 功能: 飞书审批流程集成,支持任务提交、审批、驳回
- 复杂度: High (涉及飞书审批接口集成和状态流转)
M3: 日程同步模块
- 功能: 将拜访任务同步到飞书日历
- 复杂度: Medium (飞书API调用和异常处理)
M4: 任务列表查询模块
- 功能: 分页查询任务列表,支持多维度筛选
- 复杂度: Medium (ES聚合查询和数据转换)
M5: 任务详情查询模块
- 功能: 查询任务详情,包括拜访对象、参与人员、商家信息
- 复杂度: Low (简单的关联查询)
M6: 任务统计模块
- 功能: 统计不同类型、不同状态的任务数量
- 复杂度: Low (聚合统计)
M7: 拜访结果提交模块
- 功能: 提交拜访记录,上传附件,记录拜访内容
- 复杂度: Medium (文件上传和多表操作)
M8: 任务分配模块
- 功能: 批量分配任务给运营人员
- 复杂度: High (涉及分配策略和定时任务)
M9: 任务触达模块
- 功能: 任务开始、结束、上传提醒通知
- 复杂度: Medium (飞书消息卡片模板)
M10: ES数据同步模块
- 功能: 将任务数据同步到ES,支持全文检索
- 复杂度: Medium (事件驱动和ES批量操作)
M11: 任务导入模块
- 功能: Excel批量导入拜访任务
- 复杂度: High (Excel解析、数据校验、批量插入)
M12: 任务状态变更模块
- 功能: 定时更新任务状态(未开始→进行中→已结束)
- 复杂度: Low (定时任务和批量更新)
---
第二步:技术方案设计
| 模块       | 数据存储               | 查询方案         | 外部集成          |
|------------|------------------------|------------------|-------------------|
| M1-任务创建  | MySQL (事务)           | -                | -                 |
| M2-任务审批  | MySQL + 审批记录表      | -                | 飞书审批API       |
| M3-日程同步  | -                      | -                | 飞书日历API       |
| M4-任务列表  | ES (主) + MySQL (辅)   | ES聚合查询       | -                 |
| M5-任务详情  | MySQL                  | 联表查询         | 商家信息API |
| M6-任务统计  | ES                     | ES聚合统计       | -                 |
| M7-结果提交  | MySQL + OSS            | -                | OSS文件上传       |
| M8-任务分配  | MySQL                  | 分配算法         | -                 |
| M9-任务触达  | -                      | -                | 飞书消息卡片      |
| M10-ES同步  | ES                     | Spring Event     | -                 |
| M11-任务导入 | MySQL                  | Excel 解析    | -                 |
| M12-状态变更 | MySQL                  | JOB定时任务  | -                 |
---
第三步:任务优先级排序
P0 核心流程(必须先实现)
1. M1-任务创建 (基础功能)
2. M5-任务详情 (数据展示)
3. M4-任务列表 (核心查询)
4. M7-结果提交 (闭环流程)
P1 审批与通知(核心功能增强)
5. M2-任务审批 (依赖M1)
6. M3-日程同步 (依赖M2审批通过)
7. M9-任务触达 (依赖M1、M7)
P2 运营功能(效率提升)
8. M8-任务分配 (依赖M1)
9. M11-任务导入 (依赖M1)
10. M6-任务统计 (依赖M4)
P3 技术优化(性能优化)
11. M10-ES同步 (依赖M1、M4)
12. M12-状态变更 (独立模块)
---
实现建议
阶段一:基础能力
- 先实现 M1、M5、M4,打通任务创建→查询→详情的基本链路
- 使用 MySQL 实现,暂不接入 ES
阶段二:审批流程
- 实现 M2、M3,接入飞书审批和日历
- 完成任务的完整生命周期管理
阶段三:结果闭环
- 实现 M7,完成拜访结果提交
- 实现 M9,添加任务触达通知
阶段四:运营优化
- 实现 M8、M11、M6
- 提升运营效率
阶段五:性能优化(按需)
- 实现 M10,将查询迁移到 ES
- 实现 M12,优化任务状态管理

这种方式不仅让AI能够有序工作，也让我们对整个开发进度有了更清晰的把控。

系统提示词：给AI立"规矩"的艺术

如果把Claude Code比作一个新加入团队的开发人员，系统提示词（CLAUDE.md）就相当于给他的"入职手册"，告诉他团队的编码规范、工作流程和注意事项。

新手常犯的错误： 把系统提示词写成"百科全书"，恨不得把所有项目知识都塞进去。结果AI要么忽略大部分内容，要么在生成代码时顾此失彼。我们早期的系统提示词长达5000字，包含了从架构设计到代码规范的所有内容，效果反而不好。

实践心得：有效的系统提示词应该像"护栏"而非"详尽手册"。我们发现，针对AI常见错误模式设计的针对性提示，远比全面但泛泛的规范更有效。现在我们的系统提示词控制在200字以内，只包含最关键的约束和指引。

系统提示词模板

经过多次迭代，我们总结出包含三个关键模块的系统提示词结构：

使用技巧

分享几个在实践中总结的系统提示词编写技巧：

• 避免信息过载： 不要试图包含所有知识，而是指引AI在需要时查询特定文档。例如："遇到分布式事务问题时，请参考/doc/分布式事务最佳实践.md文档中的TCC模式实现方案"。
• 提供正向引导： 不仅说"不要做什么"，更要明确"应该怎么做"。例如，不说"不要使用过时的API"，而说"请使用OrderServiceV2替代OrderServiceV1。
• 动态调整策略： 我们每两周会回顾一次系统提示词的有效性，根据AI最近常犯的错误补充新的约束。比如发现AI经常忘记处理空指针，就新增一条："所有方法入参必须进行非空校验，使用ValidateUtil.isEmpty()方法，异常时抛出IllegalArgumentException"。

SKILL与MCP：知识沉淀与外部能力扩展

在团队协作中，我们经常说"不要重复造轮子"。同样，在使用Claude Code时，我们也需要一种机制来沉淀和复用那些有效的Prompt和解决方案——这就是SKILL和MCP机制的价值所在。

SKILL机制： 把好经验变成"可复用组件"

SKILL本质上是将单次生效的Prompt指令沉淀为可反复调用的标准化复用资产。举个例子，我们团队处理"ES数据查询"逻辑时，总结出了一个内部版本的SDK。我们把这个SDK的调用方式封装成一个SKILL，以后遇到类似场景，只需调用这个SKILL，AI就能按照我们团队的最佳实践来实现。

MCP协议： 让AI能"调用"外部工具

MCP（模型上下文协议）解决了AI与外部工具、数据源的连接问题。通过MCP，AI不再局限于静态知识，而是能够动态访问实时数据。我们集成了飞书MCP服务器，让AI能够直接操作飞书平台，如自动生成技术方案文档、读取PRD需求、同步数据到多维表格等。

最适合封装为SKILL的场景

1.复杂工具使用指南： 如"ElasticSearch接入"、"Redis缓存更新策略"等需要特定知识的场景。

2.常见错误处理模板： 如"分布式锁冲突处理"、"数据库乐观锁重试机制"等反复出现的问题解决方案。

MCP协议的典型应用场景

• 场景1: 自动生成技术方案文档
• AI分析需求后，通过飞书MCP调用feishu_create_doc；
• 直接在指定的知识库目录创建格式化的技术方案文档；
• 省去手动复制粘贴的繁琐步骤。
• 场景2: 读取PRD需求
• 用户提供飞书文档链接；
• AI通过feishu_get_doc_content获取文档内容；
• 基于完整需求信息生成技术方案和实现计划。

• 场景3: 数据同步到多维表格
• 代码生成后的统计数据(如代码行数、涉及文件等)；
• 通过feishu_append_bitable_data自动追加到飞书多维表格；
• 便于团队追踪AI编程效率指标。

三、对话流设计方法论：让AI"懂"你的真实需求

刚接触Claude Code时，我们采用的是简单直接的"需求-响应"模式：开发者描述需求，AI生成代码，开发者修改调整。这种模式在处理简单功能时还行，但遇到复杂场景就会出问题。

现状分析：传统对话模式的局限性

我们早期在项目中踩过的三个坑：

三大典型问题：

• 需求表达不完整：

开发者说"实现一个商家信息查询接口"，AI生成了基础的CRUD代码，但没有考虑商家数据权限、数据脱敏、缓存策略等实际业务需求 ；

实现任务时，只描述了"需要任务分配功能"，结果AI生成的代码没有处理任务池、任务优先级、分配策略等核心逻辑。

• 上下文管理混乱：

一个对话持续了十几轮后，AI开始忘记我们前面确定的"使用MyBatis-Plus + BaseMapper"的设计决策，擅自改成了JPA Repository模式； 

在实现相关功能时，早期确定的DTO转换规范在后续模块中被遗忘，导致代码风格不一致。

• 迭代反馈滞后：

等AI生成完整的Service + Controller + Repository代码后才发现方向不对，比如数据库表设计与现有架构冲突，不得不从头再来，浪费了大量时间；

实现触达功能时，生成的飞书消息发送代码没有考虑现有的FeishuClient封装，重复造了轮子。

核心问题：为什么AI总是"听不懂"？

深入分析后，我们发现传统对话模式失败的根源在于三个核心矛盾：

语义鸿沟

自然语言描述的模糊性与代码逻辑的精确性之间的差距。我们说"这个接口要安全"，AI可能理解为"需要登录校验"，而我们实际想要的是：

• 使用项目中的@Permission注解进行权限校验。
• 参数需要使用ValidatorUtil进行校验。
• 敏感操作需要记录操作日志。

约束衰减

随着对话推进，早期设定的技术约束在AI理解中的权重逐渐降低。就像我们记笔记时，重要的事情要反复强调。比如：

• 第1轮对话强调"必须继承BaseServiceImpl"。
• 第5轮对话AI可能忘记这个约束，直接实现了一个独立的Service类。
• 第10轮对话可能连项目的分层架构都混淆了。

目标偏移

在多轮对话中，AI容易过度关注当前细节而忽视整体目标。比如讨论某个接口的参数设计时：

• AI可能会纠结于参数名称是否优雅。
• 而忽略了这个接口的核心业务价值是"快速检索符合条件的商家"。
• 结果生成的代码参数命名很完美，但缺少了分页、排序等实际必需的功能。

解决方案：结构化对话设计方法

针对这些问题，我们团队总结出一套"三阶段对话模型"，现在已经成为我们使用Claude Code的标准流程：

阶段一：需求定义——把"要做什么"说清楚

这个阶段的目标是确保我们和AI对需求达成共识。我们会用"用户故事+验收标准"的格式来描述需求：

示例1：新商户成长任务分配

【用户故事】
作为新商户运营，我需要一个任务分配功能，以便将成长任务高效分配给运营人员
【验收标准】
 - 支持从任务池中按优先级(P0/P1/P2)筛选待分配任务
 - 支持指定运营人员进行任务分配，需校验运营人员是否有权限
 - 分配时需检查运营人员当前任务负载，超过上限时提示"当前任务数已达上限"
 - 分配成功后需发送飞书消息通知运营人员，消息内容包含任务详情和截止时间
 - 操作需记录到表，包含操作人、操作时间、任务ID、分配对象

示例2：商家数据权限查询

【用户故事】
作为商家运营，我需要一个商家信息查询接口，查询结果需要根据我的数据权限进行过滤
【验收标准】
 - 支持按商家ID、商家名称、商家状态进行查询
 - 支持分页查询，默认每页20条，最大100条
 - 查询结果需要根据当前用户的数据范围进行过滤
 - 商家敏感信息(手机号、身份证号)需脱敏处理
 - 接口需要权限校验，至少具有"商家查看"权限
 - 查询条件需记录到操作日志，便于审计

阶段二：边界明确——确定"怎么做"的约束条件

在这个阶段，我们会明确技术栈选择、架构设计和各种约束条件。关键是要区分"必须遵守"和"建议参考"的约束：

示例1：新商户成长任务模块

【技术约束】
必须遵守:
 - 使用SpringBoot标准分层架构,所有Service继承OcsBaseServiceImpl
 - 数据库操作使用MyBatis-Plus,实体类继承BaseEntity,Mapper继承BaseMapper
 - 接口返回统一使用Result<T>格式,错误码使用ErrorCode
 - 权限校验使用@Permission注解,参数校验使用@Valid + ValidatorUtil
 - 飞书消息发送必须使用FeishuClient,不要重复实现
建议参考:
 - 任务状态流转参考TaskServiceImpl中的状态机模式
 - 批量分配操作参考AssignImportHandler中的异步处理方式
 - 运营人员权限校验参考OperatorRelationServiceImpl
 - 数据权限过滤参考ScopeServiceImpl中的范围查询逻辑
【数据库约束】
 - 新增表必须包含created_at, updated_at, is_deleted字段
 - 表名使用ocs_前缀,字段名使用蛇形命名法
 - 索引设计需考虑查询场景,高频查询字段必须建立索引
 - 外键约束通过代码层面维护,不在数据库层面创建

示例2：机器人问答功能

【技术约束】
必须遵守:
 - Controller层使用@RestController + @RequestMapping,路径遵循/api/v1/{module}/{action}格式
 - Service层业务逻辑必须有事务控制,使用@Transactional(rollbackFor = Exception.class)
 - DTO转换使用项目中的ConvertUtil,不要手动赋值
 - 第三方API调用(如Dify)必须有重试机制和降级策略
 - 敏感配置(API Key)必须从配置中心读取,不要硬编码
建议参考:
 - 对话上下文管理参考RobotServiceImpl中的会话ID生成逻辑
 - 消息发送失败重试参考FeishuMessageHandler中的重试策略
 - 错误处理参考GlobalExceptionHandler中的统一异常处理
【集成约束】
 - Dify API调用统一通过DifyClient,响应格式需转换为项目标准格式
 - 飞书机器人回调处理需实现签名校验,参考FeishuEventHandler
 - 所有外部API调用需记录请求日志到integration_log表 

阶段三：迭代反馈——在"做的过程"中持续对齐

这个阶段的核心是增量验证，避免一次性生成大量代码后才发现方向错误。

实践要点：

1.分模块实现，逐个验证

• 先实现核心接口(如任务分配)，验证通过后再实现辅助功能(如任务查询)。
• 先实现Service层核心逻辑，验证业务流程正确后再补充Controller和参数校验。

2.关键节点主动暂停

• 数据库表设计完成后，先让开发者确认表结构再继续。
• 核心业务逻辑实现完成后，先通过单元测试验证再生成Controller。
• 集成第三方API前，先确认调用方式和参数映射。

3.持续同步技术方案

• 发现架构设计与现有代码不一致时，立即更新tech-solution.json和tech-solution.md。
• 新增数据表、修改核心逻辑时，同步更新技术方案文档。
• 每个模块完成后，更新模块状态为implemented → reviewed → verified。

对话示例：

开发者: "实现新商户成长任务分配功能"
AI: "我将分三步实现:
1. 先设计数据库表结构(ocs_task_assignment表)
2. 实现核心分配逻辑(NewMerchantTaskAssignService)
3. 实现Controller层接口
现在开始第一步,设计的表结构如下:
[展示表结构]
请确认表结构是否符合需求?"
开发者: "字段没问题,但索引需要加上(operator_id, status)"
AI: "已更新索引设计,现在开始实现Service层核心逻辑...
[生成Service代码]
核心逻辑已实现,包含:
- 任务池查询(按优先级过滤)
- 运营人员负载检查
- 任务分配和状态更新
- 飞书消息发送
请验证业务逻辑是否正确?"
开发者: "逻辑正确,继续实现Controller"
AI: "开始实现Controller层...
[生成Controller代码]
已完成模块M1实现,更新技术方案状态为implemented"

对话设计三原则与常见问题应对策略

为什么这样设计：背后的认知科学原理

这种结构化对话设计不是凭空想出来的，而是基于我们对人类认知过程的理解：

• 工作记忆限制理论： 就像我们一次只能记住7±2个信息块一样，AI的上下文理解能力也是有限的。通过分阶段对话和单次聚焦单模块，我们控制了每次交互的认知负荷。
• 渐进式知识构建： 学习和理解是一个渐进过程，先掌握整体框架再深入细节，符合认知规律。这和我们教新人时"先讲架构图，再讲模块间交互，最后讲具体实现"的思路是一致的。

四、AI团队协作模式：子代理系统的实践与思考

随着团队使用Claude Code的深入，我们发现单个AI助手已经难以满足复杂项目的开发需求——就像一个人再厉害也干不了一个团队的活。于是，我们开始探索让多个AI"角色"协同工作的模式，这就是子代理（SubAgent）系统的由来。

团队协作的现状与挑战

在传统开发模式中，我们有需求分析师、架构师、开发工程师、测试工程师等不同角色，他们通过文档、会议和代码审查等方式协作。这种模式虽然成熟，但在快节奏的业务迭代中，我们发现了一些问题：

协作中的三大痛点：

• 信息传递损耗： 需求文档从产品经理到开发再到测试，每经过一个环节就可能产生一些理解偏差。就像玩"电话游戏"，信息传到最后可能已经面目全非。
• 责任边界模糊： 当出现问题时，有时会出现"这是架构设计问题"、"这是实现问题"、"这是测试不充分"的互相推诿。
• 反馈周期漫长： 从需求分析到代码审查，整个流程走下来往往需要几天时间，等发现问题时可能已经投入了大量开发资源。

这些问题促使我们思考：能不能在Claude Code中模拟团队协作模式，让不同的AI角色各司其职又协同工作？

Claude Code的子代理协作模式

借鉴了MetaGPT等框架的思想，我们在Claude Code中构建了由多个专业化子代理组成的AI团队协作系统。每个子代理承担特定角色，通过标准化中间产物协同工作。

核心工作机制：中间产物驱动

所有子代理通过共享"技术方案文档"进行协作，这个文档就像团队的"共享白板"，包含需求分析、模块划分、实现状态和接口设计等关键信息。每个子代理只负责修改文档中与自己角色相关的部分，确保信息一致性。

四个核心子代理角色

技术方案架构师

负责需求分析、技术方案设计和模块划分。相当于团队里的架构师，输出"技术方案文档"这个"施工蓝图"。

核心职责：

• 需求拆解与模块划分
• 技术栈选型与架构设计
• 接口定义与数据模型设计
• 模块间依赖关系梳理
• 技术方案文档编写与维护

代码审查专家

负责代码质量审查。扮演技术负责人的角色，从架构合规性、代码规范和稳定性等角度挑毛病。

核心职责：

• 检查代码是否符合架构设计
• 验证代码规范和命名约定
• 识别潜在性能问题和bug
• 评估代码可维护性和扩展性
• 提供具体修改建议

代码实现专家

专注于代码实现和单元测试编写。就像主力开发工程师，按照架构师设计的蓝图一块块地实现功能。

核心职责：

• 根据技术方案实现代码
• 编写单元测试和集成测试
• 修复代码审查中发现的问题
• 编写API文档和使用说明
• 同步更新技术方案实现状态

前端页面生成器

专门负责生成符合我们低代码平台规范的前端页面配置。这是针对我们商家域管理后台特点定制的角色。

核心职责：

• 根据接口定义生成前端页面配置
• 实现表格、表单、详情页等标准组件
• 配置页面权限和数据范围过滤
• 优化前端交互体验
• 确保符合设计规范和响应式要求

协作流程

我们采用"先整体规划，再迭代实现"的工作方式，有点像敏捷开发中的Sprint规划+Daily Scrum：

1. 整体规划阶段：

• 产品经理提供需求文档。
• 协调者调用"技术方案架构师"子代理分析需求，生成技术方案文档。
• 团队评审技术方案，提出修改意见。
• 架构师子代理根据反馈修改方案，直到团队确认。

2. 单模块迭代阶段：

• 协调者从技术方案文档中选取一个模块。
• 调用"代码实现专家"生成代码。
• 调用"代码审查专家"审查代码。
• 实现专家根据审查意见修改代码。
• 重复"实现-审查-修改"直到通过。
• 更新技术方案文档，标记该模块为"已完成"。
• 进入下一个模块。

子代理协作的价值与局限

实践中的三个显著价值

• 专业化分工提升质量： 每个子代理专注于特定领域，就像专科医院比综合医院在特定疾病上更专业一样。我们发现，专门的代码审查子代理比通用AI能发现更多潜在问题。
• 流程标准化降低风险： 通过技术方案文档和明确的角色分工，开发流程被标准化和可视化。新人加入项目时，只要看技术方案文档就能快速了解整体情况。
• 知识沉淀促进复用： 子代理的专业知识和决策逻辑被编码为可复用的配置和规则，避免了"人走经验丢"的问题。

遇到的四个实际挑战

子代理协作的挑战与应对：

• 上下文同步问题： 当技术方案文档更新时，各子代理有时不能立即同步最新信息。解决办法：每次修改文档后，明确通知相关子代理"技术方案中XX部分已更新"。
• 协作边界模糊： 在处理跨模块功能时，出现"该由哪个子代理负责"的困惑。解决办法：在技术方案文档中添加"责任人"字段，明确每个模块由哪个子代理负责。
• 灵活性与标准化的平衡： 高度标准化的流程有时会限制处理特殊情况的灵活性。解决原则：90%的常规情况严格遵循标准流程，10%的特殊情况由人工介入处理。
• 错误传递放大效应： 如果技术方案设计阶段就有问题，这个问题会在后续实现和审查阶段被放大。解决办法：加强技术方案的人工评审环节，确保"地基"打牢。

子代理协作的设计思考

在设计这套协作模式时，我们有几个关键思考：

• 为什么选择"中间产物驱动"而非"直接沟通"？
• 直接让子代理之间对话可能更灵活，但会导致沟通成本指数级增加（n个代理就有n(n-1)/2种沟通渠道）。通过"技术方案文档"这个单一事实来源，我们大大降低了协作复杂度，也便于追踪变更历史。
• 角色划分的依据是什么？
• 我们的角色划分基于软件开发的自然阶段（设计→实现→审查）和专业领域（后端→前端），这符合软件开发生命周期的自然规律。没有盲目追求角色数量，而是根据实际需求逐步增加。
• 为什么采用"增量迭代"而非"一次性开发"？
• 复杂系统的构建本质上是一个不断学习和调整的过程。增量迭代让我们能够及早发现问题并调整方向，避免在错误的道路上走得太远。这和我们常说的"小步快跑，快速迭代"理念一致。

五、实践经验与未来展望

经过几个月的Claude Code实践，从最初的"试试看"到现在成为离不开的开发工具，我们积累了一些经验，也对AI编程的未来有了更清晰的认识。

实践经验总结

人机协作的最佳平衡点：

我们发现最有效的AI编程模式是"人类主导，AI辅助"，而不是反过来。我们将工作内容分为三类：

• AI主导： 标准化代码生成（如基础CRUD接口）、单元测试编写、API文档生成等重复性高、规则明确的任务。
• 人机协作： 技术方案设计、复杂逻辑实现、代码审查等需要结合领域知识和创造性思维的任务。
• 人类主导： 需求分析、架构设计、质量决策等高风险、高创造性的任务。

上下文管理的实用技巧

管理好对话上下文是用好Claude Code的关键，分享几个我们团队总结的技巧：

• 对话线程化： 为不同功能模块创建独立对话线程。我们曾经在一个对话里讨论三个不同模块，结果上下文混乱到不得不从头开始。
• 关键信息锚定： 重要的技术决策和约束要在对话中反复强调。就像写文章时，核心观点要多次出现。
• 文档外化： 复杂设计和决策要记录在外部文档中，而不是仅依赖对话历史。我们会在对话中引用这些文档："数据库设计详见/doc/db_design.md，特别是索引设计部分"。
• 状态可视化： 通过技术方案文档中的进度标记（如[未开始]、[设计中]、[已实现]、[已审查]），直观跟踪开发状态。

质量控制的三个关键策略

使用AI生成代码后，质量控制变得更加重要。我们的做法是：

• 多层次验证： 单元测试（AI生成）+ 集成测试（人工设计）+ 代码审查（人机结合）的三层验证体系。
• 渐进式信任： 从简单、低风险模块开始使用AI，建立信任后再逐步扩展。我们最先用AI生成内部工具，验证没问题后才用于核心业务系统。
• 错误模式学习： 记录AI常犯的错误类型，针对性优化系统提示词。我们有一个"AI错误案例库"，记录了"AI忘记处理分布式锁超时"、"日期格式转换错误"等典型问题及解决方案。

AI编程的局限性认知

在实践过程中，我们也清醒地认识到AI编程并非万能解决方案，它有几个明显的局限性：

• 创造性思维不足： AI擅长在已有知识范围内进行组合和优化，但在需要突破性创新的场景下表现有限。比如我们尝试让AI设计一个全新的商家结算模型时，它还是会倾向于参考现有模型进行修改，难以跳出固有思维框架。
• 上下文理解深度有限： 尽管Claude Code的上下文窗口已经很大，但对于我们系统中某些"牵一发而动全身"的核心模块，AI还是难以把握其深层设计意图和与其他模块的隐性依赖。
• 质量责任边界模糊： 当AI生成的代码出现质量问题时，责任界定变得复杂。我们的解决办法是：开发者对AI生成的代码负全部责任，就像我们对自己写的代码负责一样。
• 领域知识滞后性： AI对我们公司内部系统的最新变更反应不够及时。为此我们建立了"知识库更新机制"，每月将最新的系统变更和业务规则整理成文档，供AI参考。

未来发展方向思考

基于这些实践经验，我们对AI编程工具的未来发展有几点思考：

• 更智能的上下文管理： 未来的AI编程工具应该能自动识别相关上下文、追踪依赖关系，并在适当的时候提醒开发者潜在的上下文冲突。就像经验丰富的团队领导，能记住每个人负责的模块和项目的整体情况。
• 多模态交互模式： 除了文本对话，未来可能引入图表、流程图等多种交互方式。有时画一个简单的流程图(PlantUML)，比写几百字描述更能说明问题。
• 自适应学习机制： AI编程工具应该能从团队的使用反馈中学习，适应特定团队的编码风格和业务领域。就像新加入团队的开发者，会逐渐适应团队的工作方式。

六、结语：人机协作的新型开发范式

回顾这几个月使用Claude Code的经历，我们最大的体会是：AI编程工具的价值不在于替代开发者，而在于构建人机协作的新型开发范式。在这种范式下，人类开发者从繁琐的重复劳动中解放出来，更专注于需求分析、架构设计和质量把控等高价值创造性工作，而AI则承担起代码实现、文档生成和基础验证等标准化工作。

Claude Code作为我们实践的核心工具，通过精准对话流设计、模块化任务分解和专业化子代理协作，展示了这种新型开发范式的潜力。但我们也认识到，成功的AI编程应用需要"工具+方法论+团队协作"三位一体的系统性变革，其中人的角色从"代码生产者"向"问题解决者"和"质量把控者"转变。

作为开发者，我们需要保持开放学习的心态，积极探索和适应这种新范式。未来已来，与其恐惧被AI替代，不如学会与AI协作，在人机协作中实现更高的个人价值和团队效能。毕竟，代码只是解决问题的手段，而非目的；AI只是增强我们能力的工具，而真正的创新和价值，始终源于人的智慧和创造力。

实践启示： 在AI编程时代，最有价值的开发者不是"写代码最快的人"，而是"最会引导AI、最能把控质量、最能解决复杂问题的人"。掌握与AI协作的技巧，建立系统化的AI辅助开发流程，将成为未来开发者的核心竞争力。我们的经验表明，通过合理设计对话流程、明确分工协作和严格质量控制，AI编程工具能够显著提升团队效能，但这需要整个团队在思维方式和工作流程上的共同转变。

往期回顾

1.入选AAAI-PerFM｜得物社区推荐之基于大语言模型的新颖性推荐算法

2.Galaxy比数平台功能介绍及实现原理｜得物技术 

3.得物App智能巡检技术的探索与实践

4.深度实践：得物算法域全景可观测性从 0 到 1 的演进之路

5.前端平台大仓应用稳定性治理之路｜得物技术

文 /稚归

关注得物技术，每周更新技术干货

要是觉得文章对你有帮助的话，欢迎评论转发点赞～

未经得物技术许可严禁转载，否则依法追究法律责任。

统信Windows应用兼容引擎 V3.4.2 更新日志
【优化】高级调试-组件安装内增加组件介绍
【优化】支持直接打开日志文件
【优化】投递应用时exe下载链接的预设文案
【优化】外显了每个专区内收录的应用数量组件安装增加详细介绍之前有人吐槽，高级调试-组件安装当中的组件都是英文的，能不能提供中文名称？

这些组件的名称本来就是英文的，没有中文名称，比如“JAVA”就是“JAVA”，“mono”就是“mono”，它没有中文名称，强行翻译成中文反而不方便大家去查询使用，但是我们可以给这些组件添加中文的介绍说明，告诉大家这些组件是干什么的，方便大家进行wine调试和研究：可以了解到wine应用一般都会安装什么组件解决什么问题，调试运行的时候需要解决什么问题，也可以去组件里搜索进行组件安装尝试。

直接打开调试日志文件高级调试-调试日志窗口处进行了一个微小的优化，将“打开日志”的行为从“打开日志所在文件”调整为“打开日志文件”。之前的版本当中，“打开日志”功能是打开日志所在文件夹，需要用户使用其他工具来打开日志文件，多了一步流程，而且查看日志的效果受到默认打开日志文件工具的影响。

兼容引擎本质上是一个工具型的应用，工具型应用是要注重效率问题的，随着收到大家越来越多的应用投递和应用适配申请，在进行应用wine适配时，需要频繁的进行应用调试和查看日志，缩短打开日志的路径以及更方便的审查日志，可以极大的提高wine适配效率，基于上述实际使用场景，将“打开日志”的行为从“打开日志所在文件”调整为“打开日志文件”，用来打开日志文件的工具是deepin-wine团队日常使用的日志分析工具，大家有好的想法也可以给我们提建议。

优化exe下载链接引导文案在投递应用时，填写exe文件下载链接的引导文案调整为“请提供链接用于复测，官方链接优先采用”。

这个优化点很小，但却是需要大家认真关注的一个地方。一些应用程序是否能成功wine是与其版本号有强关联的，因此兼容引擎在提供wine应用数据库的时候着重强调了exe文件的版本号，大家在投递wine应用的时候一定要投递准确的应用版本，并且尽量提供软件官方的下载链接，方便审核人员下载应用可以加速审核。外显各应用专区内收录的软件数量自2025年5月21日上线“全部应用”模块后，经过deepin社区多次wine众测活动，在deepin-wine团队和各位爱好者们的共同努力建设下，目前兼容引擎已经收录了超过 3800+款应用。

为了控制应用投递的质量，目前兼容引擎的应用投递功能做了诸多限制，对于最重要的“应用名称”和“应用版本号”信息采用直接读取PE文件信息的策略，不允许自定义修改。同时为了防止恶意代码注入之类的风险，各字段的数据传输做了严格限制，因此一些打包不规范的exe文件、有风险的链接格式和字符可能导致无法投递。

什么是访答？它如何改变我们的生活

在这个信息爆炸的时代，我们每天都会遇到各种各样的问题。从简单的日常疑问到复杂的专业难题，寻找准确答案往往需要花费大量时间和精力。而访答技术的出现，正在悄然改变我们获取知识的方式。

访答技术的基本原理

访答，顾名思义，就是访问和回答的简称。它是一种基于人工智能的智能问答系统，通过自然语言处理技术理解用户提出的问题，然后从海量数据中寻找最相关的信息，最终给出准确、简洁的答案。

与传统的搜索引擎不同，访答系统不是简单地返回一堆相关网页链接，而是直接给出问题的答案。这就像有一个知识渊博的专家随时待命，能够立即回答你的任何疑问。

访答技术的核心优势

高效获取信息

传统的信息搜索需要用户浏览多个网页，筛选有用信息，这个过程可能耗时数分钟甚至更久。而访答系统能在几秒钟内提供精准答案，大大提高了信息获取效率。

理解自然语言

访答技术能够理解人类自然的提问方式。你不需要学习特定的搜索语法或关键词组合，就像与人对话一样自然地提问即可。

多领域知识覆盖

优秀的访答系统通常拥有跨领域的知识库，从日常生活常识到专业学术问题，都能提供可靠的解答。

访答与传统搜索的区别

为了更好地理解访答的价值，让我们比较一下它与传统搜索引擎的主要区别：

交互方式不同

传统搜索是关键词匹配，而访答是语义理解。前者需要用户提炼关键词，后者理解问题的完整含义。

结果形式不同

搜索引擎返回的是网页列表，用户需要自行筛选；访答直接给出答案，节省了中间步骤。

适用场景不同

简单的事实性问题适合使用访答，而需要多角度了解的研究性课题可能还是传统搜索更合适。

访答技术的应用场景

教育学习

学生在学习过程中遇到难题时，可以通过访答系统快速获得解答和解释，提高学习效率。

工作辅助

专业人士在工作中遇到技术难题或需要快速查阅资料时，访答能提供即时帮助。

日常生活

从烹饪技巧到健康咨询，从旅行规划到产品比较，访答让获取生活常识变得轻而易举。

如何更好地使用访答

提问要具体明确

虽然访答系统能理解自然语言，但清晰具体的问题往往能得到更准确的答案。

善用追问功能

如果对答案不满意或不理解，可以继续追问，访答系统通常能够提供更深入的解释。

验证重要信息

对于关键信息，特别是涉及健康、法律等重要领域的建议，最好通过多个来源进行验证。

访答技术的未来发展

随着人工智能技术的不断进步，访答系统将变得更加智能和人性化。未来的访答可能具备更强的推理能力，能够处理更复杂的问题，甚至主动预测用户的需求。

同时，访答技术也将更好地融入我们的日常生活，成为智能家居、车载系统、移动设备的标准配置，随时随地为人们提供知识服务。

结语

访答技术正在重新定义我们获取知识的方式，它让信息的获取变得更加高效、便捷。虽然它不能完全取代人类的思考和学习过程，但作为强大的辅助工具，访答无疑为我们打开了一扇通往知识的新大门。

在这个信息过载的时代，拥有一个可靠的访答伙伴，或许就是我们保持竞争力的重要法宝。

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 经过深度评估，最终选择阿里云数据库 SelectDB 版作为其全新可观测性数据平台的核心基座。阿里云数据库 SelectDB 版凭借其更低的成本、更高的查询性能以及更灵活的查询方式在众多产品中脱颖而出。其关键特性精准匹配了现代 AI 业务的严苛要求：

• 云原生存算分离架构：基于对象存储 OSS 的存储层与弹性计算层解耦，支持独立、无损的弹性伸缩，为应对日志洪峰提供了近乎无限的扩展能力。
• 多集群硬隔离与数据共享：支持云原生多集群硬隔离能力，用户可以将单个实例的计算资源划分为多个逻辑集群，不同集群之间的分配独立的计算资源，实现了不同集群的严格物理资源隔离和数据共享。
• 智能缓存加速：通过单副本本地读写缓存、智能数据淘汰策略、高效列式存储格式和先进压缩算法，显著提升了海量数据的读写效率。

阿里云数据库 SelectDB 植根于开源 Apache Doris 的坚实基础，深度融合云随需而用的特性，依托阿里云基础设施，构建起云原生存算分离的全新架构，面向企业海量数据的实时分析需求，提供极速实时、湖仓融合统一、简单易用的云上数仓服务。

基于阿里云 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

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

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 组件