Join 关系代数连接优化

我在学校的教科书中看到，许多联接操作似乎从未优化联接右侧的表，而只是在左侧。

---

例如，要查找管理数据库部门的员工的姓名，您可以这样做：
大多数优化器使用只考虑左深联接的系统优化器。这就是为什么你永远看不到右边的连接

所有选项的搜索空间都是指数型的，因此优化器希望快速找到合理可接受的解决方案（优化器不会找到最佳解决方案，而是尽量避免最坏的解决方案）

---

另外，使用左深联接的原因是，它允许在不需要将结果写入磁盘的情况下对结果进行管道化，从而节省I/O。

任何合适的查询优化器都会降低适当的限制，有时还会降低预测，以最小化要处理的数据。因为优化器会自动执行，并且结果是相同的，所以不需要在关系代数中优化表达式

在这样的两表连接序列中，在与部门连接之前形成投影是否有好处还不清楚；可能的处理顺序是查找Dname为'Database'的（可能是单个）部门，然后在Employee中查找E.SSN=D.Mgr\u SSN的单行。但是，如果子表达式被多次使用，它可能很值得一做

---

我还注意到，这种设计很糟糕——在数据库设计中，永远不要使用像SSN这样敏感的连接字段。PCI团队可能会有麻烦！但也许这些名字是很久以前温和时代的遗留物，但内容是生成的代理，真正的SSN存储在Employee.RealSSN中（这甚至可能被加密，以确保未经授权的人看不到它-尽管在列上正确设置权限以便只有授权的人可以选择它也是有效的）。

自System R prototype发布以来，优化器取得了进步。