是否有任何工具集/技术来确定 SQL 查询在功能上是否相同?

发布于 2024-09-27 03:55:30 字数 460 浏览 2 评论 0原文

我从客户端收到 SQL 查询,其中包含由 MS Access 中的构建器生成的各种冗余子 SELECT。我将 SQL 转换为 Postgres,并且它可以运行 - 但我知道它的效率低得令人绝望。因此,我开始优化查询,并进行迭代改进 - 为了确定每个新查询在功能上是否相同,我运行它并确保它产生相同的结果集。

当然,这在确定一个查询是否与另一个查询是否相同方面并不是 100% 有效 - 它依赖于探索每种不同情况的数据。一位同事建议我可以对每个查询运行一个解释计划,但他承认内部数据库优化器可能会采用不同的查询策略,即使新的查询在功能上是相同的(这是一件好事 - 新策略可能会更有效) )。

我至少拥有中级 SQL 技能,但我不是一个自信的查询优化者。因此,我对任何可以 100% 确定两个查询执行相同操作的 Postgres 工具集感兴趣。如果它本身可以建议优化就更好了!我相信 TOAD 可以做到这一点,但我不相信它适用于 Postgres。我使用的是 Mac OS X。

From a client I receive SQL queries that contain all sorts of redundant sub-SELECTs, generated by a builder in MS Access. I convert the SQL to Postgres, and it runs - but I know it's hopelessly inefficient. So, I set about optimising the query, and produce iterative improvements - and to determine whether each new query is functionally identical, I run it and ensure it produces the same resultset.

This, of course, is not 100% effective at determining whether one query is the same as another - it relies on the data exploring every different case. A colleague suggests I could run an explain plan over each query, but concedes that the internal db optimiser may employ a different query strategy even though the newer query is functionally identical (and this is a good thing - the new strategy may be much more efficient).

I have at least intermediate SQL skills, but am not a confident query optimiser. So, I'd be interested in any toolset for Postgres that can say with 100% certainty that two queries do the same thing. Even better if it can suggest optimisations itself! I believe that TOAD can do this, but I don't believe it is available for Postgres. I'm on Mac OS X.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

热血少△年 2024-10-04 03:55:30

很好的问题。要求很高。

如您所知,存在逻辑相同的程度。然后是生成相同计划的级别,即需要哪些表访问以及以什么顺序访问。

最后,将这些底层计划与表中数据的分布进行比较,以确定是否在表上使用给定索引,并且缓存数据页的使用也将发挥作用。 (30,000 英尺的描述,我知道)

如果您的问题仅限于“在同一数据集上执行相同的操作”,那么比较 EXPLAIN 计划就足够了,并且将包含逻辑相同性和某种程度的 I/O 相同性。

Great question. Tall order.

As you know there's the level of being logically identical. Then there is the level of generating identical plans as far as which table accesses are required and in what order.

Lastly those underlying plans are compared to the distribution of data in the table to determine whether or not to use a given index on a table, and the use of cached data pages comes into play as well. (30,000 foot description, I know)

If your question is limited to 'perform identically on the same dataset', then comparing EXPLAIN plans would be sufficient, and would encompass both logical identicality and some level of I/O identicality.

小瓶盖 2024-10-04 03:55:30

您可以尝试在 MySQL 上使用 TOAD 来分析查询。改进查询后,将其移植到 PostgreSQL。

You could try using TOAD on MySQL to analyze the query. Once you improve the query, port it over to PostgreSQL.

旧时模样 2024-10-04 03:55:30

假设您正在改进 PostgreSQL 查询,当然已经使用 pgTap(PostgreSQL 单元测试)为 PostgreSQL 编写了查询,这是毫无疑问的。您可以测试查询运行的时间以及它返回的结果等。
http://pgtap.org/

Assuming your are improving a PostgreSQL query that is of course already written for PostgreSQL use pgTap (Unit Testing for PostgreSQL), no question about it. You can test for how long a query runs and the results it returns among other things.
http://pgtap.org/

满地尘埃落定 2024-10-04 03:55:30

升级到 PostgreSQL 9.0 或更高版本。

来自 9.0 发行说明

  • 针对特定类型查询的多项性能增强,包括消除不必要的连接。这有助于优化一些自动生成的查询,例如由对象关系映射器 (ORM) 生成的查询。

Upgrade to PostgreSQL 9.0 or later.

From 9.0 release notes:

  • Multiple performance enhancements for specific types of queries, including elimination of unnecessary joins. This helps optimize some automatically-generated queries, such as those produced by object-relational mappers (ORMs).
摘星┃星的人 2024-10-04 03:55:30

我会说不。然而,在给定适当索引的情况下,来自 access 的查询在 postgres 中不应表现得更差。

您可能会认为查询速度较慢,因为 msaccess 通常返回部分结果,并且只有在浏览数据集时才继续执行查询,而 postgres 通常会运行整个查询(当然取决于您使用的客户端)。

I would say no. However queries from access should not perform worse in postgres given proper indexes.

You might percieve the queries as slower as msaccess normally returns partial results and only on browsing the dataset continues to execute the query where postgres would normally run the whole query (depending of course on the client you use).

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文