简介

最近搞一个 LLM 聊天的后端，其中对于聊天记录的存储形式是在一个 MySQL 的表中存储，每条历史有一个 history_id，json（存储具体历史记录），创建时间等。

这样的设计对于纯文本来说没有什么问题，但是如果涉及到多种文件格式就有点头疼。那么我想着分为两个表，一个表用来存储 history_id 和时间等信息，但是没有具体内容；另外一个表存储具体消息，每个消息都有一个 message_id 和相应的 history_id。

如果要查询一个历史中的消息，第一种设计只需要根据相应的 history_id 就能够获得所有的消息，第二种就需要通过 history_id 去找所有有相同 history_id 的消息。

对于第二种设计虽然让存储多种消息类型更加方便，但是不知道这样查询会不会慢，所以就将这部分功能简单剥离出来做了本次测试。

代码

具体代码放到了 github 中。

测试情况

为了模拟大量历史消息，写了一个向数据库中写入消息的脚本。

预计 500 条历史，每个历史中 20 条消息。

写完后再用第二个脚本去获得所有历史消息，分别记录查询用时进行对比。

• 单表

首先是单表的情况，一共 500 条历史，每个历史 3-7 条消息。

查询总耗时: 53.25秒

• 多表

然后是多表的情况，一共 500 条历史，每个历史 20 条消息。

查询总耗时: 54.19秒

总结

之后反复尝试了几次，两种方式查询的时间基本相同，但是有一个问题，单表每个历史只有 3-7 条消息。

这个并不是我特意调整的，而是意外发现在高并发的情况下预计的 20 条消息中有一半以上没有正常写入。

因此引出第二组数据，写入时间：

单表脚本写入总耗时: 54.56秒

多表脚本写入总耗时: 76.97秒

虽然多表的情况多耗了 20 秒，但是基本全都写入成功了，所以还是采用第二种方式更好一些。

这次测试有很多不足之处，比如没有确保变量完全相同，也没有多次测试以及调整消息数量测试，但大体可以作为参考了。

至于没有成功写入的问题，有可能是脚本代码有问题，也可能是别的，依旧有待考证。