Native JSON-stöd i MYSQL 5.7:vilka är fördelarna och nackdelarna med JSON-datatyp i MYSQL?

SELECT * FROM t1
WHERE JSON_EXTRACT(data,"$.series") IN ...

Att använda en kolumn i ett uttryck eller en funktion som denna förstör alla möjligheter att frågan använder ett index för att optimera frågan. Frågan som visas ovan tvingas göra en tabellskanning.

Påståendet om "effektiv tillgång" är missvisande. Det betyder att efter att frågan har undersökt en rad med ett JSON-dokument kan den extrahera ett fält utan att behöva analysera texten i JSON-syntaxen. Men det krävs fortfarande en tabellskanning för att söka efter rader. Med andra ord måste frågan undersöka varje rad.

I analogi, om jag söker i en telefonbok efter personer med förnamnet "Bill", måste jag fortfarande läsa varje sida i telefonboken, även om förnamnen har markerats för att göra det lite snabbare att upptäcka dem.

MySQL 5.7 låter dig definiera en virtuell kolumn i tabellen och sedan skapa ett index på den virtuella kolumnen.

ALTER TABLE t1
  ADD COLUMN series AS (JSON_EXTRACT(data, '$.series')),
  ADD INDEX (series);

Om du sedan frågar efter den virtuella kolumnen kan den använda indexet och undvika tabellsökningen.

SELECT * FROM t1
WHERE series IN ...

Det här är trevligt, men det missar liksom poängen med att använda JSON. Det attraktiva med att använda JSON är att det låter dig lägga till nya attribut utan att behöva göra ALTER TABLE. Men det visar sig att du måste definiera en extra (virtuell) kolumn ändå, om du vill söka i JSON-fält med hjälp av ett index.

Men du behöver inte definiera virtuella kolumner och index för alla fältet i JSON-dokumentet – endast de du vill söka eller sortera på. Det kan finnas andra attribut i JSON som du bara behöver extrahera i urvalslistan som följande:

SELECT JSON_EXTRACT(data, '$.series') AS series FROM t1
WHERE <other conditions>

Jag skulle generellt säga att detta är det bästa sättet att använda JSON i MySQL. Endast i urvalslistan.

När du refererar till kolumner i andra klausuler (JOIN, WHERE, GROUP BY, HAVING, ORDER BY) är det mer effektivt att använda konventionella kolumner, inte fält i JSON-dokument.

Jag presenterade ett föredrag som heter Hur man använder JSON i MySQL Fel på Percona Live-konferensen i april 2018. Jag kommer att uppdatera och upprepa föredraget på Oracle Code One under hösten.

Det finns andra problem med JSON. Till exempel krävde det i mina tester 2-3 gånger så mycket lagringsutrymme för JSON-dokument jämfört med konventionella kolumner som lagrar samma data.

MySQL marknadsför sina nya JSON-funktioner aggressivt, till stor del för att avskräcka människor från att migrera till MongoDB. Men dokumentorienterad datalagring som MongoDB är i grunden ett icke-relationellt sätt att organisera data. Det är annorlunda än relationellt. Jag säger inte att den ena är bättre än den andra, det är bara en annan teknik, lämpad för olika typer av frågor.

Du bör välja att använda JSON när JSON gör dina frågor mer effektiva.

Välj inte en teknik bara för att den är ny eller för modets skull.

Edit:Den virtuella kolumnimplementeringen i MySQL är tänkt att använda indexet om din WHERE-sats använder exakt samma uttryck som definitionen av den virtuella kolumnen. Det vill säga följande bör använd indexet på den virtuella kolumnen, eftersom den virtuella kolumnen är definierad AS (JSON_EXTRACT(data,"$.series"))

SELECT * FROM t1
WHERE JSON_EXTRACT(data,"$.series") IN ...

Förutom att jag har funnit genom att testa den här funktionen att den INTE fungerar av någon anledning om uttrycket är en JSON-extraktionsfunktion. Det fungerar för andra typer av uttryck, bara inte JSON-funktioner. UPPDATERING:enligt uppgift fungerar detta äntligen i MySQL 5.7.33.