sql >> Database teknologi >  >> RDS >> Mysql

JSON_STORAGE_FREE() – Find ud af, hvor meget lagerplads der blev frigivet efter en opdatering af et JSON-dokument i MySQL

I MySQL er JSON_STORAGE_FREE() funktionen viser, hvor meget lagerplads der blev frigivet, efter at et JSON-dokument blev opdateret.

For en JSON-kolonneværdi viser den, hvor meget lagerplads der blev frigivet i dens binære repræsentation, efter at den blev opdateret på plads ved hjælp af JSON_SET() , JSON_REPLACE() , eller JSON_REMOVE() .

For et JSON-dokument (eller en streng, der kan parses som én), returnerer denne funktion 0 .

Syntaks

Syntaksen ser sådan ud:

JSON_STORAGE_FREE(json_val)

Hvor json_val repræsenterer JSON-dokumentet, hvortil der skal returneres mængden af ​​frigjorte bytes efter en opdatering. Dette kan være et kolonnenavn. Det kan også være et gyldigt JSON-dokument eller en streng, der kan parses som én – enten som en bogstavelig værdi eller som værdien af ​​en brugervariabel – i hvilket tilfælde funktionen returnerer 0 .

Eksempel

Vi kører en forespørgsel:

SELECT Contents 
FROM Collections 
WHERE CollectionId = 4;

Og få følgende data:

+-------------------------------------+
| Contents                            |
+-------------------------------------+
| {"Name": "Homer", "Stupid": "True"} |
+-------------------------------------+

Lad os tjekke lagerstørrelsen for Contents kolonne, og se, om der er blevet frigivet plads ved en opdatering.

SELECT 
  JSON_STORAGE_SIZE(Contents) Size,
  JSON_STORAGE_FREE(Contents) Free
FROM Collections
WHERE CollectionId = 4;

Resultat:

+------+------+
| Size | Free |
+------+------+
|   40 |    0 |
+------+------+

I dette tilfælde bruger dataene op til 40 bytes lagerplads, og der er ikke frigivet plads ved nogen opdateringer.

Men det kan vi ændre på.

Lad os lave en opdatering.

UPDATE Collections
SET Contents = JSON_SET(Contents, "$.Stupid", 1)
WHERE CollectionId = 4;

Resultat:

Query OK, 1 row affected (0.08 sec)
Rows matched: 1  Changed: 1  Warnings: 0

Lad os køre endnu en forespørgsel for at se de opdaterede data.

SELECT Contents 
FROM Collections 
WHERE CollectionId = 4;

Resultat:

+--------------------------------+
| Contents                       |
+--------------------------------+
| {"Name": "Homer", "Stupid": 1} |
+--------------------------------+

Altså værdien "True" er blevet ændret til 1 .

Lad os nu se, hvor meget plads der blev frigivet med den opdatering.

SELECT 
  JSON_STORAGE_SIZE(Contents) Size,
  JSON_STORAGE_FREE(Contents) Free
FROM Collections
WHERE CollectionId = 4;

Resultat:

+------+------+
| Size | Free |
+------+------+
|   40 |    5 |
+------+------+

Dette resultat viser, at en delvis opdatering af JSON-dokumentet fandt sted, og at dette frigjorde 5 bytes lagerplads. Resultatet returneret af JSON_STORAGE_SIZE() er uændret af den delvise opdatering.

Delvise opdateringer understøttes for opdateringer ved hjælp af JSON_SET() , JSON_REPLACE() , eller JSON_REMOVE() .

Ikke-delvise opdateringer

Den direkte tildeling af en værdi til en JSON-kolonne kan ikke delvist opdateres, og derfor vil dette resultere i, at der ikke bliver rapporteret frigjort plads.

Det samme gælder for en JSON-brugervariabel.

Her er et eksempel til at demonstrere.

Først indstiller vi variablen:

SET @data = '{"Name": "Homer", "Stupid": "True"}';
SELECT 
  JSON_STORAGE_SIZE(@data) Size,
  JSON_STORAGE_FREE(@data) Free;

Resultat:

+------+------+
| Size | Free |
+------+------+
|   40 |    0 |
+------+------+

Nu opdaterer vi variablen ved hjælp af JSON_SET() :

SET @data = JSON_SET(@data, "$.Stupid", 1);
SELECT 
  JSON_STORAGE_SIZE(@data) Size,
  JSON_STORAGE_FREE(@data) Free;

Resultat:

+------+------+
| Size | Free |
+------+------+
|   35 |    0 |
+------+------+

Så i dette tilfælde blev der ikke frigivet plads. Bemærk dog også, at JSON_STORAGE_SIZE() funktionen rapporterer nu det laveste antal bytes (35), der bruges til at gemme dokumentet.


  1. Skift til en partition i SQL Server (T-SQL)

  2. TO_SECONDS() Eksempler – MySQL

  3. PostgreSQL-funktion/lagret procedure CURRENT_TIMESTAMP ændres ikke

  4. Microsoft OLE DB uudviklet! Længe leve ADO!