Java卷不动了？我靠这套“人大金仓降维打击路线图”，在信创风口拿到了年薪80W的架构师Offer！

“能用KB特性降维打击业务痛点”的信创架构师。

✅ 认知破局：Java学KB的4个致命误区
✅ 四阶路线图：从青铜到王者的打怪升级指南
✅ 核心实战：MyBatis多数据源方言路由引擎（附保姆级源码）
✅ 深度定制：KB神级特性 JSONB 的Java端完美封装
✅ 3个让P7翻车的血泪案例

💀 第一章：认知破局——Java学KB的4个致命误区

在开始路线图之前，必须先洗脑。很多Java开发学KB，一开始方向就错了。

误区1：“把它当MySQL学”
错！ KB的内核是PostgreSQL（PG）。
MySQL是“怎么方便怎么来”（隐式转换、松散的锁），而PG/KB是“严谨的学院派”（强类型、严格的MVCC、复杂的优化器）。
用MySQL的思维写KB的SQL，就像用开自动挡的习惯去开手动挡，迟早熄火。

误区2：“只学SQL语法，不学底层原理”
错！ 会写 SELECT 只是青铜。
你必须懂KB的 MVCC（多版本并发控制），否则你不知道为什么 UPDATE 多了系统会卡死；
你必须懂 执行计划（EXPLAIN），否则你不知道为什么加了索引反而更慢。

误区3：“那是DBA的事，我只管写Java”
错！ 在信创项目里，DBA通常只懂运维，不懂Java生态（MyBatis、Hibernate、连接池）。
当JDBC驱动和KB内核发生“化学反应”时，只有懂DB底层的Java开发才能排查！ 这就是你的核心竞争力。

误区4：“KB完全兼容PG，直接看PG文档就行”
错！ KB在PG基础上做了大量信创魔改：
增加了MySQL/Oracle兼容模式（db_compatibility）
增加了国密SM2/SM3/SM4加密函数
修改了部分系统表结构和安全认证流程
PG文档是基础，但KB的官方Release Notes才是“避坑圣经”。

🗺️ 第二章：四阶学习路线图（从青铜到王者）

graph LR
subgraph “🥉 青铜：基础生存 (1-2周)”
B1[环境搭建与连接]
B2[SQL方言差异]
B3[JDBC驱动避坑]
B4[MyBatis基础适配]
end

subgraph "🥈 白银：性能调优 (1个月)" S1[EXPLAIN 执行计划] S2[索引原理(B-Tree/GiST/GIN)] S3[事务隔离与MVCC] S4[VACUUM与表膨胀] end subgraph "🥇 黄金：架构设计 (2-3个月)" G1[高可用KHA架构] G2[读写分离与分库分表] G3[JSONB/Array高级特性] G4[多数据源方言路由] end subgraph "👑 王者：内核与生态 (半年+)" K1[PL/Java/PL/Python扩展] K2[自定义C扩展/Hook] K3[信创全栈调优(Kylin+Kunpeng)] K4[数据迁移与回滚架构] end B1 --> S1 --> G1 --> K1 style B1 fill:#868e96,color:#fff style S1 fill:#51cf66,color:#fff style G1 fill:#fcc419,color:#333 style K1 fill:#e03131,color:#fff

🥉 阶段一：青铜（基础生存）—— 别让它报错
目标：让Java应用连上KB，跑通CRUD，不报语法错误。
核心动作：
本地用Docker跑一个KB实例（或申请测试环境）。
熟记KB与MySQL的20个核心语法差异（如：反引号 vs 双引号，IFNULL vs COALESCE，AUTO_INCREMENT vs SERIAL）。
掌握KB JDBC URL的核心伪装参数（stringtype=unspecified 等）。

🥈 阶段二：白银（性能调优）—— 别让它卡死
目标：写出高性能SQL，能排查慢查询，理解KB的“脾气”。
核心动作：
死磕 EXPLAIN ANALYZE，看懂 Seq Scan、Index Scan、Hash Join、Nested Loop。
理解KB的 MVCC 机制：为什么 UPDATE 会产生死元组（Dead Tuples）？为什么需要 autovacuum？
掌握KB特有的索引：除了B-Tree，还要懂 GIN索引（查JSONB和全文检索的利器）和 BRIN索引（时序数据神器）。

🥇 阶段三：黄金（架构设计）—— 让它发挥神力
目标：利用KB的高级特性重构业务代码，降维打击MySQL做不到的痛点。
核心动作：
JSONB 深度应用：用JSONB替代传统的EAV（实体-属性-值）表设计，实现动态表单。
Array 数组类型：用数组替代关联表，解决“标签”、“权限”等多对多关系的性能瓶颈。
UPSERT 优雅处理：掌握 INSERT … ON CONFLICT DO UPDATE，干掉应用层的“先查后插”逻辑。
多数据源兼容：设计一套架构，让同一套Java代码无缝兼容MySQL和KB。

👑 阶段四：王者（内核与生态）—— 成为信创专家
目标：突破Java边界，深入数据库内核，解决信创环境下的极端问题。
核心动作：
学习 PL/pgSQL / PL/Java，把复杂的业务逻辑下沉到数据库层（存储过程/触发器）。
了解 KB 的 KHA（高可用） 架构，懂主从同步延迟的排查。
研究 鲲鹏CPU + 麒麟OS + KB 的全栈性能调优（如：NUMA架构对KB共享内存的影响）。

💻 第三章：核心实战——Java端的“信创方言路由引擎”

在真实的信创项目中，最恶心的情况是：“双轨运行”。
也就是：系统要同时支持 MySQL（老客户）和 人大金仓（信创客户）。

你不可能写两套代码！
我们需要在 Java 端设计一个 “方言路由引擎”，在运行时根据数据源类型，动态改写 SQL。

3.1 架构设计：MyBatis 拦截器 + 策略模式

graph TD
A[Java 业务代码] -->|发送标准SQL| B(MyBatis Mapper)
B --> C{DialectRouterInterceptor}
C -->|判断当前DataSource| D[MySQLDialectStrategy]
C -->|判断当前DataSource| E[KingbaseDialectStrategy]
D -->|生成MySQL SQL| F[(MySQL 8.0)]
E -->|生成KB SQL| G[(KingbaseES V8R6)]

3.2 核心代码：方言路由拦截器

// ============================================================
// 📌 文件：DialectRouterInterceptor.java
// 📌 用途：MyBatis拦截器，根据当前数据源动态路由SQL方言
// 📌 设计思想：
// 1. 拦截 Executor 的 query 和 update 方法
// 2. 通过 ThreadLocal 获取当前使用的 DataSource 类型
// 3. 调用对应的 DialectStrategy 改写 SQL
// 4. 性能优化：使用 Caffeine 缓存改写后的 SQL，避免重复解析
// ============================================================

import com.github.benmanes.caffeine.cache.Cache;
import com.github.benmanes.caffeine.cache.Caffeine;
import org.apache.ibatis.executor.Executor;
import org.apache.ibatis.mapping.BoundSql;
import org.apache.ibatis.mapping.MappedStatement;
import org.apache.ibatis.plugin.*;
import org.apache.ibatis.session.ResultHandler;
import org.apache.ibatis.session.RowBounds;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.stereotype.Component;

import java.lang.reflect.Field;
import java.util.Properties;
import java.util.concurrent.TimeUnit;

@Component
@Intercepts({
@Signature(type = Executor.class, method = “update”, args = {MappedStatement.class, Object.class}),
@Signature(type = Executor.class, method = “query”, args = {MappedStatement.class, Object.class, RowBounds.class, ResultHandler.class})
})
public class DialectRouterInterceptor implements Interceptor {

private static final Logger log = LoggerFactory.getLogger(DialectRouterInterceptor.class); // 💡 策略工厂：根据数据源类型获取对应的方言策略 private final DialectStrategyFactory strategyFactory; // 💡 性能优化：缓存改写后的SQL // Key: "MapperId + 原始SQL + 数据源类型", Value: "改写后的SQL" // 设置最大10000条，5分钟过期（防止内存泄漏） private final Cache<String, String> sqlCache = Caffeine.newBuilder() .maximumSize(10000) .expireAfterWrite(5, TimeUnit.MINUTES) .build(); public DialectRouterInterceptor(DialectStrategyFactory strategyFactory) { this.strategyFactory = strategyFactory; } @Override public Object intercept(Invocation invocation) throws Throwable { MappedStatement ms = (MappedStatement) invocation.getArgs()[0]; Object parameter = invocation.getArgs()[1]; BoundSql boundSql = ms.getBoundSql(parameter); String originalSql = boundSql.getSql().replaceAll("[\s]+", " ").trim(); // 1️⃣ 获取当前线程使用的数据源类型（由 DynamicDataSource 设置到 ThreadLocal） String dsType = DataSourceContextHolder.getDataSourceType(); if (dsType == null) { dsType = "mysql"; // 默认兜底 } // 2️⃣ 检查缓存 String cacheKey = ms.getId() + "|" + originalSql + "|" + dsType; String finalSql = sqlCache.getIfPresent(cacheKey); if (finalSql == null) { // 3️⃣ 缓存未命中，执行方言改写 DialectStrategy strategy = strategyFactory.getStrategy(dsType); finalSql = strategy.rewriteSql(originalSql, ms, parameter); // 放入缓存 sqlCache.put(cacheKey, finalSql); if (!originalSql.equals(finalSql)) { log.debug("🔄 SQL方言改写 [{}]: n原: {}n新: {}", dsType, originalSql, finalSql); } } // 4️⃣ 反射替换 BoundSql 中的 SQL if (!finalSql.equals(originalSql)) { Field sqlField = BoundSql.class.getDeclaredField("sql"); sqlField.setAccessible(true); sqlField.set(boundSql, finalSql); } // 5️⃣ 继续执行 MyBatis 流程 return invocation.proceed(); } @Override public Object plugin(Object target) { return Plugin.wrap(target, this); } @Override public void setProperties(Properties properties) {}

}

3.3 核心代码：人大金仓方言策略实现

// ============================================================
// 📌 文件：KingbaseDialectStrategy.java
// 📌 用途：专门针对 KingbaseES 的 SQL 改写策略
// 📌 设计思想：
// 1. 处理 MySQL 特有语法（如 IFNULL, DATE_FORMAT）
// 2. 处理 Upsert 语法转换
// 3. 处理分页语法差异（虽然KB兼容模式支持LIMIT，但标准写法更稳）
// ============================================================

import org.apache.ibatis.mapping.MappedStatement;
import org.springframework.stereotype.Component;

import java.util.regex.Matcher;
import java.util.regex.Pattern;

@Component
public class KingbaseDialectStrategy implements DialectStrategy {

// 📌 正则：匹配 IFNULL(a, b) private static final Pattern IFNULL_PATTERN = Pattern.compile( "(?i)IFNULL\\s(?)\s,\(.?)\s*" ); // 📌 正则：匹配 DATE_FORMAT(date, '%Y-%m-%d') // 💡 KB 使用 TO_CHAR(date, 'YYYY-MM-DD') private static final Pattern DATE_FORMAT_PATTERN = Pattern.compile( "(?i)DATE_FORMAT\\s(?)\s,\'%(.?)'\s*" ); @Override public String rewriteSql(String originalSql, MappedStatement ms, Object parameter) { String rewritten = originalSql; // 1️⃣ 改写 IFNULL -> COALESCE (KB/PG 标准函数) Matcher ifnullMatcher = IFNULL_PATTERN.matcher(rewritten); if (ifnullMatcher.find()) { // 💡 使用 StringBuffer 和 appendReplacement 处理多次匹配 StringBuffer sb = new StringBuffer(); while (ifnullMatcher.find()) { String arg1 = ifnullMatcher.group(1); String arg2 = ifnullMatcher.group(2); ifnullMatcher.appendReplacement(sb, "COALESCE(" + arg1 + ", " + arg2 + ")"); } ifnullMatcher.appendTail(sb); rewritten = sb.toString(); } // 2️⃣ 改写 DATE_FORMAT -> TO_CHAR Matcher dateFormatMatcher = DATE_FORMAT_PATTERN.matcher(rewritten); if (dateFormatMatcher.find()) { StringBuffer sb = new StringBuffer(); while (dateFormatMatcher.find()) { String dateCol = dateFormatMatcher.group(1); String mysqlFormat = dateFormatMatcher.group(2); // 💡 格式符转换：MySQL的 %Y-%m-%d -> PG的 YYYY-MM-DD String pgFormat = convertDateFormat(mysqlFormat); dateFormatMatcher.appendReplacement(sb, "TO_CHAR(" + dateCol + ", '" + pgFormat + "')"); } dateFormatMatcher.appendTail(sb); rewritten = sb.toString(); } // 3️⃣ 处理 UPSERT (ON DUPLICATE KEY UPDATE -> ON CONFLICT) // 💡 这里简化处理，实际生产中建议结合 3.3 节的反射机制或元数据缓存获取主键 if (rewritten.toUpperCase().contains("ON DUPLICATE KEY UPDATE")) { rewritten = rewriteUpsert(rewritten, ms); } return rewritten; } /** 💡 MySQL 日期格式符 -> PG/KB 日期格式符 */ private String convertDateFormat(String mysqlFormat) { return mysqlFormat .replace("%Y", "YYYY") .replace("%m", "MM") .replace("%d", "DD") .replace("%H", "HH24") .replace("%i", "MI") .replace("%s", "SS"); } /** 💡 改写 Upsert 语法 ⚠️ 注意：KB 的 ON CONFLICT 必须指定冲突列（通常是主键） 这里假设 Mapper ID 中包含了表名信息，或者通过元数据缓存获取 */ private String rewriteUpsert(String sql, MappedStatement ms) { // 简化的正则提取 Pattern upsertPattern = Pattern.compile( "(?i)(INSERT\s+INTO\s+?VALUES\s?)\s+ON\s+DUPLICATE\s+KEY\s+UPDATE\s+(.)", Pattern.DOTALL ); Matcher matcher = upsertPattern.matcher(sql); if (matcher.find()) { String insertPart = matcher.group(1); String updatePart = matcher.group(2); // 将 VALUES(col) 替换为 EXCLUDED.col String kbUpdatePart = updatePart.replaceAll("(?i)VALUES\\s(\w+)\s*", "EXCLUDED.$1"); // 💡 假设主键是 id（生产环境必须动态获取！） String conflictColumn = "id"; return String.format("%s ON CONFLICT (%s) DO UPDATE SET %s", insertPart, conflictColumn, kbUpdatePart); } return sql; }

}

💡 架构师视角：这套路由引擎的价值在于 “业务代码无感”。Java 开发依然可以写 MySQL 方言（照顾老项目），但在信创环境部署时，拦截器会自动将其翻译为 KB 方言。这就是“防腐层”设计的魅力。

🔥 第四章：深度定制——榨干 KB 的神级特性 JSONB

很多 Java 开发把 KB 当 MySQL 用，暴殄天物！
KB（继承自 PG）最强大的特性之一是 JSONB（二进制 JSON）。

场景：电商系统的“商品扩展属性”（如：手机有屏幕尺寸，衣服有尺码）。
MySQL 做法：建一张 EAV 表（product_id, attr_key, attr_value），查询时疯狂 JOIN，性能极差。
KB 做法：直接在商品表加一个 ext_attrs JSONB 字段，用 GIN 索引，查询速度起飞！

4.1 MyBatis JSONB TypeHandler 深度封装

我们要让 Java 的 Map 或 POJO 自动与 KB 的 JSONB 无缝转换。

// ============================================================
// 📌 文件：KingbaseJsonbTypeHandler.java
// 📌 用途：MyBatis TypeHandler，实现 Java 对象与 KB JSONB 的无缝转换
// 📌 设计思想：
// 1. 使用 Jackson 进行 JSON 序列化/反序列化
// 2. 使用 PGObject 包装 JSONB 类型，欺骗 JDBC 驱动
// 3. 支持泛型，可映射到 Map、List 或具体的 POJO
// 4. 处理 NULL 值和空字符串的边界情况
// ============================================================

import com.fasterxml.jackson.core.JsonProcessingException;
import com.fasterxml.jackson.databind.JavaType;
import com.fasterxml.jackson.databind.ObjectMapper;
import org.apache.ibatis.type.BaseTypeHandler;
import org.apache.ibatis.type.JdbcType;
import org.apache.ibatis.type.MappedJdbcTypes;
import org.apache.ibatis.type.MappedTypes;
import org.postgresql.util.PGobject;

import java.sql.CallableStatement;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.sql.SQLException;
import java.util.Map;

// 💡 指定处理的 Java 类型（这里以 Map 为例，也可以用 Object）
@MappedTypes({Map.class, Object.class})
// 💡 指定映射的 JDBC 类型（KB/PG 的 JSONB 对应 OTHER）
@MappedJdbcTypes(JdbcType.OTHER)
public class KingbaseJsonbTypeHandler extends BaseTypeHandler {

private static final ObjectMapper MAPPER = new ObjectMapper(); private final JavaType javaType; /** 💡 构造函数：通过反射获取泛型类型 ⚠️ 易错点：MyBatis 实例化 TypeHandler 时，必须提供无参或单参构造函数 */ public KingbaseJsonbTypeHandler(Class<T> type) { this.javaType = MAPPER.constructType(type); } /** 📌 设置非空参数到 PreparedStatement */ @Override public void setNonNullParameter(PreparedStatement ps, int i, T parameter, JdbcType jdbcType) throws SQLException { try { // 1️⃣ 将 Java 对象序列化为 JSON 字符串 String json = MAPPER.writeValueAsString(parameter); // 2️⃣ 构造 PGObject（KB/PG JDBC 驱动的特殊对象） // 💡 核心：必须设置 type 为 "jsonb"，否则 KB 会把它当普通 text 处理，无法使用 GIN 索引！ PGobject pgObject = new PGobject(); pgObject.setType("jsonb"); pgObject.setValue(json); // 3️⃣ 设置到 PreparedStatement ps.setObject(i, pgObject); } catch (JsonProcessingException e) { throw new SQLException("Error converting Java object to JSONB: " + e.getMessage(), e); } } /** 📌 从 ResultSet 获取可空结果 */ @Override public T getNullableResult(ResultSet rs, String columnName) throws SQLException { return parseJson(rs.getString(columnName)); } @Override public T getNullableResult(ResultSet rs, int columnIndex) throws SQLException { return parseJson(rs.getString(columnIndex)); } @Override public T getNullableResult(CallableStatement cs, int columnIndex) throws SQLException { return parseJson(cs.getString(columnIndex)); } /** 💡 核心解析逻辑：JSON String -> Java Object */ private T parseJson(String json) { if (json == null || json.trim().isEmpty()) { return null; // ⚠️ 边界处理：空字符串返回 null } try { // 💡 使用 JavaType 支持泛型反序列化（如 Map<String, Object>） return MAPPER.readValue(json, javaType); } catch (JsonProcessingException e) { // ⚠️ 容错处理：如果 JSON 格式损坏，记录日志并返回 null，避免整个查询崩溃 log.error("Failed to parse JSONB: {}", json, e); return null; } } // 省略 log 定义... private static final org.slf4j.Logger log = org.slf4j.LoggerFactory.getLogger(KingbaseJsonbTypeHandler.class);

}

4.2 在 MyBatis XML 中使用

SELECT id, name, ext_attrs FROM products WHERE -- 💡 KB 的 ->> 操作符：提取 JSON 中的字段并转为 text -- 💡 如果建了 GIN 索引，这个查询会走索引，性能极高！ ext_attrs ->> 'screen_size' = #{screenSize}

💡 金句：把 JSONB 用好，你能干掉系统里 50% 的“扩展属性表”和“字典表”。这不仅是在用数据库，这是在用数据库做架构重构。

💀 第五章：3个让P7翻车的血泪案例（面试必问）

5.1 翻车1：自增主键 SERIAL 的“序列断层”

场景：从 MySQL 迁移到 KB，表的主键从 AUTO_INCREMENT 改成了 KB 的 SERIAL（底层是 Sequence）。
Java 代码用 MyBatis-Plus 批量插入（saveBatch）。

翻车点：
批量插入 1000 条数据后，发现主键 ID 不是连续的！比如从 1 直接跳到了 1050。
更可怕的是，当应用重启后，Sequence 的值没有正确回写，导致新插入的数据 ID 和已有数据冲突，报 Duplicate Key！

原因：
KB 的 Sequence 是非事务性的（为了高并发性能，获取 Sequence 不会回滚）。
MyBatis-Plus 的批量插入默认没有正确触发 KB 的 Sequence 缓存刷新。

修复：
在 KB 中，强烈建议使用 GENERATED ALWAYS AS IDENTITY 替代 SERIAL（KB V8R6+ 支持）。
– ❌ 老写法（容易出断层）
CREATE TABLE users (
id SERIAL PRIMARY KEY,
name VARCHAR(50)
);

– ✅ 新写法（SQL 标准，MyBatis-Plus 适配更好）
CREATE TABLE users (
id INT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
name VARCHAR(50)
);

同时，在 MyBatis-Plus 配置中指定主键生成策略为 INPUT 或 AUTO，并确保 JDBC URL 包含 reWriteBatchedInserts=true。

5.2 翻车2：双引号陷阱与“大小写敏感”惨案

场景：DBA 用 Navicat 建表，表名叫 User_Order（带了大写字母）。
Java 代码里写的是 SELECT * FROM User_Order （MySQL 习惯用反引号）。

翻车点：
应用启动报错：relation “user_order” does not exist。
DBA 在命令行查：SELECT * FROM “User_Order” 能查出来。

原因：
KB（PG内核）对标识符的大小写规则极其严格：
不加引号：全部转为小写存储和查询（User_Order -> user_order）。
加双引号：严格区分大小写（“User_Order” 就是 “User_Order”）。
反引号：KB 的 MySQL 兼容模式虽然支持反引号，但底层依然会做大小写转换。

修复（架构师方案）：
铁律：在 KB 中，所有表名、字段名必须全小写！用下划线分隔！
禁止在代码和建表脚本中使用大写字母。
如果历史遗留必须用大写，在 JDBC URL 中加上 currentSchema=public 并确保开启 enable_ci = on（大小写不敏感模式）。

5.3 翻车3：READ COMMITTED 下的“幻读”灵异事件

场景：
库存扣减逻辑。Java 代码开启了 @Transactional。
@Transactional
public void deductStock(Long productId, int count) {
// 1. 查询库存
Product p = productMapper.selectById(productId);
if (p.getStock() >= count) {
// 2. 扣减库存
productMapper.updateStock(productId, p.getStock() - count);
}
}

翻车点：
在 MySQL（默认 REPEATABLE READ）下，这段代码在并发时没问题（MVCC 快照读）。
但在 KB（默认 READ COMMITTED）下，高并发时出现了“超卖”！

原因：
KB 的默认隔离级别是 READ COMMITTED。
线程 A 查到库存 10，线程 B 也查到库存 10。
线程 A 扣减为 5 并提交。
线程 B 扣减为 5 并提交。
结果：卖了 10 个，但库存只扣了 5 个！

修复：
不要用应用层的“先查后改”！必须用数据库层的原子更新！
// ✅ 正确的做法：一条 SQL 搞定，利用行级锁
@Update(“UPDATE product SET stock = stock - #{count} WHERE id = #{id} AND stock >= #{count}”)
int deductStock(@Param(“id”) Long productId, @Param(“count”) int count);

💡 金句：在 KB/PG 的世界里，“先查后改”是万恶之源。永远用 UPDATE … WHERE 或者 SELECT … FOR UPDATE 来保证并发安全。

🎯 第六章：面试与晋升——如何把“用过KB”包装成核心竞争力？

在简历和面试中，不要只写“熟悉人大金仓”。要这样写：

❌ 低级写法：
“参与信创项目，将 MySQL 迁移至人大金仓，修改了部分 SQL 语法，保证了系统上线。”

✅ 架构师写法：
“主导政务信创数据库改造（MySQL -> 人大金仓 KingbaseES）。
设计并实现了基于 MyBatis Interceptor 的多数据源方言路由引擎，实现业务代码 100% 零改动迁移。
深度利用 KB 的 JSONB + GIN 索引特性，重构商品扩展属性模型，复杂条件查询性能提升 300%。
解决 KB MVCC 机制下的表膨胀问题，定制 autovacuum 策略，保障核心链路 RT 稳定在 50ms 以内。
封装 KB 专用的 UPSERT 和 批量插入 组件，解决高并发下的序列断层与死锁问题。”

面试时，主动抛出这几个问题引导面试官：
“您知道 KB 的 stringtype=unspecified 参数在隐式类型转换中的作用吗？”
“您了解 KB 的 GIN 索引在全文检索和 JSON 查询中的底层 B+Tree 变体结构吗？”
“在信创环境下，鲲鹏 CPU 的 NUMA 架构对 KB 的 shared_buffers 配置有什么影响？”