mokeegateway/memory/session-20260621-1.md

name, description, metadata

name	description	metadata
session-20260621-1	2026-06-21 第1次会话 — 接口性能排查 + sys_system.system_code 加索引	type date sessionNumber startTime session 2026-06-21 1 2026-06-21T00:00:00+08:00

2026-06-21 第1次会话

会话摘要

用户反馈两个接口响应慢，排查了全链路耗时分布。最终在 QA/Prod 数据库 sys_system 表 system_code 列加了普通索引。

关键操作

/zgapi/v1/auth/system/list 性能排查

• 做了什么: 完整追踪请求链路：Nginx → Gateway(32000) → TokenAuthFilter → RateLimitFilter → HeaderInjectFilter → ApiPermissionFilter → GatewayController → [HTTP转发] → Auth(32001) → DB/Redis
• 发现的浪费:
  1. JWT 签名验证执行了 3 次（TokenAuthFilter + RateLimitFilter + AuthServiceImpl）
  2. 同一个 Redis key 被查询了 4 次（TokenAuthFilter GET+GETEXPIRE + AuthServiceImpl GET+GETEXPIRE）
  3. Gateway→Auth HTTP 转发无连接池（SimpleClientHttpRequestFactory）
• 原因: Gateway 和 Auth 服务各自独立认证，互不复用结果
• 结论: 架构设计上的"层层设防"必然代价，不是 bug。未改代码

/zgapi/v1/open/token 性能排查

• 做了什么: 追踪 /zgapi/v1/open/token 全链路
• 发现的问题:
  1. sys_system.system_code 列没有索引 → 每次查询都是全表扫描
  2. sys_open_token_log 用 UUID 主键，日志量上去后 INSERT 引发页分裂
  3. RateLimitFilter 对所有 /open/token 请求共用一个 anonymous 限流 key
  4. 同上：Gateway→Admin HTTP 转发无连接池

sys_system.system_code 加索引

• 做了什么: 在 QA (mokeegatewayqa) 和 Prod (mokeegateway) 的 sys_system 表 system_code 列创建普通索引 idx_system_code
• SQL: CREATE INDEX idx_system_code ON sys_system (system_code)
• 原因: DDL 仅指定了 PRIMARY KEY (id)，system_code 的索引被遗漏，所有按 system_code 查询的场景都在全表扫描（/open/token、ApiPermissionFilter、GatewayController 业务系统转发等）
• 验证结果: QA 和 Prod 均已确认 idx_system_code 存在

重要信息

• QA MySQL: db1.qa.zgitm.com / mokeegatewayqa
• Prod MySQL: db1.prod.zgitm.com / mokeegateway
• DDL sys_system 注释 "uk_system_code/uk_gateway_url 唯一性由应用层代码校验" 说明当时故意没建唯一约束，但普通索引也没有是遗漏

待处理

• 可以考虑给 sys_system.gateway_url 也加个索引（但使用频率低，优先级不高）
• RestTemplateConfig 改用连接池（HttpComponentsClientHttpRequestFactory），省掉每次转发的 TCP 握手
• RateLimitFilter 可以跳过 /zgapi/v1/open/token（获取 token 本身不应限流，且 anonymous key 是热点）
• Auth 服务 getTokenInfoFromRedis 中 JWT validateToken 可以改为只解析 payload 不验签（Gateway 已验证过）