请查阅参考昇腾社区文档：https://gitee.com/ascend/MindSpeed-LLM/blob/2.1.0/docs/pytorch/features/yarn.md 

MyBatis 完全支持 GaussDB（包括华为云 GaussDB、openGauss），核心原因是：GaussDB 兼容主流数据库协议（PostgreSQL 或 MySQL 协议），而 MyBatis 作为 ORM 框架，不直接依赖数据库本身，仅通过 JDBC 驱动 与数据库交互 —— 只要 GaussDB 提供标准 JDBC 驱动，MyBatis 就能无缝适配，无需额外修改框架源码。一、支持的核心逻辑MyBatis 的核心是 “通过 SQL 映射与 JDBC 连接数据库”，其适配性取决于：GaussDB 提供兼容 JDBC 规范的驱动（华为云 GaussDB、openGauss 均提供官方 JDBC 驱动）；GaussDB 兼容标准 SQL 语法（或 PostgreSQL/MySQL 语法），MyBatis 的 SQL 映射、动态 SQL、结果映射等功能均可正常使用。无论是华为云托管的 GaussDB（如 GaussDB (for PostgreSQL)、GaussDB (for MySQL)），还是开源的 openGauss，MyBatis 都能完美支持。二、MyBatis 集成 GaussDB 的实操步骤以 Spring Boot + MyBatis + 华为云 GaussDB (for PostgreSQL) 为例（openGauss 配置完全一致，仅驱动和 URL 略有差异）：1. 引入依赖（Maven）核心依赖包括：MyBatis 核心包、Spring Boot 整合 MyBatis starter、GaussDB JDBC 驱动。<!-- 1. Spring Boot 整合 MyBatis 依赖 --><dependency> <groupId>org.mybatis.spring.boot</groupId> <artifactId>mybatis-spring-boot-starter</artifactId> <version>2.3.2</version> <!-- 适配 Spring Boot 版本，建议用稳定版 --></dependency><!-- 2. GaussDB JDBC 驱动（华为云 GaussDB/开源 openGauss 通用） --><!-- 华为云 GaussDB 推荐用官方驱动 --><dependency> <groupId>com.huawei.gaussdb</groupId> <artifactId>gaussdb-jdbc</artifactId> <version>1.0.1</version> <!-- 需与 GaussDB 版本匹配，参考官方文档 --></dependency><!-- 若为 openGauss，也可使用开源驱动 --><!-- <dependency> <groupId>org.opengauss</groupId> <artifactId>opengauss-jdbc</artifactId> <version>3.1.0</version></dependency> --><!-- 3. 数据库连接池（可选，推荐 HikariCP，Spring Boot 2.x+ 默认集成） --><dependency> <groupId>com.zaxxer</groupId> <artifactId>HikariCP</artifactId></dependency> 2. 配置数据源（application.yml）关键配置：JDBC 驱动类、连接 URL、用户名密码（GaussDB 的 URL 格式与 PostgreSQL 类似）。spring: datasource: # 1. GaussDB JDBC 驱动类（华为云 GaussDB 和 openGauss 通用） driver-class-name: org.postgresql.Driver url: jdbc:postgresql:// username: your-username password: your-password # 3. 连接池配置（HikariCP） hikari: maximum-pool-size: 10 minimum-idle: 2 connection-timeout: 30000# MyBatis 配置（可选，根据需求调整）mybatis: mapper-locations: classpath:mapper/*.xml # Mapper 映射文件路径 type-aliases-package: com.example.entity # 实体类别名包 configuration: map-underscore-to-camel-case: true # 下划线转驼峰（如 user_name → userName） log-impl: org.apache.ibatis.logging.stdout.StdOutImpl # 打印 SQL 日志（调试用）注意一下下：如果 GaussDB 是 “兼容 MySQL 协议” 的版本（如 GaussDB (for MySQL)），驱动类和 URL 需调整为 MySQL 格式：driver-class-name: com.mysql.cj.jdbc.Driverurl: jdbc:mysql:// 驱动类也可使用 GaussDB 专属驱动 com.huawei.gaussdb.jdbc.Driver（华为云推荐），URL 格式不变。3. 编写 Mapper 接口与 XML 映射文件与操作 MySQL、PostgreSQL 完全一致，MyBatis 的所有功能（动态 SQL、分页、结果映射等）均可正常使用。实体类 User.javapublic class User { private Long id; private String userName; // 对应数据库 user_name 字段（下划线转驼峰生效） private Integer age; // getter/setter 省略}Mapper 接口 UserMapper.java@Mapperpublic interface UserMapper { // 新增用户 int insert(User user); // 根据 ID 查询用户 User selectById(Long id); // 动态 SQL：条件查询 List<User> selectByCondition(@Param("userName") String userName, @Param("age") Integer age);}Mapper 映射文件 UserMapper.xml、<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE mapper PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN" "http://mybatis.org/dtd/mybatis-3-mapper.dtd"><mapper namespace="com.example.mapper.UserMapper"> <!-- 新增用户 --> <insert id="insert" parameterType="com.example.entity.User"> INSERT INTO user (user_name, age) VALUES (#{userName}, #{age}) </insert> <!-- 根据 ID 查询 --> <select id="selectById" parameterType="java.lang.Long" resultType="com.example.entity.User"> SELECT id, user_name, age FROM user WHERE id = #{id} </select> <!-- 动态 SQL 条件查询 --> <select id="selectByCondition" resultType="com.example.entity.User"> SELECT id, user_name, age FROM user <where> <if test="userName != null and userName != ''"> AND user_name LIKE CONCAT('%', #{userName}, '%') </if> <if test="age != null"> AND age = #{age} </if> </where> </select></mapper>4. 测试验证编写测试类，验证 MyBatis 能否正常操作 GaussDB：@SpringBootTestpublic class UserMapperTest { @Autowired private UserMapper userMapper; @Test public void testInsertAndSelect() { // 新增用户 User user = new User(); user.setUserName("test"); user.setAge(25); userMapper.insert(user); // 查询用户 User result = userMapper.selectById(1L); System.out.println(result.getUserName()); // 输出 "test"，说明集成成功 }}三、注意下哦驱动版本匹配：GaussDB 驱动版本需与数据库版本对应（如 openGauss 3.x 对应驱动 3.x 版本），否则可能出现连接失败、SQL 执行异常等问题，建议参考 华为云 GaussDB 官方文档 或 openGauss 文档 选择驱动。SQL 兼容性：GaussDB 兼容 PostgreSQL 或 MySQL 的 SQL 语法，MyBatis 中的标准 SQL、动态 SQL 均可直接使用；若使用 GaussDB 特有语法（如分区表、并行查询），需在 XML 中直接编写对应 SQL，MyBatis 无额外限制。分页插件支持：MyBatis-Plus、PageHelper 等分页插件同样支持 GaussDB，只需在插件配置中指定数据库类型为 postgresql（兼容 GaussDB）： # PageHelper 配置示例pagehelper: helper-dialect: postgresql reasonable: true  事务支持：Spring 声明式事务（@Transactional）完全兼容 GaussDB，无需额外配置，事务隔离级别、传播行为等遵循 JDBC 标准。总结一下下MyBatis 对 GaussDB 的支持是 “无缝适配” 的，本质是通过 GaussDB 提供的 JDBC 驱动实现连接，MyBatis 的所有核心功能（SQL 映射、动态 SQL、分页、事务等）均可正常使用。

  (2025年11月）  < 华为云Versatile智能体平台 体验入口>华为开发者空间--开发平台--Versatile Agent （请在PC端打开）  版本概览 华为云Versatile智能体平台定位为一站式企业级智能体构建平台，倡导人人都能构建自己的企业级智能体。本次十一月版本升级，新增多项重点特性，包括Agent web分享能力、NL2Agent技术的落地——AI创建智能体、提示词工程体验重构、Agent观测等，以及知识库、平台资源订购等能力增强，更好地满足海量客户在企业级Agent平台上的使用需求，并致力于深化产品能力，持续与开发者合力构建易用、好用、开放的AI Agent平台。  新增重点特性介绍 01  Agent web分享能力  应用管理· 支持单智能体应用、工作流应用发布为网页，可分享使用；并增加资源配置，可设置每日调用限额。业务价值：通过一键发布，支持在web端快捷访问智能体应用；可通过链接形式将Agent分享给他人体验，极大提升AI Agent的对外分享能力与成果使用率。  02 一句话智能生成智能体应用管理· 支持通过自然语言、对话交互式创建智能体，轻松实现AI创建应用业务价值：用户通过自然语言描述需求，实现无码化、智能化创建单智能体应用、工作流应用，大幅降低构建AI应用的门槛。面向企业内用户，可显著减轻海量智能体创建的工作量。入口一：首页概览对话区入口二：创建应用-AI创建  03 提示词功能重构  应用管理· 重构"创建提示词"功能，界面更新；重构"优化提示词"功能，可在提示词中引入变量，实现不同场景下的快速复用；新增变量数据测评集，实现模型辅助构建。业务价值：简化提示词工程的开发流程，引入变量概念，借助大模型的学习能力，实现提示词的智能化构建。通过添加数据评测集和补充提示词背景知识等，可以帮助模型更好地理解提示词，多场景评测数据使提示词指令更加具体，输出更加符合预期。=   04 运营运维-观测 观测· 新增会话管理功能，支持查看Agent和工作流的会话历史。 业务价值：记录了智能体和工作流对话中的数据，可以更高效地管理和提升对话系统的性能。  · 增加租户指标统计。租户指标统计页面，提供当前租户下智能体应用和工作流方面的关键使用数据，包括TOP10单智能体/工作流的Tokens消耗、TOP10单智能体/工作流的总调用量等。业务价值：通过这些统计数据，您可以了解智能体和工作流的总数、新增数量、活跃情况以及资源消耗情况，帮助您优化资源分配，提高使用效率，并及时发现和解决问题。   05 Agent应用支持发布到云商店  应用管理· 将单智能体、工作流应用发布到云商店后，生成OpenAPI URL，用户可以在华为云云商店通过调用OpenAPI URL，即可将应用发布到云商店。业务价值：用户可以通过云商店发布上架次接口，支持将Agent在云商店上架交易。   06  单智能体应用能力拓展 应用管理· 单智能体在模型优先场景下，增加变量记忆功能，支持对用户变量进行设置。业务价值：用户变量可存储使用项目过程中需要持久化存储和读取的数据，如用户的语言偏好、个性化设置等，能让智能体提供更个性化回复，更好响应用户的消息，提升输出内容的上下文关联度和准确性。  · 调度模式支持工具优先功能。在处理用户的输入时，结合prompt，系统会优先判断用户添加的工具是否合适的，通过分析工具名称/描述/参数选择合适的工具来处理。业务价值：基于用户指令意图，准确映射到匹配的插件，提升问题处理的精确度。 适用于特定任务处理、高效任务执行、工具依赖性高的场景。  · 单智能体应用在添加插件、工作流、MCP等时支持无断点，可在构建过程中进行开通、创建等操作。业务价值：提升Agent创建全流程的流畅度，优化用户体验。   07  多智能体应用优化 应用管理· 多智能体应用创建过程中，与其关联的工作流、智能体可以修改意图识别。业务价值：增加修改子工作流意图识别的入口，提升多智能体应用的决策执行灵敏度。  08  数据能力 知识库· 知识文档支持上传Markdown和HTML格式的文档。业务价值：支持上传更多样的文档格式，提升文件解析能力，满足用户使用需求。  · 新增知识库从obs桶（Object Storage Service,OBS）中拉取知识文件。业务价值：通过对象存储服务（Object Storage Service,OBS）配置接入知识文档，实现快速调用，效率提升。  · 提供多知识库并行检索能力。知识库检索接口支持语义、关键词、混合及FAQ四种检索模式，并允许自定义相似度阈值与返回结果数量。业务价值1：丰富检索策略，实现更精准的知识调用。通过控制阈值，调节知识库与大模型之间的协作效能，实现精准高效的信息匹配。业务价值2：知识库节点增加“启用FAQ”按钮，默认状态下关闭，支持跳过FAQ查询环节，直接查询文档切片，满足个性化内容检索需求。  09  插件能力 组件库-我的插件· 支持创建函数类型插件。在函数编辑页面，可以创建并上传自定义依赖包，依赖包可包含自定义代码。业务价值：丰富插件创建方式，可实现代码复用，简化流程，以提高工具的灵活性和功能性。10 平台资源订购 平台管理-我的资源· Versatile智能体平台支持购买套餐包，购买后使用Versatile智能体平台的全量功能。业务价值：支持用户按需选购资源，包括免费版和商用版，升级商用版可便捷使用平台全量功能，满足业务需求。   点击可前往>>华为云Versatile智能体平台 官网

请查阅参考昇腾社区文档：https://gitee.com/ascend/MindSpeed-LLM/blob/2.1.0/docs/pytorch/solutions/inference/chat.md 

请查阅参考昇腾社区文档：https://gitee.com/ascend/MindSpeed-LLM/blob/2.1.0/docs/pytorch/solutions/inference/inference.md 

前段时间买房一直为找不到好的房源而头大，徒增三千烦恼丝。首先在预算范围内，周边交通便利，有优质学区房，离医疗条件配备齐全的医院距离又要适中的好房源到底哪里找？每天钻进各个平台上研究，耗费大把时间，而且信息繁多难以筛选。无意中发现了这个开发神器，不到几分钟就能按照提供的筛选条件推荐了好几个优质房源，不得不给大家安利一下！大家可以按照步骤试试：案例体验：基于华为云开发者空间-Versatile Agent开发平台零基础开发购房助手实操步骤：领取登录华为开发者空间，开通Versatile Agent；创建Versatile Agent应用；使用Versatile Agent开发平台的服务模型-平台预置功能配置MaaS；使用Versatile Agent的MCP服务，创建车票查询工具MCP；配置购房助手应用模型、提示词、知识库、开场白等，完成预览调试；发布Versatile Agent应用。按照以上步骤完成部署，输入你想要的房源条件，不出几秒就可以给你推荐合适的房源了，节省很多时间，分分钟和购房烦恼say goodbye！  

【话题交流】2025年已悄然步入尾声～这一年，大家有哪些悄然生长的收获？华为云的ModelArts Studio（MaaS）让我们更好的调用deepseek等大模型；对象存储，让海量数据存得下、管得好、用得快。

邀请数据公示信息如下：1、符合条件的邀请人数公示见本论坛贴附件1，PC端下载后查看！2、完成指定任意1门课程学习或实验进度100%，抽奖公示查看附件2，3、开发者空间案例抽奖查看附件3【公示时间】：2025年12月18日—2025年12月22日（含），若有疑问请在该时间段反馈，逾期视为放弃奖励！【奖品发放】：所有奖励将于活动公示期后陆续安排发放，请耐心等待！  【活动时间】2025年 11月 20日 - 2025年 12月 17日活动报名链接：cid:link_8【活动福利】福利1、邀请新用户注册华为云+领取开发者空间+完成指定任意1项学习或实验进度100%，最高可领6000元云资源券（可购买、续费云服务）。邀请新用户+领取开发者空间+指定任意学习或实验奖品2选1（云资源券与实物礼品2选1）云资源券金额实物礼品4人120元/8人240元HC鼠标垫（限50）15人450元开发者定制水杯（限10）20人600元开发者空间定制冲锋衣（颜色/尺码随机）（限10）40人1200元开发者空间定制双肩包（限10）60人1800元罗技MK20键鼠套装（限5）80人2400元开发者空间定制冲锋衣+开发者定制水杯（限5）100人3000元开发者空间定制双肩包+开发者定制水杯（限5）150人4500元开发者空间定制冲锋衣+开发者空间定制双肩包（限5）200人6000元HUAWEI FreeClip  星空黑（限3）  福利2、完成指定任意1项课程学习或实验进度100%可参与抽奖，抽开发者定制双肩包、水杯、数据收纳包、100元云资源券。课程列表（含报名入口）实验列表（含实验入口）DeepSeek大模型服务API发布与调用使用MindSpore开发训练模型识别手写数字基于DeepSeek搭建Agent智能助手基于ECS制作模型镜像在ModelArts训练模型DeepSeek + AI编程助手Cline自动化游戏开发基于鲲鹏架构的飞机大战游戏开发MCP协议基础与MCP Server服务实践部署Python电商项目MCP协议高级应用与AI助手协同理论/ 福利3、完成指定任意1项开发者空间案例可参与抽奖，抽华为云定制键盘、开发者空间定制长袖卫衣、华为智能体脂秤3、华为FreeLace 活力版耳机。（1） 点此免费领取华为开发者空间，然后完成下方任意1项案例实践后，在论坛贴评论区发布：案例名称+完成案例实践截图+心得，再抽奖→（点此抽奖）。抽华为FreeLace 活力版耳机、华为云定制键盘、开发者空间定制长袖卫衣、华为智能体脂秤等好礼。开发者空间案例（含实操入口）基于开发者空间-Versatile Agent构建内容审核工作流智能应用基于华为开发者空间-Versatile Agent开发平台构建旅游规划助手基于华为云开发者空间-Versatile Agent开发平台零基础开发购房助手基于华为开发者空间-Versatile Agent预置MCP资产快速构建智能体基于华为开发者空间-云开发环境（容器）+MaaS实现智语灵犀-AI对话助手基于华为开发者空间-云开发环境（容器）+MaaS大模型构建智能写作助手应用基于华为开发者空间开发平台-云开发环境（容器），完成贪吃蛇小游戏开发华为开发者空间-云开发环境（虚拟机）IDE插件远程连接操作指导  点击前往活动页，可查看详细福利。

案例体验《云主机调用DeepSeek实现代码自动生成》在云主机上调用ModelArts Studio预置的DeepSeek V3模型API实现代码自动生成，跟着步骤一步步做，简单有趣，很快就帮我自动生成一款带图形画界面的双人乒乓球对战游戏啦，重点还是免费体验的，快都来试！步骤很简单！已经总结在下面啦① 开发者空间领取免费云主机，配置开发环境（免费的！！！）② 安装大模型应用开发框架AutoGen③ CodeArts IDE运行DeepSeek V3 API调用程序④ 调用ModelArts Studio预置DeepSeek V3模型（还是免费的！！！）⑤ 返回生成的代码免费DeepSeek V3模型领取路径，偷偷告诉你！戳这里直接领代金券——购买DeepSeek V3模型——选用领取的代金券即可抵扣眼见为实，快看我生成的游戏截图！↓↓  

一文走进IPv4和IPv6cid:link_7 IPv6和Ipv4笔记分享cid:link_8 防火墙HRP笔记分享cid:link_9 openEuler 国产化替代：平衡生态兼容与自主创新cid:link_10 openGauss 全密态数据库：计算过程隐私保护技术解析cid:link_11 常见的ONU与IP静态绑定配置分享cid:link_12 无 GPS 环境米级定位方案分享：大型仓库物资追踪解决方案cid:link_0 户外气象站全面防雷保护方案：从器件选型到接地系统cid:link_13 物联网设备并发上线抗雪崩方案：从协议优化到架构升级cid:link_14 边缘 AI 部署中的典型挑战cid:link_15 物联网设备深度休眠下的 "瞬时唤醒" 方案cid:link_16 边缘设备与云平台业务不中断保障cid:link_17 NB-IoT 设备电池寿命精准估算与功耗优化全方案cid:link_18 多品牌智能家居设备互联互通全方案cid:link_1 工业温湿度传感器数据滤波全方案：从硬件到算法的精准降噪cid:link_19 农业传感器防伪造：低成本设备身份认证全方案cid:link_2 低功耗边缘 AI 芯片选型指南：电池供电设备的实时异常检测方案cid:link_20 物联网设备OTA升级设计cid:link_3 LoRa 模块 (SX1278) 传输距离不足：实战排查与距离提升方案cid:link_4 智能家居协议实测：MQTT vs CoAP 真实体验与选型指南cid:link_5 一文带你走进autovacuumcid:link_21 Docker数据丢失核心原因及解决方法cid:link_6 

请查阅参考昇腾社区文档：https://gitee.com/ascend/MindSpeed-LLM/blob/2.1.0/docs/pytorch/solutions/finetune/qlora_finetune.md 

各位华为云社区的技术同行们，大家好！初冬寒意渐浓，但技术学习的热情从未降温～ 转眼间 2025 年 11 月已近尾声，在华为云这个汇聚根技术生态的平台上，想必大家都收获了满满的新知识与实战经验。或许是昇腾 AI 的最新适配技巧，是仓颉编程的高效开发方法，是鸿蒙端云协同的创新实践，又或是 MCP 协议、DeepSeek 大模型的落地应用心得？技术的成长从不止步于独自探索，每一份知识分享都能碰撞出创新火花，每一次经验交流都能助力共同成长。现在就来畅所欲言，聊聊这个 11 月你解锁的新技能、吃透的新技术，让我们在交流中互学互鉴，让知识在分享中持续增值！

 数据丢失的核心原因是 数据卷挂载配置错误（路径不对、权限不足、挂载类型误用），Docker 环境下 PostgreSQL 的数据持久化完全依赖正确的卷挂载 ——PostgreSQL 容器的默认数据存储目录是 /var/lib/postgresql/data，如果挂载时路径不匹配、宿主机目录无写入权限，数据会默认存到容器的 “临时存储层”，容器重启后就会丢失。一、先排查：你的数据卷挂载到底错在哪？1. 最常见错误：挂载路径不匹配（没对准容器内默认数据目录）PostgreSQL 容器的 数据必须存储在 /var/lib/postgresql/data 目录下（这是官方镜像的固定路径，改不了）。如果你的启动命令里挂载路径写错了（比如多写一层目录、少写路径），数据根本没写到宿主机卷里。常见小错误（路径错误）： # 错误1：挂载到 /var/lib/postgresql（少了 /data 后缀）docker run -d -v pgdata:/var/lib/postgresql postgres:15# 错误2：自定义容器内路径（比如 /data），但PostgreSQL不往这写docker run -d -v /宿主机路径:/data postgres:15# 错误3：绑定挂载时宿主机路径拼写错误（比如 /home/user/pgdata 写成 /home/user/pgdat）docker run -d -v /home/user/pgdat:/var/lib/postgresql/data postgres:15 正确示例（路径必须对准 /var/lib/postgresql/data）： # 命名卷（推荐，Docker自动管理路径和权限）docker run -d -v pgdata:/var/lib/postgresql/data postgres:15# 绑定挂载（宿主机路径自定义，需确保权限）docker run -d -v /home/user/pgdata:/var/lib/postgresql/data postgres:15 2. 第二常见：宿主机目录权限不足（容器内用户写不进去）PostgreSQL 容器内默认使用 postgres 用户（UID=999，GID=999）运行，如果是 绑定挂载（直接挂载宿主机目录），宿主机目录的属主 / 权限不对，postgres 用户无法写入数据，会自动降级为 “临时存储”（重启丢失）。错误场景：宿主机创建了 /home/user/pgdata 目录，但默认属主是 root，权限是 755（只有 root 能写），容器内 postgres 用户没权限写入，只能用临时存储。修复方法（绑定挂载时）：  # 1. 先给宿主机目录设置正确权限（让 UID=999 能写入）sudo chown -R 999:999 /home/user/pgdatasudo chmod -R 700 /home/user/pgdata # PostgreSQL要求数据目录权限为700（仅所有者可读写）# 2. 再启动容器（路径正确+权限正确）docker run -d -v /home/user/pgdata:/var/lib/postgresql/data postgres:15 3. 其他的小错误：误用 “匿名卷” 或 “临时存储”匿名卷：启动命令里只写 -v /var/lib/postgresql/data（没指定宿主机路径或卷名），Docker 会创建随机命名的匿名卷，容器删除后匿名卷可能被清理（重启容器不删，但手动删容器时容易丢）；临时存储：如果启动时没加任何 -v 挂载，数据直接存在容器的 “可写层”，容器重启 / 重建后 100% 丢失。二、Docker 部署 PostgreSQL 的正确流程（确保数据不丢）推荐用 命名卷（Docker 自动管理路径、权限，避免手动配置错误）1. 提前创建命名卷（也可启动时自动创建） # 创建名为 pgdata 的命名卷（Docker会把数据存在 /var/lib/docker/volumes/pgdata 下）docker volume create pgdata 2. 启动容器（核心：正确的去挂载卷 + 设置必要环境变量）docker run -d \ --name postgres-db \ -p 5432:5432 \ # 端口映射（宿主机:容器） -v pgdata:/var/lib/postgresql/data \ # 命名卷挂载（关键） -e POSTGRES_USER=myuser \ # 自定义数据库用户（避免用默认postgres） -e POSTGRES_PASSWORD=mypassword \ # 自定义密码（必须设置，否则容器启动失败） -e POSTGRES_DB=mydb \ # 初始化时创建的数据库（可选） -e PGDATA=/var/lib/postgresql/data/pgdata \ # 可选：指定数据子目录（避免和配置文件混放） --restart=always \ # 容器异常退出时自动重启 postgres:15 # 指定具体版本（不要用latest，避免版本迭代问题） 3. 验证数据持久化（确保重启后不丢） # 1. 进入容器，创建测试数据docker exec -it postgres-db psql -U myuser -d mydb# 执行SQL创建表并插入数据CREATE TABLE test (id int);INSERT INTO test VALUES (1);SELECT * FROM test; # 确认能查到数据，退出容器（ctrl+d）# 2. 重启容器docker restart postgres-db# 3. 再次进入容器，验证数据是否存在docker exec -it postgres-db psql -U myuser -d mydbSELECT * FROM test; # 能查到 (1) 说明持久化成功 三、Docker 环境使用 PostgreSQL 的关键注意事项1. 数据卷相关（重中之重）优先用 命名卷：避免绑定挂载的权限、路径问题，Docker 会自动维护卷的生命周期（容器删除后卷不会删，数据保留）；绑定挂载需注意：宿主机目录必须提前创建并设置 999:999 属主（容器内 postgres 用户的 UID/GID），权限设为 700（PostgreSQL 安全要求，禁止其他用户访问数据目录）；不要修改容器内默认数据目录：官方镜像的 /var/lib/postgresql/data 是固定路径，修改 PGDATA 环境变量时需确保挂载路径同步（比如 PGDATA=/var/lib/postgresql/data/pgdata，挂载路径仍为 /var/lib/postgresql/data）。2. 配置与权限必须设置密码：PostgreSQL 官方镜像从 10 版本后，必须通过 POSTGRES_PASSWORD 环境变量设置密码，否则容器启动失败；避免硬编码密码：生产环境不要直接在命令行写密码，可用 --env-file 加载环境变量文件（比如 docker run --env-file .env ...，.env 文件里写 POSTGRES_PASSWORD=mypassword）；挂载配置文件：如果需要修改 postgresql.conf（比如调整内存、连接数），可将宿主机的配置文件挂载到 /var/lib/postgresql/data/postgresql.conf（命名卷中会自动生成默认配置，可先拷贝出来修改再挂载）： # 先拷贝容器内默认配置到宿主机docker cp postgres-db:/var/lib/postgresql/data/postgresql.conf /home/user/pgconf/# 修改后重新挂载配置文件docker run -d -v pgdata:/var/lib/postgresql/data -v /home/user/pgconf/postgresql.conf:/var/lib/postgresql/data/postgresql.conf ...  3. 容器管理禁止用 docker rm -v 删除容器：-v 参数会同时删除挂载的卷（包括命名卷），导致数据丢失；定期备份数据卷：即使挂载了卷，也要定期备份（比如用 docker run --rm -v pgdata:/source -v /宿主机备份路径:/dest alpine tar -czf /dest/pgbackup.tar.gz -C /source .）；指定具体镜像版本：不要用 postgres:latest，避免容器重建时自动升级版本（可能出现兼容性问题），比如固定 postgres:15.6。4. 网络与端口避免暴露 5432 端口到公网：默认 -p 5432:5432 会把端口暴露到公网，容易被暴力破解，生产环境可改为内网访问（比如 -p 127.0.0.1:5432:5432，仅允许宿主机访问），或用 Docker 自定义网络隔离；容器间通信：如果其他容器需要访问 PostgreSQL，建议创建 Docker 网络（docker network create pg-network），启动时加入网络（--network pg-network），通过容器名（比如 postgres-db）访问，无需暴露端口。5. 资源限制限制 CPU / 内存：避免 PostgreSQL 容器占用过多宿主机资源，可通过 --cpus 和 --memory 限制（比如 --cpus 2 --memory 4g，限制 2 核 CPU、4G 内存）；磁盘空间监控：命名卷默认存在 /var/lib/docker/volumes/ 下，需监控宿主机磁盘空间，避免数据量增长导致磁盘满。四、如果数据已经丢失，怎么去救救数据呢？如果容器还没删除，可尝试从容器的 “临时存储层” 抢救数据： # 1. 查看容器是否还存在（即使已停止）docker ps -a | grep postgres-db# 2. 用新容器挂载原容器的存储层，拷贝数据docker run --rm -v /宿主机临时路径:/backup alpine \ cp -r /var/lib/docker/containers/[原容器ID]/mounts/secrets/ /backup/# （注：如果原容器已删除，临时存储层会被清理，无法恢复，只能依赖之前的备份） 总结一下下数据丢失的核心是 挂载路径不对 或 权限不足，记住：PostgreSQL 容器必须挂载 /var/lib/postgresql/data 目录；推荐用 命名卷 部署，避免手动配置权限和路径的麻烦；生产环境务必做好 定期备份 和 权限隔离，不要暴露端口到公网，指定固定镜像版本。

一、autovacuum 是干什么的？—— PostgreSQL 的 “自动清洁工 + 优化师”PostgreSQL 基于 MVCC（多版本并发控制） 机制工作，这个机制会导致两个关键问题，而 autovacuum 就是专门解决这两个问题的后台进程：1. 核心功能 1：清理 “死元组”（垃圾数据）当你执行 DELETE 或 UPDATE 时，PostgreSQL 不会直接删除旧数据：DELETE：只是给旧数据打个 “已删除” 标记（变成 “死元组”）；UPDATE：本质是 “删除旧行 + 插入新行”，同样会产生死元组。这些死元组会占据磁盘空间，还会让查询时扫描更多无效数据，导致表变大、查询变慢。autovacuum 会自动扫描表，清理这些死元组，释放磁盘空间，让查询更高效。2. 核心功能 2：更新统计信息PostgreSQL 的查询优化器（ Planner ）需要依赖 “表数据统计信息”（比如某列有多少不同值、数据分布）来生成最优执行计划。如果统计信息过时，优化器可能会选低效的执行计划（比如明明该走索引却全表扫描），导致查询变慢。autovacuum 会定期更新这些统计信息，确保优化器决策准确。3. 核心功能 3：防止事务 ID 回卷（致命风险）PostgreSQL 中每个事务都有一个唯一的事务 ID（XID），XID 是 32 位整数，会循环使用。如果长期不运行 autovacuum，旧事务的 XID 会被 “冻结”，一旦 XID 循环到临界值，数据库会直接进入只读模式（甚至不可用），这就是 “事务 ID 回卷”，修复成本极高。二、能不能直接关掉？—— 绝对不建议哦！直接关闭 autovacuum 会导致三个致命问题：死元组堆积：表体积暴增，查询、备份、恢复速度越来越慢；统计信息过时：查询执行计划变差，业务 SQL 可能从毫秒级变成秒级 / 分钟级；事务 ID 回卷风险：数据库最终会只读或崩溃，影响业务连续性。例外情况：仅当你有严格的手动维护流程（比如每天凌晨手动执行 VACUUM ANALYZE），且能确保覆盖所有表，才可能考虑关闭 —— 但实际生产中几乎没人这么做（手动维护容易遗漏大表 / 热点表）。三、核心解决方案：调整 autovacuum，避开夜间高峰期你的问题本质是 autovacuum 在半夜 12 点（可能是业务低峰期，但数据库仍有压力）集中运行，导致资源占用过高。解决方案是：让 autovacuum 在更空闲的时段运行，或分散运行，降低单轮资源消耗。调整思路分 3 类，优先从简单的来：1. 第一步：调整 autovacuum 运行时段（避开 12 点）PostgreSQL 12+ 版本支持通过 autovacuum_naptime 和 autovacuum_vacuum_cost_delay 控制运行频率，或通过 pg_cron 插件指定固定时段运行（推荐）。方法 1：修改全局参数（适用于所有表）编辑 PostgreSQL 配置文件 postgresql.conf（路径通常在 $PGDATA/postgresql.conf），调整以下参数：  # 1. 控制 autovacuum 进程的唤醒间隔（默认1分钟，可缩小让它更频繁但轻量化）autovacuum_naptime = 30s # 每30秒唤醒一次，分散清理压力（默认1min）# 2. 降低 autovacuum 的资源消耗（避免单轮清理占用过多CPU/IO）autovacuum_vacuum_cost_delay = 20ms # 每消耗一定“成本”就暂停20ms（默认0，不暂停）autovacuum_vacuum_cost_limit = 100 # 单次清理的“成本上限”（默认-1，继承全局vacuum_cost_limit）# 3. 避开12点高峰期：让 autovacuum 主要在凌晨3-6点运行（需配合 pg_cron）# 先启用 pg_cron 插件（需提前安装，多数云数据库已预装）shared_preload_libraries = 'pg_cron' # 新增或添加到现有列表cron.database_name = '你的数据库名' # 指定 pg_cron 生效的数据库# 然后在数据库中执行SQL，禁用默认自动触发，改为定时执行-- 1. 全局禁用自动 autovacuum（仅禁用触发，保留进程）ALTER SYSTEM SET autovacuum = off;-- 2. 用 pg_cron 定时在凌晨3点执行全库 vacuum analyze（低峰期）SELECT cron.schedule('daily-autovacuum', '0 3 * * *', 'VACUUM ANALYZE;');-- 3. 可选：对大表单独定时（比如凌晨4点清理大表）SELECT cron.schedule('vacuum-big-table', '0 4 * * *', 'VACUUM ANALYZE public.你的大表名;'); 方法 2：针对单个大表调整（如果是某张大表导致的慢）如果日志显示是某张大表（比如千万级 / 亿级数据的表）在 12 点触发 autovacuum，可以单独给这张表设置参数，让它在其他时段清理：  -- 给大表设置：降低触发阈值（更早清理，避免堆积后单次消耗过大）+ 调整运行时段ALTER TABLE public.你的大表名 SET ( autovacuum_vacuum_threshold = 5000, -- 死元组达到5000就触发（默认50） autovacuum_vacuum_scale_factor = 0.05, -- 死元组占比达到5%也触发（默认20%） autovacuum_vacuum_cost_delay = 50ms -- 单表清理时更慢，减少资源占用); 2. 第二步：限制 autovacuum 的资源占用（避免拖慢数据库）如果 autovacuum 运行时占用过多 CPU/IO，导致业务 SQL 变慢，可以通过以下参数限制资源：  # postgresql.conf 中调整vacuum_cost_page_hit = 1 # 内存中命中数据页的“成本”（默认1）vacuum_cost_page_miss = 10 # 磁盘中读取数据页的“成本”（默认10）vacuum_cost_page_dirty = 20 # 修改脏数据页的“成本”（默认20）autovacuum_vacuum_cost_limit = 50 # 单次清理的最大“成本”（默认-1，继承全局） 核心的逻辑：autovacuum 每清理一页数据会累积 “成本”，达到 cost_limit 后，就会暂停 cost_delay 时间，避免持续占用资源。小建议：IO 压力大的场景，可增大 cost_delay（比如 50ms），减小 cost_limit（比如 50），让清理更 “温和”。3. 第三步：排查是否有其他任务冲突（比如备份）半夜 12 点可能同时运行其他耗资源任务（比如数据库备份、ETL 同步），和 autovacuum 争夺 CPU/IO，导致变慢。可以：查看日志，确认 12 点是否有备份 / ETL 任务，将其调整到其他时段（比如凌晨 2 点）；如果必须同时运行，降低备份的 IO 优先级（比如 PostgreSQL 备份用 pg_dump -F c -j 2 限制并发，避免全量备份占满 IO）。四、验证调整效果调整后，需要确认 autovacuum 是否在目标时段运行，且不再导致数据库变慢：查看 autovacuum 运行状态： -- 查看当前正在运行的 autovacuum 进程SELECT pid, query, state, now() - query_start AS duration FROM pg_stat_activity WHERE query LIKE '%autovacuum%' AND state = 'active';-- 查看各表的 autovacuum 统计（比如死元组数量、最后清理时间）SELECT relname AS 表名, n_dead_tup AS 死元组数量, last_vacuum AS 最后手动清理时间, last_autovacuum AS 最后自动清理时间, autovacuum_count AS 自动清理次数FROM pg_stat_user_tables ORDER BY n_dead_tup DESC; 观察数据库负载：调整后半夜 12 点的 CPU/IO 使用率、查询响应时间是否恢复正常。总结一下下autovacuum 是 PostgreSQL 的 “必需进程”，负责清理垃圾、更新统计、防止事务 ID 回卷，不能直接关掉；夜间变慢的核心是 autovacuum 与业务 / 其他任务争夺资源，优先通过 pg_cron 调整运行时段（比如凌晨 3-6 点）；辅助调整资源限制（cost_delay/cost_limit）和表级触发阈值，让清理更分散、更温和；若调整后仍慢，排查是否有备份 / ETL 等任务冲突，或优化大表结构（比如分区表）。

请查阅参考昇腾社区文档：https://gitee.com/ascend/MindSpeed-LLM/blob/2.1.0/docs/pytorch/solutions/finetune/lora_finetune.md