如何判断查询是否可以很好地扩展？

慕阳文

2023-03-14

问题内容：

有经验的SQL开发人员可以使用哪些方法/技术来确定特定的SQL查询是否会随着负载的增加，关联表中的行的增加等而很好地扩展。

问题答案：

我遵循的一些规则最重要。

不要在你的查询，如使用每排功能if，case，coalesce等等。通过将数据放入您需要的格式的数据库中来解决它们，即使这涉及重复的数据。

例如，如果您需要快速查找姓氏，则以输入的形式和小写形式存储它们，并索引小写形式。这样您就不必担心诸如此类的事情select * from tbl where lowercase(surname) = 'smith';

是的，我知道这会破坏3NF，但是您仍然可以通过明智地使用触发器或预先计算的列来保证数据完整性。例如，表上的插入/更新触发器可以强制将lower_surname列设置为的小写版本surname。

这会将转换成本转移到insert/update（很少发生），而从select（发生更多）。您基本上会摊销转换成本。

确保where子句中使用的每个列都已建立索引。不一定要单独使用，但至少要作为组合键的主要部分。

始终从3NF开始，只有在性能问题（ 生产中 ）时才还原。3NF通常是最容易处理的，只有在绝对必要时才应执行还原操作。

生产中的配置文件（或其他位置，只要您具有生产数据和模式）。除非表中的数据永不更改（非常少见），否则数据库调整不是“一劳永逸”的操作。您应该定期进行监视，并可能进行调整，以免发生更改数据会降低性能的可能性。

除非绝对必要，否则请勿对您的数据库进行裸查询。尝试控制可以运行哪些查询。如果有一些经理可以加入并开始工作，那么您作为DBA的工作将变得更加困难：

select * from very_big_table order by column_without_index;

在您的数据库上。

如果经理希望能够运行即席查询，请为他们提供一个克隆的DBMS（或副本），以使您的实际用户（需要性能的用户）不受影响。

不要使用union何时union all就足够了。如果知道联合的两个选择之间没有重复项，那就没有必要让DBMS尝试删除它们。

同样，select distinct如果要检索所有主键列（或唯一约束中的所有列），请不要在表上使用。有没有
在这种情况下重复的可能性，所以，再一次，你问的DBMS做不必要的工作。

示例：我们有一个客户select distinct *在其一张桌子上使用了视图。查询视图花费了50秒钟。当我们用开始视图替换它时select *，时间降到了亚秒级。不用说，我从中得到了一瓶红酒:-)

尽量避免select *。换句话说，仅获取所需的列。当您在本地PC上使用MySQL时，这几乎没有什么区别，但是，当加利福尼亚州有一个应用程序查询内蒙古的数据库时，您希望最大程度地减少通过网络发送的流量。