---
notion-id: 1bcca4d7-cb7b-80e9-bc5f-c148d9dc376b
---
从表名和字段来看，`wiz_kb`（知识库表）和`wiz_document`（文档表）之间应该是通过`KB_GUID`字段关联的。
让我们看看这两个表之间的关系：
1. `wiz_document`表中有：

```sql
`KB_GUID` binary(16) NOT NULL COMMENT '知识库GUID'
```
2. 我们可以用以下SQL查询来确认两个表的关系：

```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`约束可以看出

为了更好地帮助您理解这两个表的关系，建议您：
3. 确认`wiz_kb`表的具体结构
4. 告诉我您想了解的具体业务场景

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

现在我明白了问题所在。从表结构可以看到，`KB_GUID`列的数据类型是`binary(16)`：
```sql
`KB_GUID` binary(16) NOT NULL COMMENT '知识库GUID'

```
这就解释了为什么您看到的是乱码。这是因为：
5. GUID/UUID 是以二进制格式存储的，直接查看二进制数据自然会显示为乱码
6. 正确的做法是在查询时将二进制数据转换为可读的十六进制字符串

要正确查看 KB_GUID 的值，您可以使用以下 SQL 查询：
```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 的标准和高效方式，只是需要用正确的方式来显示它。

```javascript
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的对应名称
```