If query entity rule is slow, how do you analysis and improve the performance of it?

When a query rule is slow I check four things in order: where the rule is used, how many rows it returns, which columns it returns, and whether the table is indexed for the filter.

Check where the rule is used

Before touching the query I look at the interfaces, expressions and process models that call it and confirm what data each caller needs. A rule written for a grid and later reused to fetch one value returns far more than the second caller needs. If a caller needs a single value or record, I change the query for that case instead of returning the full dataset.

Limit rows with pagination

Returning rows nobody reads is the most common cause. Every query gets a pagingInfo, batchSize: -1 is used only when there is a real reason, and the batch size matches what the caller shows.

Example that fetches one record:

The database returns one row instead of the table.

Return only the columns you need

Many slow queries return every column when the caller uses two or three. I pass the wanted columns as a rule input and build the selection from it, so one rule serves several callers without over-fetching.

Add an index

If the slow part is a filter on one column, username for example, an index on that column usually fixes it.

If the data source is a view

The same steps apply, plus the view itself.

Simplify the view

1. Remove filters and joins the UI does not need
2. Keep heavy calculations out of sub-queries
3. Push heavy logic down to the database where possible

Fix the joins

1. Drop joins whose columns the UI never shows
2. Change LEFT JOIN to INNER JOIN when the business rules allow it
3. Index the join columns

In short: find out what the callers need, then page the rows, trim the columns, simplify the joins, and index the columns you filter on.