When hundreds of pages of SQL templates flood your database and performance metrics spike, sorting through them manually is impractical. The abnormal SQL request identification feature uses machine learning to group SQL templates by behavior, so you can pinpoint the category driving the anomaly—without reviewing every template individually.
Prerequisites
Before you begin, ensure that you have:
A supported database instance type:
ApsaraDB RDS for MySQL 5.6, 5.7, or 8.0
ApsaraDB MyBase for MySQL 5.6, 5.7, or 8.0
The instance connected to DAS. For more information, see Autonomy center.
DAS Enterprise Edition enabled for the instance. For more information, see the Enable DAS Economy Edition and DAS Enterprise Edition section of the "Enable and manage DAS Economy Edition and DAS Enterprise Edition" topic.
How it works
DAS analyzes the top 1,000 SQL templates by total execution time. The backend algorithm identifies similar SQL behavior profiles and groups templates into categories. You can then correlate each category's occurrence trend with a specific metric spike to find the root cause.
The full SQL request analysis feature of DAS Enterprise Edition retrieves and processes the complete SQL dataset, which typically takes 1 to 5 minutes depending on data size.
Use cases
The following QPS chart illustrates two categories of abnormal SQL requests:
Use case 1: Too many SQL templates to sort manually
When your database handles hundreds of pages of SQL templates, sorting alone cannot surface the problem. The abnormal SQL request identification feature groups templates by SQL behavior profile. Templates with similar behavior are aggregated into one category, so you review categories—not thousands of individual templates.
Use case 2: Metric spike with an unknown SQL cause
When CPU utilization or active session count spikes, you need to know which SQL category is responsible. The abnormal SQL request identification feature overlays each category's occurrence trend against the metric timeline. The category whose trend coincides with the metric spike is the likely culprit.
Identify abnormal SQL requests
Log on to the DAS console.
In the left-side navigation pane, click Instance Monitoring.
Find the database instance and click its instance ID to open the instance details page.
In the left-side navigation pane, click Autonomy Center.
Set a time range and click Search to list events in that period.
Click Details for an event. This example uses a time series exception detection event.
On the Anomaly Snapshots tab, review the Analysis of Abnormal Metrics section to see the exception causes and related metric changes.
In the Performance Metrics section, select an abnormal metric type to view its distribution over the specified time range.
In the SQL Request Behavior Analysis section, select a monitoring metric and an associated metric to run the analysis.
Review the analysis results. The results show the SQL metric most correlated with the abnormal metric, along with the corresponding SQL template and statistics.
A correlation value closer to 1.00 indicates a stronger association with the abnormal metric.
Interpret the results
Compare each SQL category's occurrence trend with the metric spike timeline to determine the root cause.
Pattern: spike timing does not match
If a SQL category spikes at a different time from the metric spike, it is not the primary contributor to the anomaly.
Pattern: spike timing coincides
If the point at which CPU utilization and active sessions peak coincides with a sudden decrease in SQL requests for a category, those SQL requests are being blocked when the active session count spikes.
