Fix for slow query on MS SQL

[boring-joey]

What's changed:

• Resolved performance issue related to long-running queries in Azure SQL Database.
• Simplified conditions in SQL queries to improve execution times.
• Added optimization steps for better handling of schema updates in Directus.

Potential Risks / Drawbacks

• Changes in SQL query handling might affect other parts of the system that rely on similar queries.

Review Notes / Questions

• Please review the changes made to SQL query conditions and confirm they do not impact other functionalities.
• Special attention should be paid to the handling of NULL values and the use of temporary tables for intermediate results.

Fixes #19486

You can review the related issue here.
#19486

[changeset-bot]

⚠️ No Changeset found

Latest commit: 64bdde8

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[nickrum]

If I understand it correctly, this completely removes the check which ensures that is_primary_key and is_unique are only set if index_column_count and index_priority are either 1 or NULL. Can we really drop that?

My best guess for the slow query is that using a function and a comparison, that does not establish a relation between the joined tables, inside the ON expression of a join somehow hits a slow path in Azure. Maybe moving the check into the subquery would help.

[boring-joey]

@nickrum, is this something the Directus team will investigate further, or would you like me to look into it more? I noticed the issue has been moved to 'ready,' so I'm curious about the status.

[jaads]

I'm currently looking into it. I cannot reproduce the issue but that's only because I don't have a big and complex enough schema in my ms sql database. we're currently thinking about how we can spin up an arbitrary schema to do performance tests for introspection but right now it's tricky / time consuming.

But I can confirm that the query in this PR does not return the same result as the current one. The one in this PR returns more records. I'll have to investigate now that this does not introduce any other problem.

However, the fact that the PR does not introduce any additional integration tests to fail is a good sign that we can use the updated query :)

[jaads]

I compared the query results further and noticed that the is_primary_key and is_unique are not correct. so unfortunately, we cannot use the updated query as it is right now

[jaads]

as described above