A utilities billing RDS MySQL database shows rising p95 query latency after a schema growth year. Performance Insights highlights repeated full-table scans and suboptimal parameters. Which data-tier remediation best addresses the bottleneck?
Select an answer to reveal the explanation.
Short Explanation
When the billing ledger starts wheezing, you do not throw the filing cabinets into deep freeze—you fix the index cards and the engine knobs. Slow-query evidence plus parameter and index tuning is the grown-up move.
Full Explanation
A utilities billing RDS MySQL database with rising p95 query latency after schema growth, where Performance Insights highlights full-table scans and suboptimal parameters, needs data-tier tuning—not storage theater. Tuning indexes and engine parameters guided by slow-query and Performance Insights analysis, then re-measuring against billing SLOs, addresses the bottleneck where it lives: query plans and configuration. That remediation works because OLTP billing latency is usually access-path and parameter driven once instance size is adequate. Migrating the OLTP billing ledger to S3 Glacier Instant Retrieval as the primary store fails as an inappropriate primary for transactional billing. Deleting automated backups to free IOPS for SELECTs fails conceptually by sacrificing recoverability for a dubious IOPS trade. Forcing every report through a single read replica with no indexes fails by recreating scans on the replica and simplifying nothing useful. Exam caveat: index changes can slow writes—validate under billing batch windows; parameter changes need staged apply and fallback notes. Operational check: capture top SQL from Performance Insights, add or adjust indexes in nonprod with production-like data volume, compare p95 to SLO, apply during a change window, and retain backup retention unchanged.