数据库中实现二叉搜索树（BST）的重要性及是否需自行实现？

核心结论：绝大多数业务场景下，完全不需要用编程语言手动实现BST，具体原因和细节如下：

1. 数据库内置了更高效的索引结构 #

像PostgreSQL这类关系型数据库，底层已经实现了比基础BST更适配磁盘存储的索引结构——B树（B-Tree）。它是BST的优化变种，专门针对大规模数据的磁盘读写做了优化，能高效支撑CRUD操作。当你在Django模型里给字段设置db_index=True，或者定义唯一约束时，PostgreSQL会自动创建B树索引，底层的树结构维护完全由数据库负责。

2. ORM已封装好索引逻辑 #

以Django的ORM为例，你只需要在模型中通过models.Index、unique=True等参数声明索引需求，ORM会自动生成对应的SQL语句，让数据库完成索引的创建和维护。你完全不需要关心底层是B树还是其他结构，只需专注业务逻辑开发。

3. 自行实现BST的明显弊端 #

• 性能不足：应用层实现的BST通常基于内存存储，数据量增大后会占用大量内存，且服务重启后数据会丢失；同时，自行处理磁盘IO的效率远不如数据库原生索引。
• 维护成本高：要自己解决树的平衡（如AVL树、红黑树）、并发安全、数据持久化等问题，这些都是数据库已经成熟解决的问题，重复造轮子只会增加bug和维护负担。

仅有的特殊场景 #

只有当你有高度定制化的内存数据需求，且数据量小、不需要持久化时，才需要考虑自行实现BST或其变种，但这类场景在常规数据库存储业务中极少出现。

内容的提问来源于stack exchange，提问作者anoop george