如何判断查询是否具有良好的伸缩性?

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

不要 在查询中使用每行函数,例如 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 * 时间降到了秒以下。不用说,我从中得到了一瓶好酒。

尽量避免 选择* 尽可能多。换句话说,只获取所需的列。当您在本地PC上使用MySQL时,这几乎没有什么区别,但是,当您在加利福尼亚州有一个应用程序在查询内蒙古的数据库时,您希望尽可能减少通过线路发送的流量。

不要使表变宽,使它们和索引一样窄。确保索引完全覆盖了查询,并且这些查询是可搜索的。

在投入生产前,用大量数据进行测试,看看这个: Your testbed has to have the same volume of data as on production in order to simulate normal usage

拉起执行计划,寻找以下任何一项:

• 表扫描
• [聚集]索引扫描
• RID查找
• 书签查找
• 键查找
• 嵌套循环

其中任何一项(按从大到小的降序排列)都意味着数据库/查询可能 不会 缩放到更大的表。理想的查询主要有索引查找、哈希或合并联接、偶尔的排序和其他低影响操作(假脱机等)。

唯一能证明这一点的方法 将 正如其他答案所指出的,量表是在所需大小的数据上进行测试。以上只是一个经验法则。

向它抛出一个数据的sh*tload,并进行概要分析。

并确保它遵循索引、模式设计等方面的最佳实践。

除此之外(并沿着相同的路线),考虑罗伯特的建议,执行计划。它是否使用索引?有没有扫描之类的?你能以任何方式简单地查询吗?例如,消除 IN 赞成 EXISTS 只和你一起吃饭 需要 加入

您没有提到技术——请记住,不同的技术可能会影响更复杂查询的效率。

我强烈建议阅读一些关于这方面的参考资料。这个(下面的超链接)可能是一本不错的书。在其他主题中,一定要注意“选择性”。

SQL Tuning - Dan Tow