obsidian/技术支持/为知笔记/为知笔记数据库关系.md

---

notion-id: 1bcca4d7-cb7b-80e9-bc5f-c148d9dc37

从表名和字段来看，wiz_kb（知识库表）和wiz_document（文档表）之间应该是通过KB_GUID字段关联的。 让我们看看这两个表之间的关系：

1. wiz_document表中有：

   `KB_GUID` binary(16) NOT NULL COMMENT '知识库GUID'
   

2. 我们可以用以下SQL查询来确认两个表的关系：

   SELECT
   k.*,
   COUNT(d.DOCUMENT_GUID) as document_count
   FROM wizasent.wiz_kb k
   LEFT JOIN wizksent.wiz_document d ON k.KB_GUID = d.KB_GUID
   GROUP BY k.KB_GUID;
   

这是一个典型的一对多关系：

• 一个知识库（wiz_kb）可以包含多个文档（wiz_document）
• 每个文档（wiz_document）必须属于一个知识库（wiz_kb），这从KB_GUID字段的NOT NULL约束可以看出

为了更好地帮助您理解这两个表的关系，建议您：

1. 确认wiz_kb表的具体结构
2. 告诉我您想了解的具体业务场景

这样我可以提供更详细的分析和查询示例。

现在我明白了问题所在。从表结构可以看到，KB_GUID列的数据类型是binary(16)：

`KB_GUID` binary(16) NOT NULL COMMENT '知识库GUID'

这就解释了为什么您看到的是乱码。这是因为：

1. GUID/UUID 是以二进制格式存储的，直接查看二进制数据自然会显示为乱码
2. 正确的做法是在查询时将二进制数据转换为可读的十六进制字符串

要正确查看 KB_GUID 的值，您可以使用以下 SQL 查询：

SELECT
    HEX(KB_GUID) as KB_GUID_HEX,
    -- 或者使用更易读的格式
    CONCAT(
        LOWER(HEX(SUBSTR(KB_GUID, 1, 4))), '-',
        LOWER(HEX(SUBSTR(KB_GUID, 5, 2))), '-',
        LOWER(HEX(SUBSTR(KB_GUID, 7, 2))), '-',
        LOWER(HEX(SUBSTR(KB_GUID, 9, 2))), '-',
        LOWER(HEX(SUBSTR(KB_GUID, 11, 6)))
    ) as KB_GUID_FORMATTED
FROM wiz_document;

这样查询的结果将会是：

• KB_GUID_HEX 会显示类似：550E8400E29B41D4A716446655440000
• KB_GUID_FORMATTED 会显示类似：550e8400-e29b-41d4-a716-446655440000

这不是乱码问题，而是正常的数据存储方式。binary(16) 是存储 GUID/UUID 的标准和高效方式，只是需要用正确的方式来显示它。

SELECT
    wizk.*,
    CONCAT(
        LOWER(HEX(SUBSTR(KB_GUID, 1, 4))), '-',
        LOWER(HEX(SUBSTR(KB_GUID, 5, 2))), '-',
        LOWER(HEX(SUBSTR(KB_GUID, 7, 2))), '-',
        LOWER(HEX(SUBSTR(KB_GUID, 9, 2))), '-',
        LOWER(HEX(SUBSTR(KB_GUID, 11, 6)))
    ) AS KB_GUID_FORMATTED
FROM
    wiz_document wizk
WHERE
    DT_CREATED BETWEEN '2025-01-01 00:00:00' AND '2025-03-19 00:00:00'
HAVING
    KB_GUID_FORMATTED = '299eccd0-70b1-11ef-8686-e9aeab186b47';
    
    通过获取kb的对应名称