Database Autonomy Service:[Avis] Optimisation de l'algorithme des modèles SQL

Contexte

DAS utilise l'algorithme des modèles SQL pour traiter les instructions SQL sous forme de modèles, afin de les agréger et de les analyser dans le cadre des requêtes lentes et de l'audit SQL. L'ancien algorithme gérait mal les instructions SQL tronquées. Par exemple, une troncature à des positions imprévisibles pouvait entraîner une expansion des modèles, ce qui rendait leur agrégation difficile.

Date d'entrée en vigueur

À compter du 1er septembre 2024, l'algorithme des modèles SQL pour les requêtes lentes et les audits SQL est optimisé.

Périmètre d'application

L'optimisation s'applique aux moteurs de base de données suivants : ApsaraDB RDS for MySQL, ApsaraDB RDS for PostgreSQL, ApsaraDB RDS for SQL Server, ApsaraDB RDS for MariaDB et PolarDB for MySQL.

Contenu

Les optimisations suivantes sont apportées :

• $$ est reconnu comme délimiteur de constante de chaîne pour ApsaraDB RDS for PostgreSQL ; les identifiants ne sont plus incorrectement remplacés par des points d'interrogation (?).

  Prenons l'instruction SQL originale suivante :

  UPDATE "study" SET "name" = 'xiaoming', "ext" = $${"math":90,"english":91}$$ where id=128;

  Avant l'optimisation, le modèle SQL suivant était généré :

  UPDATE ?  SET ?  = ?, ?  = $${?:?,?:?}$$ where id=?;

  Après l'optimisation, le modèle SQL suivant est généré :

  UPDATE "study" SET "name"=?,"ext"=?  WHERE id=?;

• Les suffixes numériques des noms de tables et de colonnes sont remplacés par des espaces réservés pour réduire le nombre de modèles.

  Prenons l'instruction SQL originale suivante :

  select * from [school_3].[class].[student_25];

  Avant l'optimisation, le modèle SQL suivant était généré :

  select * from [school_3].[class].[student_25];

  Après l'optimisation, le modèle SQL suivant est généré :

  SELECT * FROM [school_?].[class].[student_?];

• Pour les instances ApsaraDB RDS for SQL Server, les préfixes des instructions SQL sont supprimés afin d'améliorer l'analyse du type d'instruction.

  Prenons l'instruction SQL originale suivante :

  (@P0 nvarchar(4000))select id, name from student WHERE name = @P0;

  Avant l'optimisation, le modèle SQL suivant était généré :

  Generated SQL template: (@P0 nvarchar(?))select id, name from student WHERE name = @P0;
  Parsed type of the SQL statement: p0

  Après l'optimisation, le modèle SQL suivant est généré :

  Generated SQL template: SELECT id,name FROM student WHERE name=?;
  Parsed type of the SQL statement: select

• Les espaces inutiles sont supprimés et la casse d'origine des mots-clés est préservée sans affecter la syntaxe.

  Prenons l'instruction SQL originale suivante :

  select `name` from `student` 
    where `id` = 1 and (`name` = 'xiaoming' or `class` = 2);

  Avant l'optimisation, le modèle SQL suivant était généré :

  SELECT `name` FROM `student` WHERE `id` = ?  AND (`name` = ?  OR `class` = ?)

  Après l'optimisation, le modèle SQL suivant est généré :

  SELECT `name` FROM `student` WHERE `id`=?  AND (`name`=?  OR `class`=?);

• Toutes les parenthèses de l'instruction SQL d'origine sont conservées.

  Prenons l'instruction SQL originale suivante :

  select `name` from `student` where `id` = 1 and (`name` = 'xiaoming');

  Avant l'optimisation, le modèle SQL suivant était généré :

  SELECT `name` FROM `student` WHERE `id` = ?  AND `name` = ?

  Après l'optimisation, le modèle SQL suivant est généré :

  SELECT `name` FROM `student` WHERE `id`=?  AND (`name`=?);

• Les parenthèses entourant l'expression CASE ne sont plus converties en « AS ».

  Prenons l'instruction SQL originale suivante :

  select `name`, ( CASE WHEN score > 90 THEN 'A' END ) `grade` from `student`;

  Avant l'optimisation, le modèle SQL suivant était généré :

  SELECT `name` , CASE  WHEN score > ?  THEN ?  END AS `grade` FROM `student`

  Après l'optimisation, le modèle SQL suivant est généré :

  SELECT `name`,(CASE WHEN score>?  THEN ?  END)`grade` FROM `student`;

• Le contenu situé après un signe dièse (#) est désormais correctement analysé.

  Prenons l'instruction SQL originale suivante :

  select `name`, `#grade` from `student`;

  Avant l'optimisation, le modèle SQL suivant était généré :

  SELECT `name`, `

  Après l'optimisation, le modèle SQL suivant est généré :

  SELECT `name`,`#grade` FROM `student`;

• Pour les instructions SQL tronquées, le contenu des parenthèses non appariées est ignoré afin de réduire le nombre de modèles.

  Prenons l'instruction SQL originale suivante :

  select `name`, `grade` from `student` where id = (select uid from 

  Avant l'optimisation, le modèle SQL suivant était généré :

  select `name`, `grade` from `student` where id = (select uid from

  Après l'optimisation, le modèle SQL suivant est généré :

  SELECT `name`,`grade` FROM `student` WHERE id=

• Les expressions similaires sont fusionnées pour éviter l'expansion des modèles.

  Prenons l'instruction SQL originale suivante :

  SELECT 
      CASE 
          WHEN score >= 90 THEN 'A'
          WHEN score >= 80 THEN 'B'
          WHEN score >= 70 THEN 'C'
          WHEN score >= 60 THEN 'D'
          ELSE 'F'
      END AS grade
  FROM 
      students;

  Avant l'optimisation, le modèle SQL suivant était généré :

  SELECT CASE  WHEN score >= ?  THEN ?  WHEN score >= ?  THEN ?  WHEN score >= ?  THEN ?  WHEN score >= ?  THEN ?  ELSE ?  END AS grade FROM students

  Après l'optimisation, le modèle SQL suivant est généré :

  SELECT CASE WHEN score>=?  THEN ?  ELSE ?  END AS grade FROM students;

Impact

• Après l'optimisation, la valeur SQLHash d'un SQLText donné change lors de l'appel à l'opération DescribeSlowLogs ou DescribeSlowLogRecords.

• Après l'optimisation, la valeur SqlId change lors de l'appel à l'opération GetFullRequestStatResultByInstanceId ou GetAsyncErrorRequestListByCode.