sqllog2db

达梦数据库 SQL 日志高性能解析工具 — 流式处理百万级记录，常量内存占用，支持 CSV/SQLite 导出。

快速安装

# 从 crates.io 安装
cargo install dm-database-sqllog2db

# 生成配置并运行
sqllog2db init -o config.toml
sqllog2db run -c config.toml

# 统计分析慢 SQL 和高频 SQL
sqllog2db stats -c config.toml

需要 Rust 1.85+。二进制文件约 5 MB。

文档

• 快速入门 — 从安装到导出，逐步引导完成常见使用场景
• 配置参考 — 所有配置项的完整说明
• 架构说明 — 数据流、模块划分和关键设计
• 贡献指南 — 环境搭建、编码规约和 PR 提交流程

链接

• GitHub 仓库
• crates.io
• 变更日志
• 许可证 — Apache-2.0

Built with mdBook. Deployed via GitHub Actions.

快速入门指南

本指南带你了解 sqllog2db 的常见使用场景。每个场景展示从配置生成到输出验证的完整工作流程。如需最简三命令概览，请参见 README。

环境准备

通过 rustup 安装 Rust：

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

安装 sqllog2db：

cargo install dm-database-sqllog2db

验证安装：

sqllog2db --version

备选方案：从源码构建：

git clone https://github.com/guangl/sqllog2db
cd sqllog2db
cargo build --release

二进制文件约 5 MB，静态链接，位于 target/release/sqllog2db。

从源码克隆时，sqllogs/ 目录下包含示例日志文件。生产环境请使用你自己的达梦 SQL 日志。

场景一：导出 SQL 日志到 CSV

将达梦 SQL 日志导出为 CSV 以供分析或归档。

步骤 1：生成默认配置

sqllog2db init -o config.toml --force

预期输出：

Config written to config.toml

步骤 2：配置 CSV 导出

编辑 config.toml：

[sqllog]
inputs = ["sqllogs"]

[exporter.csv]
file = "output/sqllog.csv"
overwrite = true

步骤 3：验证配置

sqllog2db validate -c config.toml

通过时静默退出（无输出，exit 0）；失败时输出 [FAIL] <字段>: <原因> 并以非零码退出。

步骤 4：运行导出

sqllog2db run -c config.toml

预期输出：

[INFO] Starting export...
[INFO] Processing: sqllogs/DM_DMSQL_202504_01.log
[INFO] Processed 100000 records...
[INFO] Processed 200000 records...
[INFO] Export complete: 2,372,459 records in 8.87s (267,525 records/sec)

步骤 5：验证输出

wc -l output/sqllog.csv
head -5 output/sqllog.csv

故障排查： 如果看到 "Config validation failed: sqllog.path"，请确保 path 指向存在的目录或文件。自动化脚本中建议使用绝对路径。

场景二：导出到 SQLite 数据库

导出到 SQLite 以便使用 SQL 进行分析。

步骤 1：配置 SQLite 导出

编辑 config.toml：

[sqllog]
inputs = ["sqllogs"]

[exporter.sqlite]
file = "output/sqllog.db"
table = "sqllog_records"
overwrite = true

步骤 2：验证并运行

sqllog2db validate -c config.toml
sqllog2db run -c config.toml

步骤 3：验证并查询

# 统计总记录数
sqlite3 output/sqllog.db "SELECT COUNT(*) FROM sqllog_records;"

# 按查询数量查看 Top 5 用户
sqlite3 output/sqllog.db "SELECT USERNAME, COUNT(*) AS cnt FROM sqllog_records GROUP BY USERNAME ORDER BY cnt DESC LIMIT 5;"

# 查看 Top 10 最慢查询
sqlite3 output/sqllog.db "SELECT SQL_TEXT, ELAPSED FROM sqllog_records ORDER BY ELAPSED DESC LIMIT 10;"

预期用户排名输出：

HIHIS|1748411
BBP|513287
HINIS|83921
BLC|18342
SYSDBA|5234

故障排查： 如果找不到 sqlite3，请通过 brew install sqlite（macOS）或系统包管理器安装。

场景三：使用过滤器精确导出

应用记录级和事务级过滤器，仅导出符合条件的 SQL 记录。

步骤 1：配置过滤器

编辑 config.toml：

[sqllog]
inputs = ["sqllogs"]

[filter]
enable = true

[filter.include]
statements = ["INS", "UPD", "DEL"]
min_runtime_ms = 100

[filter.exclude]
users = ["SYSDBA", "MONITOR"]

[exporter.csv]
file = "output/filtered.csv"
overwrite = true

步骤 2：验证并运行

sqllog2db validate -c config.toml
sqllog2db run -c config.toml

步骤 3：使用 SQL 内容过滤器

事务级 SQL 内容过滤需要两遍预扫描：

[filter.sql_filter]
includes = ["FROM ORDERS", "JOIN PAYMENTS"]
excludes = ["pg_catalog", "information_schema"]
min_runtime_ms = 500

工具先扫描所有文件收集匹配的事务 ID，再于第二遍中应用全部过滤器。

通过外部工具分析输出：

# 使用 sqlite3 查询 Top 5 最慢的写操作
sqlite3 output/filtered.db "SELECT SQL_TEXT, ELAPSED FROM sqllog_records WHERE STMT_TYPE IN ('INS','UPD','DEL') ORDER BY ELAPSED DESC LIMIT 5;"

# 使用 csvkit 工具
csvstat output/filtered.csv

场景四：SQL 统计分析

使用 stats 子命令对 SQL 日志进行统计分析，生成慢 SQL 报告和高频 SQL 报告。

步骤 1：配置输入和输出目录

编辑 config.toml（复用 run 命令的配置格式）：

[sqllog]
inputs = ["sqllogs"]

[exporter.csv]
file = "output/sqllog.csv"
overwrite = true

步骤 2：运行统计分析

sqllog2db stats -c config.toml

默认输出 Top 20 条，可用 --top 调整：

sqllog2db stats -c config.toml --top 10

步骤 3：查看输出

CSV 模式在 [exporter.csv].file 的同级目录（本例为 output/）生成：

output/slow_sql.csv       — Top N 最慢 SQL（字段：sql_text, elapsed_ms, timestamp）
output/frequent_sql.csv   — Top N 高频 SQL（字段：normalized_sql, call_count, avg_elapsed_ms, max_elapsed_ms）

示例查看：

head -5 output/slow_sql.csv
head -5 output/frequent_sql.csv

使用 SQLite 输出：

[sqllog]
inputs = ["sqllogs"]

[exporter.sqlite]
database_url = "output/sqllog2db.db"
table_name = "sqllog_records"
overwrite = true

SQLite 模式在同一数据库中写入 slow_sql 和 frequent_sql 表，可直接用 SQL 查询：

sqlite3 output/sqllog2db.db "SELECT * FROM slow_sql LIMIT 5;"
sqlite3 output/sqllog2db.db "SELECT * FROM frequent_sql ORDER BY call_count DESC LIMIT 5;"

故障排查

配置验证失败

• 运行 sqllog2db validate -c config.toml 查看具体错误
• 检查 sqllog.path 是否存在且可读
• 确保输出目录存在（sqllog2db 不会自动创建中间目录）
• 验证 TOML 语法：节标题使用 [方括号]，值使用 =

"未找到 .log 文件"

• 验证 [sqllog].path 中的路径是否正确
• 使用绝对路径：/home/user/logs/ 而非 ../logs/
• 检查文件是否具有 .log 扩展名

导出性能较慢

• 确保处理管道为空（无 [filter] 节）以获得最大速度
• CSV 导出比 SQLite 更快（约 520 万条/秒 vs 约 110 万条/秒）
• 使用 NVMe SSD 获得最佳吞吐量
• 对于大数据集，文件 I/O 是主要瓶颈

输出中出现解析错误

• 解析错误是非致命的：工具继续处理后续记录
• 错误记录到应用日志中（检查 [logging] 配置）
• GB18030/GBK 编码的文件会自动检测和解码

配置参考

本文档描述 sqllog2db 中所有可用的配置选项。配置文件使用 TOML 格式编写。默认配置由 sqllog2db init -o config.toml --force 生成。以下每节记录一个配置块，包含字段、默认值和使用说明。

[sqllog]

指定要处理的输入日志文件。

[sqllog]
# 输入列表：目录、单文件或 glob 模式均可，支持多条目
inputs = ["sqllogs"]
# 多条目示例：
# inputs = ["sqllogs/2025-01/*.log", "sqllogs/2025-02/*.log"]

说明： 自动化脚本中建议使用绝对路径。相对路径从当前工作目录解析。目录条目递归查找 .log 文件，结果按路径排序保证确定性顺序。旧版 path = "..." 字段已在 v1.12 移除，请迁移为 inputs = ["..."]。

[logging]

控制应用日志和错误日志行为。

[logging]
# 日志级别：trace、debug、info、warn、error
level = "info"
# 可选的解析失败错误日志文件
# file = "error.log"

说明： 生产环境建议设置 level = "warn" 以减少输出噪音。解析错误是非致命的，单独记录；单条记录解析失败不会停止整个导出。

[filter.include] 和 [filter.exclude]

记录级过滤：include 规则使用 AND 语义，exclude 规则使用 OR 否决。

[filter]
# 时间范围过滤（在 [filter] 级，不在 include/exclude 内）
start_ts = "2025-04-15 00:00:00"
end_ts = "2025-04-16 23:59:59"
max_record_limit = 0

[filter.include]
# 每条过滤规则是一组字段-值对（规则内使用 AND）
# 多条规则之间也使用 AND
USERNAME = "APP_USER"
# APPGROUP = "WEB"
# IP_ADDRESS = "192.168.1.100"

[filter.exclude]
# 任意单条 exclude 匹配即丢弃记录（OR 否决）
# STMT_TYPE = "SEL"
# USERNAME = "BATCH_USER"

说明： include 和 exclude 组合规则为 (include_AND) AND (NOT exclude_OR)。同一过滤规则内的所有字段使用 AND 语义。多条 include 规则之间也使用 AND。exclude 使用 OR 否决：任意匹配即丢弃记录。事务级指标和 SQL 内容过滤器使用两遍预扫描检测事务边界。

[exporter.csv]

CSV 导出配置。当 CSV 和 SQLite 同时配置时，CSV 优先级更高。

[exporter.csv]
# 输出 CSV 文件路径
file = "output/sqllog.csv"
# 覆盖已存在的文件
overwrite = true
# 列分隔符（默认 ","）
# delimiter = ";"
# 可选：按索引选择特定列（从零开始）
# ordered_indices = [0, 1, 3, 5, 7]

说明： CSV 使用 2 MB BufWriter + itoa 零分配整数格式化，实现约 520 万条记录/秒的吞吐量。ordered_indices 用于选择精确的列顺序和子集。为空表示所有字段按默认顺序输出。

[exporter.sqlite]

SQLite 导出配置。当 CSV 和 SQLite 同时配置时，SQLite 优先级较低。

[exporter.sqlite]
# 输出 SQLite 数据库路径
file = "output/sqllog.db"
# 目标表名
table = "sqllog_records"
# 删除并重建已存在的表
overwrite = true
# 可选：按索引选择特定列（从零开始）
# ordered_indices = [0, 1, 3, 5, 7]

说明： 使用批量 INSERT 配合 PRAGMA 优化（synchronous=OFF、mmap_size、cache_size），实现约 110 万条记录/秒的吞吐量。

附录：配置行为说明

导出器优先级

每次运行只有一个导出器处于活动状态。优先级：CSV > SQLite。当 [exporter.csv] 和 [exporter.sqlite] 都配置时，CSV 优先。移除或注释 CSV 节即可使用 SQLite。

处理管道快速路径

当没有启用任何过滤器时，整个处理管道通过单个 pipeline.is_empty() 检查绕过。这意味着可选功能在禁用时不会增加任何运行时开销。

配置验证

运行前使用 sqllog2db validate -c config.toml 检查配置。验证会一次性报告所有错误（而非遇错即停）。常见问题：缺少必填字段、无效路径、TOML 语法错误。

命令行子命令

sqllog2db 提供四个子命令：

sqllog2db init — 生成默认配置文件。支持 -o 指定输出路径、--force 强制覆盖。

sqllog2db validate — 校验配置文件。-c 指定配置文件路径，通过时静默退出（exit 0），失败时输出 [FAIL] <字段>: <原因> 并以非零码退出。

sqllog2db run — 执行日志导出。-c 指定配置文件路径，-v 详细模式，-q 静默模式。

sqllog2db stats — 统计分析。流式扫描日志文件，聚合慢 SQL 和高频 SQL。

• -c 指定配置文件路径（复用 [sqllog] 输入配置和 [exporter] 输出目录）
• --top N（默认 20）：每张表输出 Top N 条记录
• CSV 模式：在 [exporter.csv].file 同级目录输出 slow_sql.csv 和 frequent_sql.csv
• SQLite 模式：在配置的数据库中写入 slow_sql 和 frequent_sql 表

示例见快速入门指南。

字段顺序

各 TOML 节中的字段可以按任意顺序排列。配置使用 serde 反序列化，与顺序无关。可选节可以完全省略——所有字段采用默认值。

环境变量

• SQLLOG2DB_CONFIG — 设置默认配置文件路径（可被 -c 标志覆盖）
• NO_COLOR — 禁用彩色终端输出
• RUST_LOG — 使用 env_logger 时覆盖日志级别

架构说明

sqllog2db 是一个解析达梦数据库 SQL 日志并导出为 CSV 或 SQLite 的命令行工具。本文档描述项目的整体架构、数据流、模块划分和关键抽象。面向希望深入理解内部设计的开发者和贡献者。

数据流

工具的数据流分为四个阶段：发现 → 解析 → 管道处理 → 导出。以下 ASCII art 图展示了完整的数据流路径。

SQL 日志文件 (.log)
    ↓ SqllogParser — 文件发现与排序（src/parser.rs）
    ↓ dm-database-parser-sqllog — 逐行解析（外部 crate）
    ↓ Sqllog 记录
    ↓ Pipeline — 可选过滤器/处理器链（src/pipeline/）
    │ ├─ (空) ───────────────────── 零开销快速路径
    │ └─ FilterProcessor ────────── 过滤器处理
    ↓ ExporterManager — 路由到活跃导出器（src/exporter/）
    ▼
CSV 输出（src/exporter/csv/mod.rs）或 SQLite 输出（src/exporter/sqlite/mod.rs）

设计要点：

• 流式处理：记录逐行读取，内存占用恒定，不受文件大小影响——100 MB 和 100 GB 日志文件消耗相同的峰值内存。
• 当管道（Pipeline）为空（无过滤器）时，热循环通过 pipeline.is_empty() 检查跳过所有功能逻辑，实现零开销快速路径。

模块划分

项目按职责分为 4 大核心模块和若干支撑模块。

配置层 — src/config/

职责： 加载 TOML 配置文件，验证配置完整性。支持嵌套子表格式（v1.4+）。

关键抽象：

• Config：顶层配置结构，包含所有子配置段
• validate_and_compile()：验证配置并编译正则表达式

特性：

• 嵌套子表支持（v1.4+）：[filter.include]、[filter.exclude] 为顶级段
• 向后兼容：通过 RawFiltersFeature 中间结构支持旧版扁平格式

CLI / 编排层 — src/cli/

职责： 解析命令行参数，分派子命令，编排整体工作流。

结构：

• run/mod.rs — handle_run()：主编排逻辑（加载配置 → 构建管道 → 预扫描 → 流式导出）
• stats/mod.rs — handle_stats()：委托给 src/stats/run_stats()，流式扫描 → 聚合 → 写出
• init.rs — 生成默认配置
• validate.rs — 验证配置文件（通过时静默，失败时输出 [FAIL] 行）

模式： CLI handler 函数以 handle_ 为前缀（handle_run、handle_stats 等）。

Pipeline / 特性层 — src/pipeline/

职责： 实现可选的记录处理链——包括过滤器和 SQL 参数归一化。

关键抽象：

• LogProcessor trait：可插拔的记录处理接口，定义 process_with_meta() 方法
• Pipeline：记录处理器的有序链，is_empty() 判断是否需要处理

模式：

• 短路语义：任一 processor 返回跳过信号即停止链
• 零开销快路径：pipeline.is_empty() 检查避免热循环中不必要的函数调用

导出层 — src/exporter/

职责： 将已处理的记录写入目标后端（CSV 或 SQLite）。

关键抽象：

• Exporter trait：导出器接口，三阶段生命周期 initialize() → export_one_preparsed() → finalize()
• ExporterKind 枚举：静态分派（match）而非动态派发（Box<dyn Trait>），利于热路径内联

实现：

• CsvExporter：2 MB BufWriter + itoa 零分配整数格式化，~520 万条/秒
• SqliteExporter：批量 INSERT + PRAGMA 优化（synchronous=OFF、mmap_size、cache_size），~110 万条/秒

优先级： CSV > SQLite。同时配置时仅 CSV 生效。

支撑模块

关键抽象

Exporter trait + ExporterKind 枚举

输出后端接口定义。ExporterKind 使用静态分派（match 语句）替代动态派发（Box<dyn Trait>），编译器可以为热路径中每种变体生成优化的内联代码。三阶段生命周期（初始化 → 逐条写入 → 收尾）提供了清晰的资源管理边界。

LogProcessor trait + Pipeline

可插拔的记录处理链。每个 LogProcessor 实现 process_with_meta() 方法处理单条日志记录。Pipeline 将多个处理器串联为有序链。关键设计：is_empty() 允许在配置无过滤器需求时完全绕过管道，实现零开销。

FieldMask

u16 位掩码用于字段投影。16 个位对应 15 个输出字段（位 15 保留）。在整个管道中传递，控制每个字段是否被写入。提供 contains(index) 和 set(index) 方法，编译期内联。

性能设计

流式架构

单线程流式处理是核心性能策略。每条记录被解析后立即传递给管道和导出器，不存入内存。这意味着文件大小的增长不会影响峰值内存——无论 100 MB 还是 100 GB 的日志文件，内存曲线是平直的水平线。

零开销快路径

当没有配置任何过滤器时，热循环中的 pipeline.is_empty() 检查确保所有功能逻辑被跳过。此时记录不经处理直接流式写入导出器，性能接近裸文件复制的水平。

CSV 导出优化

• 2 MB BufWriter：大幅减少系统调用次数
• itoa 零分配整数格式化：整数直接写入缓冲区，无需分配中间字符串
• memchr SIMD 加速：字节搜索处理 CSV 转义，比逐字节扫描快数倍

编译优化

Release 构建采用激进优化：

• opt-level = 3：最高代码优化级别
• lto = "fat"：跨 crate 的链接时优化
• codegen-units = 1：单一代码生成单元，最大化内联机会
• panic = "abort"：移除恐慌展开代码
• strip = "symbols"：剥离调试符号

最终二进制文件约 5 MB，无外部运行时依赖。

基准性能

错误处理策略

分层错误类型

顶层 Error 枚举通过 thiserror 派生宏包含所有子错误变体：

• Config(ConfigError) — 配置加载和验证错误
• File(FileError) — 文件打开和读写错误
• Parser(ParserError) — 日志解析错误
• Export(ExportError) — 导出写入错误
• Io(io::Error) — 底层 I/O 错误
• Interrupted — 用户中断（Ctrl+C）

每个子错误变体包含上下文字段（path: PathBuf、reason: String），而非裸字符串，便于故障排查。

非致命解析错误

解析失败不会中断整个导出过程。无法解析的行被记录到错误日志文件（配置中的 [error] file），工具继续处理下一行。在运行结束时汇总各文件的解析成功率。

退出码

依赖关系

模块间的依赖遵循单向分层原则：

src/error.rs ←──────────────── 所有模块（横切关注点）
src/config/ ←─ src/cli/ ←─ src/pipeline/ ←─ src/exporter/

配置层（config）被 CLI 层引用，CLI 层协调 Pipeline 和 Exporter 的具体实例。

架构文档最后更新于 v1.13，反映 stats 子命令引入后的模块结构。模块级概述，不深入特定 struct 字段或 trait 方法签名。

贡献指南

欢迎为 sqllog2db 做出贡献！本指南将帮助你搭建开发环境、了解编码规约、掌握 Pull Request（拉取请求）流程和 commit（提交）规范。

开发环境搭建

前置要求

• Rust 工具链：通过 rustup 安装。项目最低支持 Rust 版本（MSRV）为 1.85+。

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

• Git：用于克隆仓库和版本控制。

克隆仓库

git clone https://github.com/guangl/sqllog2db
cd sqllog2db

构建与运行

# 构建（Release 模式）
cargo build --release

# 运行测试
cargo test

# 生成默认配置文件
cargo run -- init -o config.toml --force

# 验证配置
cargo run -- validate -c config.toml

# 运行导出
cargo run -- run -c config.toml

辅助工具

• lychee：用于检查文档中的死链（CI 中使用）。安装：cargo install lychee
• rsvg-convert：用于 SVG 渲染验证（macOS: brew install librsvg，Linux: apt install librsvg2-bin）

编码规约

命名规范

代码风格

• 格式化：使用 cargo fmt（rustfmt 默认配置），CI 中强制检查。
• Lint：必须通过 cargo clippy --all-targets -- -D warnings，零警告。
• Import 顺序：std → 外部 crate → 内部模块（crate::、super::）。
• 函数长度：每个函数不超过 40 行。超过时拆分为更小的函数。
• 尾逗号：多行 struct/enum 字面量使用尾逗号。

常用属性

• #[inline] — 用于热路径方法：write_record_preparsed、export_one_preparsed
• #[must_use] — 用于返回有意义值的纯函数：new()、from_config()
• #[derive(Debug)] — 所有公共类型必须实现
• #[expect(clippy::lint_name, reason = "...")] — 用于对特定 lint 做有理由的例外（优先于 #[allow]）

错误处理

• 使用 thiserror 派生宏定义类型化错误，错误变体包含路径和原因的上下文信息。
• 项目使用 pub type Result<T> = std::result::Result<T, Error> 统一错误类型。
• 解析错误是非致命的：写入错误日志文件后继续处理下一条记录。
• 使用 ? 操作符在函数间传播错误。

注释

• 中文注释：用于达梦数据库相关的领域概念和性能优化说明。
• 英文文档注释（///）：用于公共 API（struct、trait、方法）。
• 性能相关的设计决策使用行内注释说明。

PR 流程

1. Fork 本仓库，从 main 分支创建功能分支。
2. 在你的分支上进行修改。
3. 提交前确保通过以下所有检查：

cargo clippy --all-targets -- -D warnings
cargo fmt --check
cargo test
cargo build --release

4. 如果是新功能或 bug 修复，建议在 tests/ 目录或模块内联测试块中增加对应的测试用例。
5. 推送分支并发起 Pull Request。
6. 在 PR 描述中说明修改内容、动机和测试情况。
7. CI 将自动运行 clippy、fmt 检查、测试和文档死链检查（lychee），全部通过后方可合并。
8. 维护者审核后合并。

Commit 规范

本项目使用 Conventional Commits（约定式提交）格式。CHANGELOG.md 遵循 Keep a Changelog 格式自动生成。

提交消息格式

<type>(<scope>): <简短描述>

<详细说明（可选）>

Type（类型）

Scope（范围）

使用受影响的模块或文件作为范围：filters、exporter、config、cli、charts、pipeline、README 等。

示例

feat(filters): add regex include for user field
fix(exporter): handle empty CSV output directory
docs(README): update installation instructions
refactor(config): extract validate_and_compile from from_config
test(charts): add edge case tests for empty histogram
chore(ci): add lychee link checker to CI pipeline

其他约定

• 提交消息使用英文撰写。
• 第一行（标题）不超过 72 个字符。
• 标题以动词原形开头（"add" 而非 "added"）。
• 关联 issue 时在正文中使用 Closes #123 或 Refs #456。

本指南在 Phase 25 中编写，如有改进建议请通过 PR 提交。

安全策略

sqllog2db 是一个达梦数据库 SQL 日志解析命令行工具。我们重视用户和社区的安全，对安全漏洞采取严肃态度。本页面说明如何报告漏洞以及我们的处理流程。

支持版本

我们仅支持最新稳定版本。旧版本可能存在已知漏洞，建议尽快升级到最新版。

你可以在 crates.io 或 GitHub Releases 查看当前最新版本。

报告漏洞

如果你发现了安全漏洞，请通过以下任一方式私密报告，切勿在公开 issue 中披露。

首选方式：GitHub Security Advisory

通过 GitHub Security Advisory 提交漏洞报告是最推荐的方式：

1. 访问 安全公告页
2. 点击 "Report a vulnerability"
3. 填写漏洞详情并提交

使用 Advisory 的好处：

• 私密提交：仅维护者可见，修复公开前不会泄露
• CVE 分配：GitHub 可自动为符合条件的漏洞分配 CVE 编号
• 自动通知：维护者会立即收到通知

建议提供的信息：

• 漏洞简要描述
• 影响版本
• 复现步骤（包含具体的命令和环境）
• 预期行为与实际行为的差异
• 建议的修复方案（如有）

备选方式：邮箱报告

如无法使用 GitHub Advisory，可通过以下邮箱报告：

安全邮箱： [请替换为实际安全邮箱]

建议使用 GPG 加密通信。如果你有 GPG 公钥需求，请先在 issue 中请求。

响应承诺

严重程度分级

安全更新流程

1. 漏洞被私密报告并验证
2. 维护者开发修复补丁
3. 发布包含安全修复的新版本（补丁版本号递增）
4. 在 CHANGELOG.md 中标注安全修复（### Security 小节）
5. 在 GitHub Advisory 上公开披露
6. 修复前的漏洞细节在 CVE 分配和补丁发布之前不会公开

工具依赖安全

sqllog2db 依赖 Rust 生态中的外部 crate。我们通过以下方式管理依赖安全：

• CI 流水线会检测 Rust 安全公告（RustSec）
• 建议用户保持工具更新到最新版本
• 如发现依赖 crate 中的漏洞，在工具层面会尽快修复或缓解

如有其他安全问题或疑虑，请通过上述方式联系维护者。