[Bug] The 2026-08-17 table renames have no upgrade path, and two deploy scripts still target the dropped names

Start from deploy/mysql/upgrade-instance-id-pk.sql and deploy/mysql/upgrade-query-history-context.sql. Compare the table names they reference against server/src/main/resources/db/schema.sql to confirm the renames from #2317. Either add IF EXISTS guards so the scripts skip on current schemas, or create a new migration that renames the four old tables to their new names before these scripts run. Run the scripts against a test database initialized from schema.sql to verify they no longer error.

Before Creating the Bug Report

• I have searched the open issues of this repository and believe that this is not a duplicate.
• This is a defect in RocketMQ Studio, not a usage question and not a defect in another Apache RocketMQ repository.
• I can reproduce this on the current master branch, or I have stated the exact version I am running below.

Studio Version

branch: rocketmq-studio
git commit id: 6a68042f
deployed as: docker compose (deploy/docker-compose.yml, existing MySQL volume)

Runtime Environment

OS: Ubuntu 22.04 (WSL2) — no local Docker integration, so the scripts could not be executed here; the failure mode below is read off the guards and MySQL's documented behaviour for a missing table
MySQL: 8.0 (the compose service)
browser: not applicable

Connected RocketMQ Cluster

RocketMQ version: not applicable — the defect is in the MySQL upgrade scripts
access mode: not applicable
deployment: not applicable

Describe the Bug

Two files under deploy/mysql/ still address tables that #2317 renamed on 2026-08-17, and nothing in the repository ever migrates the rename for an existing volume:

• upgrade-instance-id-pk.sql (added 2026-08-13, untouched since) updates rmq_topic, rmq_group, rmq_acl_rule, rmq_acl_user, rmq_data_source, rmq_instance; the first two were renamed to rmq_instance_topic / rmq_instance_group by #2317.
• upgrade-query-history-context.sql (added 2026-08-07, untouched since) alters rmq_message_query and rmq_trace_query, renamed to rmq_instance_message / rmq_instance_trace by the same commit.
• grep -rn "RENAME TABLE" . finds nothing, and deploy/mysql/ contains no script that bridges the old names to the new ones, so a volume created before 2026-08-17 never gets them.

Two consequences, both of them wrong:

1. On any database created or upgraded after #2317 (which is every deployment from the current branch), running these scripts aborts. Their guards probe a column or an index on the old table rather than the table itself, so an absent table reads as "needs the change":

SET @message_query_column_exists := (SELECT COUNT(*) FROM information_schema.columns
   WHERE table_schema = @schema_name AND table_name = 'rmq_message_query' AND column_name = 'cluster_id');
SET @message_query_sql := IF(@message_query_column_exists = 0,
   'ALTER TABLE rmq_message_query ADD COLUMN cluster_id VARCHAR(255) AFTER result_count', 'SELECT 1');

count = 0 → ALTER TABLE rmq_message_query … → ERROR 1146 (42S02): Table 'rocketmq.rmq_message_query' doesn't exist, and the mysql client stops at the first error in batch mode. upgrade-instance-id-pk.sql has no guard at all, so it fails on its very first UPDATE rmq_topic t JOIN ….

2. On a volume that still has the old tables, the scripts run, but every statement that touches a renamed table lands in a table the application no longer reads (RmqMessageQuery maps to rmq_instance_message, RmqTraceQuery to rmq_instance_trace), so the migration reports success without bringing the deployment closer to the current schema — only the parts that touch surviving tables (such as rmq_instance.id) take effect.

The scripts tell operators to run them ("存量 MySQL 数据卷增量迁移", "Run once on existing deployments"), and the project has already fixed this exact class of defect once: #4722 ("The nameserver unique-key migration script references a dropped column and always aborts") was fixed by #4721.

Steps to Reproduce

1. On a database initialized from server/src/main/resources/db/schema.sql (the authoritative DDL), list the tables: rmq_topic, rmq_group, rmq_message_query and rmq_trace_query do not exist; rmq_instance_topic, rmq_instance_group, rmq_instance_message and rmq_instance_trace do.
2. Run mysql -uroot -p rocketmq < deploy/mysql/upgrade-query-history-context.sql: the prepared ALTER TABLE rmq_message_query … fails with error 1146.
3. Run mysql -uroot -p rocketmq < deploy/mysql/upgrade-instance-id-pk.sql: the first statement fails with error 1146 on rmq_topic.
4. Check git log -S "rmq_message_query" -- server/src/main/resources/db/schema.sql and the #2317 commit message: the rename is the source of the mismatch, and no script renames anything.

What Did You Expect to See?

Either the scripts work on the schema they claim to upgrade, or they say plainly that the deployment is outside the supported upgrade path — instead of failing with a raw driver error halfway through, or silently writing to tables nobody reads.

What Did You See Instead?

Two scripts that cannot succeed on a current database, no migration for the #2317 renames at all, and no statement anywhere that pre-#2317 volumes are unsupported.

Additional Context

• I am happy to implement whichever direction maintainers pick: (a) add the missing rename migration (rename the four tables in the right order, then let the existing scripts run against the current names), or (b) declare pre-#2317 volumes unsupported and make it explicit — for example guard the two scripts on table existence so they skip with a message, and update their headers and deploy/README.md, which currently only mentions the demo scripts.
• What cannot stay as it is: a "run this on existing deployments" instruction that aborts with 1146, and a rename with no migration behind it.
• duplicate check: searched open/recent issues and PRs for rmq_message_query, "upgrade script", "existing volume" and "table rename"; the only related item is the closed #4722/#4721 pair for the nameserver script.

Are You Willing to Submit a Pull Request?

• Yes, I am willing to submit a pull request.