Question

SQL开发人员使用哪些方法/技术来确定特定SQL查询是否会随着负载增加，相关表中的行数增加等而扩展。

Answer 1

我遵循的一些规则会产生最大的不同。

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

例如，如果您需要快速查找姓氏，请将它们以小写形式存储在输入的表单和中，并将小写形式编入索引。那你就不必担心像select * from tbl where lowercase(surname) = 'smith';

这样的事情了

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

这会将转化成本转移到insert/update（不经常发生）并远离select（发生的情况要多得多）。您基本上可以分摊转换成本。

确保将where子句中使用的每个列编入索引。不一定是自己的，但至少作为复合键的主要部分。

始终以3NF开始，只有在遇到性能问题时才会恢复（ in production ）。 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时，这几乎没什么区别，但是当您在加利福尼亚州有一个应用程序查询内蒙古的数据库时，您希望尽可能减少通过线路发送的流量。

Answer 2

不要使表格宽，保持它们和索引一样窄。确保索引完全覆盖查询，并且这些查询是SARGable。

Answer 3

拉出执行计划并查找以下任何内容：

任何这些事情（从大多数到最不可扩展的降序）意味着数据库/查询可能不会扩展到更大的表。理想的查询主要包括索引搜索，散列或合并连接，偶尔排序以及其他低影响操作（假脱机等）。

正如其他答案所指出的那样，证明将扩展的唯一方法是在所需大小的数据上进行测试。以上只是一条经验法则。

Answer 4

此外（并沿着同样的路线）罗伯特的建议，考虑执行计划。它是否使用索引？有没有扫描等？你能以任何方式简单地查询吗？例如，消除IN支持EXISTS并仅加入您需要加入的表格。

您没有提及该技术 - 请记住，不同的技术会影响更复杂查询的效率。

Answer 5

我强烈建议您阅读一些参考资料。这（下面的超链接）可能是一本非常好的书。请务必查看“选择性”以及其他主题。