zmuxuny opened a new issue, #7164: URL: https://github.com/apache/rocketmq-dashboard/issues/7164
### Before Creating the Bug Report - [x] I have searched the [open issues](https://github.com/apache/rocketmq-dashboard/issues) of this repository and believe that this is not a duplicate. - [x] This is a defect in RocketMQ Studio, not a usage question and not a defect in another Apache RocketMQ repository. - [x] I can reproduce this on the current `master` branch, or I have stated the exact version I am running below. ### Studio Version rocketmq-studio@127c47b06a268cc74224d5f34c56ec7c36ac0d55 ### Runtime Environment Linux, Java 21, H2 2.4.240 in MySQL mode. Synthetic in-memory database using the current rmq_system_alert schema; no live database or broker. ### Connected RocketMQ Cluster Not required to reproduce the repository query. The normal successful native collector path reaches this query for registered instances. ### Build Toolchain Standalone JDBC fixture with an existing H2 dependency and a 128 MiB Java heap. This is not a full Maven/production performance benchmark. ### Describe the Bug MybatisPlusAlertStateRepository.findLatestAlerts needs the latest instance/labels for each active (rule_id, fingerprint), but selectList loads every matching historical event and all columns, orders them by time DESC, id DESC, and only then reduces them in Java. NativeAlertProcessor calls findActive on ordinary successful collections before skipping resources that are still present. Repeated REMINDER events and prior episodes therefore increase JDBC transfer and entity allocation on every reconciliation pass. rmq_system_alert has no automatic retention bound; snapshot/outbox cleanup does not delete these events. ### Steps to Reproduce 1. Create the current rmq_system_alert table in an isolated H2 MySQL-mode database. 2. Seed two active keys with 1,000 events each, plus same-time/older-time/null-time, unrelated-key and other-scope controls. Request five exact active keys, one with no event. 3. Execute the current query shape: SELECT * WHERE rule_id IN (...) AND fingerprint IN (...) AND domain=? AND instance_id=? ORDER BY time DESC,id DESC. Count returned rows before the existing Java first-per-key reduction. 4. Repeat with 2,000 historical events per live key. The selected latest metadata is unchanged in meaning, but all old payloads are loaded again. ### What Did You Expect to See? Return only the newest metadata row for each requested key, preserving time DESC/id DESC, domain and instance isolation, and missing-event behavior. Keep batching; a global LIMIT is not correct because one key can consume the whole limit. ### What Did You See Instead? Measured baseline rows: 2,008, then 4,008. Only four keys have relevant metadata. A candidate ROW_NUMBER partition-by-key query returns four rows at either history size and selects the same winners, including timestamp ties/nulls. In this fixture, the old description+labels values total 2,088,320 and 4,168,320 characters versus 64 label characters for the selected metadata. These are character counts, not measured network bytes or a production latency/OOM claim. A global LIMIT 5 control incorrectly represents only two keys. ### Additional Context Related #2688/#2957 introduced one batch query to avoid N+1 but retain the all-history result. #2964 handles outbox retention/snapshot indexes/silence queries, #6195 bounds the public alert list, and #7021 handles clearing acknowledged state; none bounds this reconciliation metadata read. Bounded all-state searches found no equivalent fix. Proposed small change: rank scalar event IDs by time/id for exact active keys within the current scope, then fetch only the winning metadata columns. This bounds application-side result volume; database-side history scanning/ranking remains and no constant-time DB claim is intended. MySQL 8 compatibility needs review; the executed fixture uses H2 only. No schema/index or external API change is proposed. AI assistance was used for source review, deduplication and the isolated query experiment. ### Are You Willing to Submit a Pull Request? - [x] Yes, I am willing to submit a pull request. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
