ethan-skill 1.7.0 → 1.9.0

package/dist/skills/17-system-design.js

@@ -0,0 +1,294 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.systemDesignSkill = void 0;
+exports.systemDesignSkill = {
+    id: 'system-design',
+    name: '系统设计',
+    nameEn: 'system_design',
+    order: 17,
+    category: '执行侧',
+    description: '从需求澄清到架构设计全流程，完成高并发分布式系统的方案设计与权衡分析',
+    descriptionEn: 'Full system design process from requirement clarification to architecture with scalability and availability tradeoffs',
+    detailDescription: `系统性指导大型系统设计流程，涵盖需求澄清与非功能指标量化、容量估算、高层架构选型、
+核心组件设计、数据库模型与扩展性分析，帮助在面试或实际项目中输出结构清晰、考量全面的系统设计方案。`,
+    triggers: [
+        '系统设计',
+        'system design',
+        '架构设计',
+        'architecture design',
+        '高并发系统',
+        '分布式系统',
+        'distributed system',
+        '容量估算',
+        'capacity estimation',
+        '扩展性设计',
+        'scalability',
+        '@ethan design',
+        '@ethan system-design',
+    ],
+    steps: [
+        {
+            title: '1. 需求澄清与范围界定',
+            content: `在动手设计前，花 5 分钟澄清需求：
+
+**功能需求（Functional Requirements）**
+- 系统的核心用例是什么？（写出 3-5 个最关键的）
+- 哪些功能在 scope 内，哪些明确 out of scope？
+- 用户角色有哪些？各自的主要操作是什么？
+
+**非功能需求（Non-Functional Requirements）**
+
+| 维度 | 问题 | 示例指标 |
+|------|------|---------|
+| 规模 | 用户量 / DAU / QPS 是多少？ | 1亿用户，1000万 DAU |
+| 性能 | 读写延迟要求？P99 是多少？ | P99 < 100ms |
+| 可用性 | 允许多少停机时间？ | 99.9%（每年 8.7h） |
+| 一致性 | 强一致 or 最终一致？ | 最终一致（可接受） |
+| 持久性 | 数据丢失容忍度？ | RPO = 0（不允许丢失） |
+
+**明确边界的示例问题**
+\`\`\`
+Q: 设计一个 Twitter
+A（先澄清）:
+- 只需要发推/关注/Feed 功能吗？（排除私信、广告）
+- 用户规模：3亿用户，1亿 DAU？
+- 读写比例：推文读多写少，100:1？
+- 媒体文件：支持图片/视频吗？
+- 全球分发还是单地区？
+\`\`\``,
+        },
+        {
+            title: '2. 容量估算（Back-of-Envelope）',
+            content: `快速估算系统规模，为架构决策提供数据依据：
+
+**常用基准数字**
+\`\`\`
+内存访问：    ~100ns
+SSD 访问：    ~100μs
+HDD 访问：    ~10ms
+网络往返（同数据中心）：~0.5ms
+网络往返（跨地区）：    ~100ms
+
+1 MB = 10^6 bytes
+1 GB = 10^9 bytes
+1 TB = 10^12 bytes
+\`\`\`
+
+**估算示例：设计微博（Twitter-like）**
+\`\`\`
+用户数据：
+- DAU: 1亿
+- 每用户每天发1条推文 → 写 QPS = 100M / 86400 ≈ 1160 QPS
+- 每用户每天读100条 → 读 QPS = 100 × 1160 = 116,000 QPS
+
+存储估算：
+- 单条推文: 140字 × 2字节(UTF-16) = 280字节 ≈ 300字节
+- 元数据(user_id, timestamp等): 100字节
+- 每条推文总计: ~400字节
+- 每日新增: 1.16K QPS × 400字节 × 86400 = ~40 GB/天
+- 5年存储: 40GB × 365 × 5 ≈ 73 TB
+
+带宽估算：
+- 写带宽: 1160 × 400字节 = ~450 KB/s
+- 读带宽: 116K × 400字节 = ~45 MB/s
+\`\`\`
+
+**结论：** 读多写少（100:1），需要读缓存；存储量大需分库分表；单机无法支撑读 QPS 需多副本。`,
+        },
+        {
+            title: '3. 高层架构设计',
+            content: `从整体入手，画出系统的核心模块和数据流：
+
+**通用分层架构**
+\`\`\`
+客户端 (Web/Mobile/API Consumer)
+         │
+         ▼
+   DNS + CDN (静态资源 / 地理路由)
+         │
+         ▼
+   Load Balancer (L4/L7, 负载均衡 + SSL 终止)
+    ┌────┴────┐
+    ▼         ▼
+ API Srv   API Srv   (无状态，水平扩展)
+    │
+    ├──→ Cache (Redis: 热数据)
+    ├──→ Message Queue (Kafka: 异步解耦)
+    ├──→ Primary DB (写操作)
+    └──→ Read Replica (读操作)
+         │
+         ▼
+   Object Storage (S3: 文件/媒体)
+   Search Engine (Elasticsearch)
+\`\`\`
+
+**架构选型决策点**
+
+| 场景 | 选型建议 |
+|------|---------|
+| 读多写少 | 读写分离 + 缓存层 |
+| 高写入吞吐 | 异步消息队列削峰 |
+| 数据量超百亿行 | 分库分表 / NoSQL |
+| 强一致性 | 单主 / Paxos / Raft |
+| 最终一致性 | 多主 / CRDT |
+| 低延迟全球访问 | CDN + 多地域部署 |
+| 复杂查询 | 专用搜索引擎 |
+
+**微服务 vs 单体 决策**
+- 团队 < 10人，初创期：单体优先（避免过度工程）
+- 明确的服务边界、独立扩展需求：拆分微服务
+- 拆分原则：按业务边界（DDD 限界上下文），而非技术层`,
+        },
+        {
+            title: '4. 核心组件深度设计',
+            content: `针对最关键的 2-3 个组件进行深入设计：
+
+**数据库 Schema 设计**
+\`\`\`sql
+-- 示例：推文表设计
+CREATE TABLE tweets (
+  id          BIGINT PRIMARY KEY,      -- Snowflake ID（分布式唯一ID）
+  user_id     BIGINT NOT NULL,
+  content     VARCHAR(280) NOT NULL,
+  created_at  TIMESTAMP DEFAULT NOW(),
+  like_count  INT DEFAULT 0,
+  retweet_count INT DEFAULT 0,
+  INDEX idx_user_created (user_id, created_at DESC)  -- 用户时间线查询
+);
+
+-- Fan-out 策略：预写 vs 拉取
+-- 方案A: Push（写扩散）: 发推时写入所有粉丝的 Feed 表
+-- 方案B: Pull（读扩散）: 读取时聚合关注者的推文
+-- 混合方案: 普通用户 Push，大V（粉丝>100万）Pull
+\`\`\`
+
+**缓存策略**
+\`\`\`
+Cache-Aside（旁路缓存）- 最通用
+读: 查缓存 → miss → 查DB → 写缓存 → 返回
+写: 更新DB → 删除缓存（避免双写不一致）
+
+Write-Through（写穿）- 一致性高
+写: 同时写DB和缓存
+
+Write-Behind（写回）- 高性能
+写: 先写缓存，异步批量写DB（风险：缓存宕机丢数据）
+
+缓存 Key 设计示例:
+user:{userId}:profile      → 用户资料
+user:{userId}:feed:page:{n} → 用户 Feed 分页
+tweet:{tweetId}            → 单条推文
+\`\`\`
+
+**API 接口设计**
+\`\`\`
+POST /tweets              发布推文
+GET  /users/{id}/feed     获取 Feed (cursor分页)
+POST /tweets/{id}/like    点赞
+GET  /tweets/{id}         获取单条推文
+
+分页策略: cursor-based > offset-based（大数据量场景）
+cursor: base64(created_at + tweet_id)
+\`\`\``,
+        },
+        {
+            title: '5. 可扩展性与可用性权衡',
+            content: `**CAP 定理实践**
+\`\`\`
+C（一致性）+ A（可用性）+ P（分区容错）三选二
+网络分区不可避免 → 通常是 CP 或 AP 的选择
+
+CP 系统: ZooKeeper, HBase（金融交易、库存扣减）
+AP 系统: Cassandra, DynamoDB（社交Feed、购物车）
+\`\`\`
+
+**水平扩展策略**
+
+| 层次 | 策略 |
+|------|------|
+| 无状态应用层 | 直接水平扩展 + 负载均衡 |
+| 有状态缓存 | 一致性哈希分片（Redis Cluster） |
+| 数据库水平 | 分库分表（按 user_id % N） |
+| 数据库垂直 | 主从复制，读写分离 |
+
+**单点故障（SPOF）消除清单**
+- [ ] Load Balancer 双活/主备
+- [ ] 数据库主从 + 自动故障转移（MHA/Orchestrator）
+- [ ] 缓存集群（Redis Sentinel / Cluster）
+- [ ] 消息队列多副本（Kafka Replication Factor ≥ 3）
+- [ ] 跨可用区部署（Multi-AZ）
+
+**限流与熔断**
+\`\`\`
+限流: Token Bucket（突发流量友好）
+     Sliding Window（精准限流）
+     分级限流: 用户级 → 接口级 → 全局
+
+熔断: Closed → Open（失败率>50%）→ Half-Open（探测恢复）
+工具: Resilience4j（Java）/ hystrix-go / Polly(.NET)
+\`\`\``,
+        },
+        {
+            title: '6. 输出系统设计文档',
+            content: `整理为结构化设计文档：
+
+\`\`\`markdown
+## 系统设计方案：[系统名称]
+
+### 1. 需求概述
+**功能需求**（核心功能列表）
+**非功能需求**（QPS / 延迟 / 可用性 / 存储）
+
+### 2. 容量估算
+| 指标 | 估算值 |
+|------|-------|
+| DAU | X 万 |
+| 写 QPS | X |
+| 读 QPS | X |
+| 存储（5年） | X TB |
+
+### 3. 系统架构图
+[ASCII 图或 Mermaid 图]
+
+### 4. 核心组件设计
+- **数据库 Schema**：[关键表设计]
+- **缓存策略**：[策略选择与理由]
+- **API 设计**：[关键接口]
+
+### 5. 扩展性方案
+- **瓶颈点**：[识别的瓶颈]
+- **解决方案**：[具体方案]
+
+### 6. 权衡与风险
+[已知权衡和设计风险]
+\`\`\``,
+        },
+    ],
+    outputFormat: 'Markdown 系统设计文档，含需求澄清结果、容量估算数据、架构图、核心组件设计方案和扩展性权衡分析',
+    examples: [
+        {
+            input: '设计一个短链接服务（如 bit.ly）',
+            output: `## 短链接服务设计
+
+**规模**：每天 1 亿次创建，10 亿次访问（10:1 读写比）
+**写 QPS**：~1160，**读 QPS**：~11600，存储5年：~40TB
+
+**核心架构**：Web → LB → API Server → Redis（热门短链缓存）→ Cassandra（主存储）
+
+**短链生成**：Base62 编码 7位（62^7 ≈ 3500亿，够用）
+- 方案A: 预生成随机串存DB（无冲突）
+- 方案B: ID自增 → Base62编码（简单高效，推荐）
+
+**重定向**：301（永久，浏览器缓存，减少服务压力）vs 302（临时，可统计点击）
+**数据库**：Cassandra（key-value 访问模式完美匹配，易扩展）`,
+        },
+    ],
+    notes: [
+        '系统设计没有标准答案，重点展示思考过程和权衡意识',
+        '先画出高层架构，再逐步深入细节，避免一开始陷入细节',
+        '主动提出设计中的权衡和不足，展示对复杂度的认知',
+        '数量级估算误差在 10x 以内即可，重要的是数量级概念',
+    ],
+    nextSkill: 'database-optimize',
+};
+//# sourceMappingURL=17-system-design.js.map

package/dist/skills/17-system-design.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"17-system-design.js","sourceRoot":"","sources":["../../src/skills/17-system-design.ts"],"names":[],"mappings":";;;AAEa,QAAA,iBAAiB,GAAoB;IAChD,EAAE,EAAE,eAAe;IACnB,IAAI,EAAE,MAAM;IACZ,MAAM,EAAE,eAAe;IACvB,KAAK,EAAE,EAAE;IACT,QAAQ,EAAE,KAAK;IACf,WAAW,EAAE,oCAAoC;IACjD,aAAa,EAAE,uHAAuH;IACtI,iBAAiB,EAAE;kDAC6B;IAChD,QAAQ,EAAE;QACR,MAAM;QACN,eAAe;QACf,MAAM;QACN,qBAAqB;QACrB,OAAO;QACP,OAAO;QACP,oBAAoB;QACpB,MAAM;QACN,qBAAqB;QACrB,OAAO;QACP,aAAa;QACb,eAAe;QACf,sBAAsB;KACvB;IACD,KAAK,EAAE;QACL;YACE,KAAK,EAAE,cAAc;YACrB,OAAO,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;OA0BR;SACF;QACD;YACE,KAAK,EAAE,2BAA2B;YAClC,OAAO,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;sDAkCuC;SACjD;QACD;YACE,KAAK,EAAE,WAAW;YAClB,OAAO,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;8BAwCe;SACzB;QACD;YACE,KAAK,EAAE,aAAa;YACpB,OAAO,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;OAgDR;SACF;QACD;YACE,KAAK,EAAE,eAAe;YACtB,OAAO,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;OAiCR;SACF;QACD;YACE,KAAK,EAAE,aAAa;YACpB,OAAO,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;OA+BR;SACF;KACF;IACD,YAAY,EACV,qDAAqD;IACvD,QAAQ,EAAE;QACR;YACE,KAAK,EAAE,qBAAqB;YAC5B,MAAM,EAAE;;;;;;;;;;;;0CAY4B;SACrC;KACF;IACD,KAAK,EAAE;QACL,0BAA0B;QAC1B,2BAA2B;QAC3B,yBAAyB;QACzB,6BAA6B;KAC9B;IACD,SAAS,EAAE,mBAAmB;CAC/B,CAAC"}

package/dist/skills/18-database-optimize.d.ts

@@ -0,0 +1,3 @@
+import type { SkillDefinition } from './types';
+export declare const databaseOptimizeSkill: SkillDefinition;
+//# sourceMappingURL=18-database-optimize.d.ts.map

package/dist/skills/18-database-optimize.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"18-database-optimize.d.ts","sourceRoot":"","sources":["../../src/skills/18-database-optimize.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,eAAe,EAAE,MAAM,SAAS,CAAC;AAE/C,eAAO,MAAM,qBAAqB,EAAE,eAkSnC,CAAC"}

package/dist/skills/18-database-optimize.js

@@ -0,0 +1,294 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.databaseOptimizeSkill = void 0;
+exports.databaseOptimizeSkill = {
+    id: 'database-optimize',
+    name: '数据库优化',
+    nameEn: 'database_optimize',
+    order: 18,
+    category: '质量侧',
+    description: '系统诊断数据库性能问题，涵盖 Schema 审查、索引设计、慢查询分析和 N+1 修复',
+    descriptionEn: 'Diagnose and optimize database performance covering schema review, index design, slow query analysis, and N+1 fixes',
+    detailDescription: `端到端数据库性能优化指导，从 Schema 设计审查、索引策略制定、慢查询日志分析、
+N+1 查询识别与修复，到分区分表策略，帮助系统在数据量增长时保持查询性能。`,
+    triggers: [
+        '数据库优化',
+        'database optimize',
+        '慢查询',
+        'slow query',
+        'SQL 优化',
+        'SQL optimization',
+        '索引优化',
+        'index optimization',
+        'N+1 问题',
+        'N+1 query',
+        '查询性能',
+        'query performance',
+        '@ethan db',
+        '@ethan database-optimize',
+    ],
+    steps: [
+        {
+            title: '1. Schema 设计审查',
+            content: `检查数据库表结构是否存在设计问题：
+
+**规范化检查（防止冗余）**
+\`\`\`sql
+-- ❌ 反模式：在用户表存储地址字符串
+CREATE TABLE users (
+  id INT PRIMARY KEY,
+  name VARCHAR(100),
+  address VARCHAR(500)  -- 难以精准查询城市/省份
+);
+
+-- ✅ 正确：拆分为 addresses 表
+CREATE TABLE users (id INT PRIMARY KEY, name VARCHAR(100));
+CREATE TABLE addresses (
+  id INT PRIMARY KEY,
+  user_id INT REFERENCES users(id),
+  province VARCHAR(50),
+  city VARCHAR(50),
+  detail VARCHAR(200)
+);
+\`\`\`
+
+**数据类型选择**
+
+| 场景 | 推荐类型 | 避免 |
+|------|---------|------|
+| 主键 | BIGINT / UUID | INT（可能溢出） |
+| 状态枚举 | TINYINT / ENUM | VARCHAR |
+| 金额 | DECIMAL(10,2) | FLOAT（精度丢失）|
+| 时间 | TIMESTAMP / DATETIME | VARCHAR |
+| 短字符串(≤255) | VARCHAR(N) | TEXT |
+| 布尔值 | TINYINT(1) | VARCHAR('true') |
+
+**常见 Schema 问题清单**
+- [ ] 是否有未使用的列？
+- [ ] VARCHAR 长度是否合理（不要都 VARCHAR(255)）？
+- [ ] 外键是否有索引？
+- [ ] 是否有重复的字段（非规范化导致）？
+- [ ] 是否用了 TEXT/BLOB 存储应该单独存储的大文件？`,
+        },
+        {
+            title: '2. 索引设计策略',
+            content: `**索引类型选择**
+
+\`\`\`sql
+-- 单列索引：高选择性字段（如 email、手机号）
+CREATE INDEX idx_users_email ON users(email);
+
+-- 联合索引：遵循最左前缀原则
+-- 适合查询: WHERE status = ? AND created_at > ?
+-- 适合查询: WHERE status = ?
+-- 不适合:   WHERE created_at > ?  （无法命中）
+CREATE INDEX idx_orders_status_created ON orders(status, created_at);
+
+-- 覆盖索引：索引包含查询所有字段，避免回表
+-- 查询: SELECT user_id, status FROM orders WHERE order_no = ?
+CREATE INDEX idx_orders_covering ON orders(order_no, user_id, status);
+
+-- 前缀索引：长字符串节省空间
+CREATE INDEX idx_url_prefix ON pages(url(50));
+
+-- 函数索引（MySQL 8.0+）：对表达式建索引
+CREATE INDEX idx_lower_email ON users((LOWER(email)));
+\`\`\`
+
+**EXPLAIN 分析索引使用**
+\`\`\`sql
+EXPLAIN SELECT * FROM orders
+WHERE user_id = 1001 AND status = 'PAID'
+ORDER BY created_at DESC LIMIT 10;
+
+-- 关注字段:
+-- type:  ref > range > index > ALL（ALL 最差）
+-- key:   使用的索引名（NULL 表示未使用索引）
+-- rows:  预估扫描行数（越小越好）
+-- Extra: Using filesort / Using temporary（需优化的信号）
+\`\`\`
+
+**索引原则**
+- 高频查询的 WHERE / JOIN / ORDER BY 字段建索引
+- 选择性低的字段慎建索引（如 status 只有3个值）
+- 避免在频繁更新的列上建过多索引（写性能代价）
+- 复合索引字段顺序：等值条件在前，范围条件在后`,
+        },
+        {
+            title: '3. 慢查询分析与优化',
+            content: `**开启慢查询日志**
+\`\`\`sql
+-- MySQL 配置
+SET GLOBAL slow_query_log = 'ON';
+SET GLOBAL long_query_time = 1;  -- 超过1秒记录
+SET GLOBAL log_queries_not_using_indexes = 'ON';
+
+-- 查看慢查询日志文件位置
+SHOW VARIABLES LIKE 'slow_query_log_file';
+
+-- 使用 pt-query-digest 分析日志
+pt-query-digest /var/log/mysql/slow.log | head -100
+\`\`\`
+
+**常见慢查询模式与修复**
+\`\`\`sql
+-- ❌ 问题1: SELECT * 全列查询
+SELECT * FROM orders WHERE user_id = 1001;
+-- ✅ 修复: 只查需要的列
+SELECT id, order_no, status, total FROM orders WHERE user_id = 1001;
+
+-- ❌ 问题2: 对索引列使用函数，导致索引失效
+SELECT * FROM orders WHERE DATE(created_at) = '2024-01-01';
+-- ✅ 修复: 使用范围查询
+SELECT * FROM orders
+WHERE created_at >= '2024-01-01' AND created_at < '2024-01-02';
+
+-- ❌ 问题3: OR 导致索引失效（某些情况）
+SELECT * FROM users WHERE email = ? OR phone = ?;
+-- ✅ 修复: UNION ALL
+SELECT * FROM users WHERE email = ?
+UNION ALL
+SELECT * FROM users WHERE phone = ?;
+
+-- ❌ 问题4: LIKE 前缀通配符
+SELECT * FROM products WHERE name LIKE '%iPhone%';
+-- ✅ 修复: 使用全文索引或 Elasticsearch
+SELECT * FROM products WHERE MATCH(name) AGAINST('iPhone' IN BOOLEAN MODE);
+
+-- ❌ 问题5: 隐式类型转换
+SELECT * FROM users WHERE user_id = '1001';  -- user_id 是 INT
+-- ✅ 修复: 类型匹配
+SELECT * FROM users WHERE user_id = 1001;
+\`\`\``,
+        },
+        {
+            title: '4. N+1 查询识别与修复',
+            content: `**N+1 问题定义**：查询1次获取N条记录，再针对每条记录查询1次，共 N+1 次数据库访问。
+
+**ORM 场景中的 N+1**
+\`\`\`typescript
+// ❌ TypeORM N+1 示例：查100个用户 → 执行101次SQL
+const users = await userRepository.find();  // Query 1: SELECT * FROM users
+for (const user of users) {
+  const orders = await user.orders;         // Query 2-101: 每个用户各查一次
+  console.log(orders.length);
+}
+
+// ✅ 修复：使用 eager loading（JOIN）
+const users = await userRepository.find({
+  relations: ['orders'],  // 一次 JOIN 查询搞定
+});
+
+// ✅ 或使用 QueryBuilder（更精确控制）
+const users = await userRepository
+  .createQueryBuilder('user')
+  .leftJoinAndSelect('user.orders', 'order')
+  .where('order.status = :status', { status: 'PAID' })
+  .getMany();
+\`\`\`
+
+**原生 SQL 批量查询模式**
+\`\`\`sql
+-- ❌ N+1: 循环查询
+-- for user_id in user_ids: SELECT * FROM orders WHERE user_id = ?
+
+-- ✅ 批量查询 + 应用层 Map 聚合
+SELECT user_id, COUNT(*) as order_count, SUM(total) as total_amount
+FROM orders
+WHERE user_id IN (1,2,3,...,100)  -- 一次查询
+GROUP BY user_id;
+-- 在应用层用 Map 按 user_id 聚合
+\`\`\`
+
+**检测 N+1 工具**
+\`\`\`
+- Laravel Debugbar（PHP）
+- Django Debug Toolbar（Python）
+- Bullet gem（Rails）
+- TypeORM logging: { logging: true } 观察 SQL 数量
+- DataLoader（GraphQL 场景批量加载）
+\`\`\``,
+        },
+        {
+            title: '5. 分区与分表策略',
+            content: `**表分区（Partitioning）— 单机方案**
+\`\`\`sql
+-- 按时间范围分区（适合日志、订单历史）
+CREATE TABLE orders (
+  id BIGINT,
+  user_id INT,
+  created_at DATETIME,
+  total DECIMAL(10,2)
+) PARTITION BY RANGE (YEAR(created_at)) (
+  PARTITION p2022 VALUES LESS THAN (2023),
+  PARTITION p2023 VALUES LESS THAN (2024),
+  PARTITION p2024 VALUES LESS THAN (2025),
+  PARTITION pmax  VALUES LESS THAN MAXVALUE
+);
+
+-- 分区裁剪：查询自动只扫描相关分区
+SELECT * FROM orders WHERE created_at >= '2024-01-01';
+-- 只扫描 p2024 分区，跳过历史分区
+\`\`\`
+
+**分库分表策略（超千万行后考虑）**
+
+| 方案 | 分片键选择 | 适用场景 |
+|------|----------|---------|
+| 水平分表（同库） | user_id % N | 单库容量瓶颈 |
+| 水平分库 | user_id % N | 读写 QPS 瓶颈 |
+| 按地区分库 | region | 合规/延迟要求 |
+
+\`\`\`
+分片键选择原则:
+- 选择查询中高频使用的字段（避免跨分片查询）
+- 选择数据分布均匀的字段（避免热点）
+- 一旦确定不能轻易更改
+
+常见工具:
+- ShardingSphere（Java）
+- Vitess（MySQL 集群，YouTube 方案）
+- Citus（PostgreSQL 分布式扩展）
+\`\`\`
+
+**读写分离配置**
+\`\`\`
+主库（Primary）: 处理写操作 + 强一致读
+从库（Replica）: 处理读操作（注意主从延迟，通常 <1s）
+
+适用于读写比 > 4:1 的场景
+注意: 写后立即读可能读到旧数据（主从同步延迟）
+解决: 重要读操作路由到主库；或用 Redis 缓存最新写入
+\`\`\``,
+        },
+    ],
+    outputFormat: 'Markdown 优化报告，含 Schema 问题列表、索引设计方案、慢查询 EXPLAIN 分析、N+1 修复代码示例和分区建议',
+    examples: [
+        {
+            input: '用户列表页加载很慢，查询订单表，数据量1000万行',
+            output: `## 数据库性能诊断
+
+**Step 1: 执行 EXPLAIN**
+\`\`\`sql
+EXPLAIN SELECT o.*, u.name FROM orders o
+JOIN users u ON o.user_id = u.id
+WHERE o.status = 'PAID' ORDER BY o.created_at DESC LIMIT 20;
+\`\`\`
+
+**发现问题**：type = ALL（全表扫描），rows = 10,000,000
+
+**优化方案**：
+1. 添加联合索引：\`CREATE INDEX idx_orders_status_created ON orders(status, created_at DESC);\`
+2. 加 users 表关联索引：\`CREATE INDEX idx_users_id ON users(id);\`（通常主键已有）
+3. 预期效果：rows 从 1000万 降至 <1000，响应时间从 5s → 50ms`,
+        },
+    ],
+    notes: [
+        '优化前先用 EXPLAIN 分析，避免盲目加索引',
+        '索引不是越多越好，每个索引都会降低写入性能，控制在 5-8 个以内',
+        '分库分表是最后手段，优先考虑索引优化、缓存、读写分离',
+        '生产环境加索引使用 gh-ost 或 pt-online-schema-change，避免锁表',
+    ],
+    nextSkill: 'docker',
+};
+//# sourceMappingURL=18-database-optimize.js.map

package/dist/skills/18-database-optimize.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"18-database-optimize.js","sourceRoot":"","sources":["../../src/skills/18-database-optimize.ts"],"names":[],"mappings":";;;AAEa,QAAA,qBAAqB,GAAoB;IACpD,EAAE,EAAE,mBAAmB;IACvB,IAAI,EAAE,OAAO;IACb,MAAM,EAAE,mBAAmB;IAC3B,KAAK,EAAE,EAAE;IACT,QAAQ,EAAE,KAAK;IACf,WAAW,EAAE,6CAA6C;IAC1D,aAAa,EAAE,qHAAqH;IACpI,iBAAiB,EAAE;uCACkB;IACrC,QAAQ,EAAE;QACR,OAAO;QACP,mBAAmB;QACnB,KAAK;QACL,YAAY;QACZ,QAAQ;QACR,kBAAkB;QAClB,MAAM;QACN,oBAAoB;QACpB,QAAQ;QACR,WAAW;QACX,MAAM;QACN,mBAAmB;QACnB,WAAW;QACX,0BAA0B;KAC3B;IACD,KAAK,EAAE;QACL;YACE,KAAK,EAAE,gBAAgB;YACvB,OAAO,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;mCAsCoB;SAC9B;QACD;YACE,KAAK,EAAE,WAAW;YAClB,OAAO,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;yBAwCU;SACpB;QACD;YACE,KAAK,EAAE,aAAa;YACpB,OAAO,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;OA2CR;SACF;QACD;YACE,KAAK,EAAE,gBAAgB;YACvB,OAAO,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;OA4CR;SACF;QACD;YACE,KAAK,EAAE,YAAY;YACnB,OAAO,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;OAgDR;SACF;KACF;IACD,YAAY,EACV,mEAAmE;IACrE,QAAQ,EAAE;QACR;YACE,KAAK,EAAE,2BAA2B;YAClC,MAAM,EAAE;;;;;;;;;;;;;;8CAcgC;SACzC;KACF;IACD,KAAK,EAAE;QACL,0BAA0B;QAC1B,mCAAmC;QACnC,4BAA4B;QAC5B,iDAAiD;KAClD;IACD,SAAS,EAAE,QAAQ;CACpB,CAAC"}

package/dist/skills/19-docker.d.ts

@@ -0,0 +1,3 @@
+import type { SkillDefinition } from './types';
+export declare const dockerSkill: SkillDefinition;
+//# sourceMappingURL=19-docker.d.ts.map

package/dist/skills/19-docker.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"19-docker.d.ts","sourceRoot":"","sources":["../../src/skills/19-docker.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,eAAe,EAAE,MAAM,SAAS,CAAC;AAE/C,eAAO,MAAM,WAAW,EAAE,eAoWzB,CAAC"}