kuanat
2023-12-10 04:57:25 +08:00
我大概试了一下网站，没感觉查询有什么特别慢的地方。如果要定位慢查询的问题，最好贴上语句和配置信息什么的看一下。
在不改变技术框架的情况下，优化方案就是加索引。再具体一点，这个索引是要能通过用户输入的关键词，快速定位到特定字段包含关键词的数据集。
这里涉及到两个主要的技术点，一个是对文本字段进行分词，提取出关键词。另一个是通过关键词反查数据集，这个要构建的索引叫倒排索引（ inverted index ）。剩下的事情就是更改查询逻辑，前端查询请求走索引，后端直接取索引筛选出的数据集。（这个索引可以做到后端应用程序里，也可以保存到数据库里）
考虑到楼主非专业开发，我是建议手动做上面的事情。用其他的成熟方案，需要学习的东西其实更多，原理理解不到位的话很可能达不到效果，而且没有必要。
如果是我来做这个事情的话，可能会采取完全不同的方案，楼主可以参考一下。
因为这个数据库基本上是只读不写的，写场景基本只发生在数据修正或者批量更新的时候。所以优化的核心思路就是数据集（数据库）为查询优化。
虽然楼主没有透露这个数据库的表结构，考虑到万智牌大概就几万张，而数据集大概有 10 万条，这个数据库应该是冗余很低，符合范式的设计方式。
这一类数据库是为写操作和存储优化的，冗余很低，提取数据需要对数据表做组合查询。为读操作和查询优化的数据库正好相反，冗余很高。既然最终查询结果是卡牌集合，那就以某种数据结构来记录每张卡牌包含的所有信息，一次读取即可获得完整数据，省去了数据组合的过程。
即便有大量的冗余，内存中以这种数据结构存储卡牌信息，可能不会超过 4GB ，即使再翻个倍也不是问题。那对于查询系统来说，有没有 sql 数据库都不重要了。
当然 sql 对于数据录入还是很有意义的，一方面可能本身数据来源导入比较方便，另一方面修改低冗余数据远比高冗余数据方便。所以这里需要编写个脚本，在每次 sql 数据库更新之后，重新生成一份通用格式的（比如 csv 或者 json ）的数据集，后端应用程序反序列化之后即可获得上述的内存数据库。
上面这些如果用技术语言描述，就是 sql 转 kv/nosql ，没有多少技术难度，就是个经验问题。
剩下的事情都差不多，分词、建索引。主要是一些经验层面的优化，这里就随便列举几个。
比如请求是可以缓存的，一般用在高频查询和分页上。再比如具体到这个查询场景说，一个请求如果需要返回几百个数据，要么不合理要么没必要。（人一般不需要这么多，返回太多都是在给爬虫服务了。）