{"id":1363,"date":"2013-01-08T11:22:24","date_gmt":"2013-01-08T10:22:24","guid":{"rendered":"http:\/\/dasini.net\/blog\/?p=1363"},"modified":"2013-01-30T10:57:30","modified_gmt":"2013-01-30T09:57:30","slug":"full-table-scan-vs-full-index-scan-part1-2","status":"publish","type":"post","link":"https:\/\/dasini.net\/blog\/2013\/01\/08\/full-table-scan-vs-full-index-scan-part1-2\/","title":{"rendered":"Full table scan vs Full index scan part1-2"},"content":{"rendered":"

1\/ Le myst\u00e8re de la variable Last_query_cost<\/span><\/h1>\n

MySQL utilise un optimiseur \u00e0 base de co\u00fbts. Le plan d\u2019ex\u00e9cution de la requ\u00eate choisit est celui dont le co\u00fbt est le plus faible. Ce dernier peut \u00eatre visualis\u00e9 gr\u00e2ce \u00e0 la variable <\/span>Last_query_cost<\/span><\/a>.<\/span>
\nSon unit\u00e9 est le co\u00fbt (encore lui) des acc\u00e8s al\u00e9atoires en lecture de pages de 4ko.<\/span>
\n\u00c9trangement cette variable est assez peu\/mal document\u00e9e. Voici ce qu\u2019on retrouve dans la doc officielle de MySQL<\/span>
\nJe cite: <\/span>
\nLast_query_cost<\/span><\/a>
\nThe total cost of the last compiled query as computed by the query optimizer. This is useful for comparing the cost of different query plans for the same query. The default value of 0 means that no query has been compiled yet. The default value is 0.<\/span>Last_query_cost<\/span><\/a> has session scope.<\/span>
\nThe<\/span>Last_query_cost<\/span><\/a> value can be computed accurately only for simple \u201cflat\u201d queries, not complex queries such as those with subqueries or<\/span>UNION<\/span><\/a>. For the latter, the value is set to 0.<\/span><\/p>\n

La valeur de Last_query_cost est parfois d\u00e9concertante, m\u00eame avec MySQL 5.6. Voyez par vous m\u00eame…<\/span><\/p>\n

Quelques informations avant d\u2019entrer dans le vif du sujet.<\/span>
\nServer version:<\/span> \u00a0\u00a0\u00a0\u00a0\u00a0 \u00a0<\/span>5.6.9<\/span>-rc MySQL Community Server (GPL)<\/span><\/p>\n

Configuration de l\u2019instance<\/span>:<\/span>
\nInnodb buffer pool size = <\/span>32 Go<\/span>
\nmax_heap_table_size = tmp_table_size = <\/span>512 Mo<\/span><\/p>\n

Table<\/span>: <\/span>
\nCREATE TABLE `bills` (<\/span>
\n \u00a0`id` int(10) unsigned NOT NULL AUTO_INCREMENT,<\/span>
\n \u00a0`d` datetime NOT NULL,<\/span>
\n \u00a0`price` smallint(5) unsigned NOT NULL,<\/span>
\n \u00a0PRIMARY KEY (`id`),<\/span>
\n \u00a0KEY `d` (`d`)<\/span>
\n) ENGINE=<\/span>InnoDB<\/span> DEFAULT CHARSET=utf8 COLLATE=utf8_swedish_ci<\/span><\/p>\n

SHOW TABLE STATUS<\/span>:<\/span>
\n*************************** 1. row ***************************<\/span>
\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Name: bills<\/span>
\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Engine: InnoDB<\/span>
\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Version: 10<\/span>
\n \u00a0\u00a0\u00a0 Row_format: Compact<\/span>
\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Rows: 176268<\/span>
\n Avg_row_length: 56<\/span>
\n\u00a0\u00a0\u00a0 Data_length: 9961472<\/span>
\nMax_data_length: 0<\/span>
\n \u00a0\u00a0Index_length: 4210688<\/span>
\n \u00a0\u00a0\u00a0\u00a0 Data_free: 2097152<\/span>
\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0…<\/span>
\n \u00a0\u00a0\u00a0\u00a0 Collation: utf8_swedish_ci<\/span>
\n=> Donn\u00e9es + Index: \u00a0environs 16 Mo<\/span><\/p>\n

L\u2019id\u00e9e est d\u2019ex\u00e9cuter la requ\u00eate ci-dessous, avec diff\u00e9rents \u201chint\u201d est de voir les plans d\u2019ex\u00e9cution (QEP) g\u00e9n\u00e9r\u00e9s par MySQL ainsi que leurs co\u00fbts respectifs.<\/span>
\nSELECT d,avg(price) FROM bills GROUP BY d<\/span><\/p>\n

2 QEP possibles:<\/span>
\n– Faire un full table scan, cr\u00e9er une table temporaire pour regrouper et ordonner (particularit\u00e9 du GROUP BY de MySQL) les donn\u00e9es en fonction de la date (d) pour calculer la moyenne des prix (avg(price)).<\/span>
\n– Faire un full index scan sur d, ce qui \u00e9vite le tri et la cr\u00e9ation de la table temporaire. Cependant le \u201cprice\u201d n\u2019\u00e9tant pas dans l\u2019index, l\u2019info doit \u00eatre r\u00e9cup\u00e9r\u00e9 dans la couche \u201cdata\u201d <\/span><\/p>\n

Query 1\/ EXPLAIN \u00a0SELECT d,avg(price) FROM bills GROUP BY d\\G<\/span>
\n*************************** 1. row ***************************<\/span>
\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 id: 1<\/span>
\n \u00a0select_type: SIMPLE<\/span>
\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 table: bills<\/span>
\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 type: index<\/span>
\npossible_keys: NULL<\/span>
\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 key: d<\/span>
\n \u00a0\u00a0\u00a0\u00a0 key_len: 5<\/span>
\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 ref: NULL<\/span>
\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 rows: 176268<\/span>
\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Extra: NULL<\/span><\/p>\n

Le choix de l\u2019optimiseur est assez intuitif, il se sert du fait que l\u2019index d est tri\u00e9 (type: index = full index scan) pour optimiser le GROUP BY (regroupement + tri), c\u2019est \u00e0 dire ne pas cr\u00e9er de table temporaire.<\/span><\/p>\n

Le co\u00fbt de cette op\u00e9ration est:<\/span>
\nSHOW STATUS LIKE ‘Last_query_cost;<\/span>
\n+—————–+—————+<\/span>
\n| Variable_name \u00a0\u00a0| Value \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 |<\/span>
\n+—————–+—————+<\/span>
\n| Last_query_cost | <\/span>212129.599000<\/span> |<\/span>
\n+—————–+—————+<\/span><\/p>\n

Question de psychopathe, que se passe t\u2019il si je force l\u2019optimiseur \u00e0 utiliser l\u2019index qu\u2019il dit qu\u2019il va utiliser ? (c\u2019est vicieux je sais :D)<\/span><\/p>\n

Query 2\/ EXPLAIN \u00a0SELECT d,avg(price) FROM bills <\/span>USE INDEX(d)<\/span> GROUP BY d\\G *************************** 1. row ***************************<\/span>
\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 id: 1<\/span>
\n \u00a0select_type: SIMPLE<\/span>
\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 table: bills<\/span>
\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 type: index<\/span>
\npossible_keys: NULL<\/span>
\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 key: d<\/span>
\n \u00a0\u00a0\u00a0\u00a0 key_len: 5<\/span>
\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 ref: NULL<\/span>
\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 rows: 176268<\/span>
\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Extra: NULL<\/span><\/p>\n

Alors pour \u00eatre pr\u00e9cis, l\u00e0 je ne le force pas vraiment, je l\u2019incite (fortement) \u00e0 l\u2019utiliser. Mais sans surprise, il l\u2019utilise (ouf !), en d\u2019autre terme le QEP est le m\u00eame que pr\u00e9c\u00e9demment.<\/span><\/p>\n

Et qu\u2019en est il du co\u00fbt ?<\/span><\/p>\n

SHOW STATUS LIKE ‘Last_query_cost;<\/span>
\n+—————–+—————+<\/span>
\n| Variable_name \u00a0\u00a0| Value \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 |<\/span>
\n+—————–+—————+<\/span>
\n| Last_query_cost | <\/span>212129.599000<\/span> |<\/span>
\n+—————–+—————+<\/span><\/p>\n

Pareil que pr\u00e9c\u00e9demment, circuler il n\u2019y a rien \u00e0 voir !<\/span><\/p>\n

Ok est si l\u00e0 je le force vraiment, avec FORCE INDEX (principale diff\u00e9rence entre USE INDEX et FORCE INDEX est qu\u2019avec le second l\u2019optimiseur choisira (si c\u2019est possible bien s\u00fbr) d\u2019utiliser l\u2019index en lieu est place d\u2019un full table scan)<\/span><\/p>\n

Query 3\/ \u00a0EXPLAIN \u00a0SELECT d,avg(price) FROM bills <\/span>FORCE INDEX(d)<\/span> GROUP BY d\\G<\/span>
\n*************************** 1. row ***************************<\/span>
\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 id: 1<\/span>
\n \u00a0select_type: SIMPLE<\/span>
\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 table: bills<\/span>
\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 type: index<\/span>
\npossible_keys: NULL<\/span>
\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 key: d<\/span>
\n \u00a0\u00a0\u00a0\u00a0 key_len: 5<\/span>
\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 ref: NULL<\/span>
\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 rows: 176268<\/span>
\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Extra: NULL<\/span><\/p>\n

L\u00e0 encore, (sans surprise) le QEP est le m\u00eame que pr\u00e9c\u00e9demment. Et le co\u00fbt ?<\/span><\/p>\n

SHOW STATUS LIKE ‘Last_query_cost;<\/span>
\n+—————–+—————+<\/span>
\n| Variable_name \u00a0\u00a0| Value \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 |<\/span>
\n+—————–+—————+<\/span>
\n| Last_query_cost | <\/span>387790.599000<\/span> |<\/span>
\n+—————–+—————+<\/span><\/p>\n

\u2026 WTF \u2026<\/span>
\nBon l\u00e0 pour \u00eatre franc, je n\u2019ai pas d\u2019explications rationnelles. Serait ce une feature ? (rationnelle on \u00e0 dit !!!) ok ok bah un bug alors.<\/span>
\nInutile de pr\u00e9ciser que je me suis empress\u00e9 de tester avec d\u2019autres versions de MySQL (psychopate !) et le r\u00e9sultat est sans appel:<\/span>
\nAvec MySQL 5.5, MariaDB 5.5 & Percona server 5.5 le co\u00fbt du FORCE INDEX est <\/span>identique<\/span> aux 3 autres co\u00fbts.<\/span><\/p>\n

J\u2019opterai donc pour une petite r\u00e9gression de l\u2019optimiseur, bref un BUG<\/span><\/p>\n

Soit ! si j\u2019emp\u00eache l\u2019optimiseur d\u2019utiliser l\u2019index:<\/span>
\nQuery 4\/ EXPLAIN \u00a0SELECT d,avg(price) FROM bills <\/span>IGNORE INDEX(d)<\/span> GROUP BY d\\G<\/span>
\n*************************** 1. row ***************************<\/span>
\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 id: 1<\/span>
\n \u00a0select_type: SIMPLE<\/span>
\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 table: bills<\/span>
\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 type: ALL<\/span>
\npossible_keys: NULL<\/span>
\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 key: NULL<\/span>
\n \u00a0\u00a0\u00a0\u00a0 key_len: NULL<\/span>
\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 ref: NULL<\/span>
\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 rows: 176268<\/span>
\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Extra: Using temporary; Using filesort<\/span><\/strong><\/p>\n

C\u2019est plut\u00f4t clair, full table scan (type: ALL), plus cr\u00e9ation d\u2019un table temporaire (Using temporary) pour regrouper les donn\u00e9es et les trier (Using filesort). C\u2019est le prix \u00e0 payer pour ne pas utiliser l\u2019index. \u00c7a \u00e0 l\u2019air vachement co\u00fbteux tout \u00e7a, Voyons ce qu\u2019en pense MySQL<\/span><\/p>\n

SHOW STATUS LIKE ‘Last_query_cost’;<\/span>
\n+—————–+—————+<\/span>
\n| Variable_name \u00a0\u00a0| Value \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 |<\/span>
\n+—————–+—————+<\/span>
\n| Last_query_cost | <\/span>212129.599000<\/span> |<\/span>
\n+—————–+—————+<\/span><\/p>\n


Humm pour l\u2019optimiseur, le co\u00fbt est le m\u00eame, pas forc\u00e9ment intuitif tout \u00e7a Pour rappel (ou pas) \u00a0les param\u00e8tres pris en compte par l\u2019optimiseur sont (entre autre): <\/span>
\n– Pour les co\u00fbts I\/O: information sur les enregistrements (nombre, taille,), informations sur les index(null, unique, cardinalit\u00e9…)…<\/span>
\n– Pour les co\u00fbts CPU: l\u2019\u00e9valuation des conditions, comparaison du rapport index\/enregistrements<\/span><\/p>\n

Force est de constater que selon l\u2019optimiseur, le co\u00fbt du FTS + table temp + tri et \u00e9quivalent, pour cette requ\u00eate au FIS.<\/span><\/p>\n

Bilan de cette premi\u00e8re partie<\/span>:<\/span>
\n– Il y a manifestement un bug de l\u2019optimiseur en MySQL 5.6.9 lors du calcul du co\u00fbt d\u2019une requ\u00eate avec la clause FORCE INDEX<\/span>
\n– \u00a0Dans notre exemple, le co\u00fbt d\u2019un full index scan est le m\u00eame qu\u2019un full table scan + Using temporary + Using filesort<\/span><\/p>\n

Mais alors, quel QEP donne t\u2019il le meilleur temps d\u2019ex\u00e9cution ?<\/span><\/p>\n

Cette question est trait\u00e9e dans la 2\u00e8me partie de cet article<\/span><\/p>\n

(Aller \u00e0 la 2\u00e8me partie..<\/a>)<\/em><\/p>\n

 <\/p>\n","protected":false},"excerpt":{"rendered":"

MySQL utilise un optimiseur \u00e0 base de co\u00fbts. Le plan d\u2019ex\u00e9cution de la requ\u00eate choisit est celui dont le co\u00fbt est le plus faible. Ce dernier peut \u00eatre visualis\u00e9 gr\u00e2ce \u00e0 la variable Last_query_cost.
\nSon unit\u00e9 est le co\u00fbt (encore lui) des acc\u00e8s al\u00e9atoires en lecture de pages de 4ko.
\n\u00c9trangement cette variable est assez peu\/mal document\u00e9e. Voici ce qu\u2019on retrouve dans la doc officielle de MySQL
\nJe cite:
\nLast_query_cost
\nThe total cost of the last compiled query as computed by the query optimizer. This is useful for comparing the cost of different query plans for the same query. The default value of 0 means that no query has been compiled yet. The default value is 0.Last_query_cost has session scope.
\nTheLast_query_cost value can be computed accurately only for simple \u201cflat\u201d queries, not complex queries such as those with subqueries orUNION. For the latter, the value is set to 0.<\/p>\n

La valeur de Last_query_cost est parfois d\u00e9concertante, m\u00eame avec MySQL 5.6. Voyez par vous m\u00eame…<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"footnotes":""},"categories":[34],"tags":[186],"class_list":["post-1363","post","type-post","status-publish","format-standard","hentry","category-optimisation","tag-mysql-5-6"],"aioseo_notices":[],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/p9LfWW-lZ","jetpack-related-posts":[{"id":430,"url":"https:\/\/dasini.net\/blog\/2009\/01\/29\/influencer-loptimiseur-de-mysql\/","url_meta":{"origin":1363,"position":0},"title":"Influencer l’optimiseur de MySQL","author":"Olivier DASINI","date":"29 janvier 2009","format":false,"excerpt":"Il est possible d'influencer l'optimiseur pour qu'il choisisse d'utiliser ou de ne pas utiliser un index particulier. Les clauses \u00e0 placer dans votre requ\u00eate SELECT sont les suivantes: USE INDEX : utilise l'index pass\u00e9 en argument (MySQL ne l'utilisera pas si l'index est plus couteux qu'un full table scan) FORCE\u2026","rel":"","context":"Dans "MySQL"","block_context":{"text":"MySQL","link":"https:\/\/dasini.net\/blog\/category\/mysql\/"},"img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":1370,"url":"https:\/\/dasini.net\/blog\/2013\/01\/30\/full-table-scan-vs-full-index-scan-part2-2\/","url_meta":{"origin":1363,"position":1},"title":"Full table scan vs Full index scan part2-2","author":"Olivier DASINI","date":"30 janvier 2013","format":false,"excerpt":"2\/ FTS ou FIS Avant de r\u00e9pondre explicitement \u00e0 la question, un petit zoom sur l\u2019une des nombreuses nouveaut\u00e9s de MySQL 5.6. La commande EXPLAIN s\u2019est enrichie de la clause format=json. Elle permet d\u2019avoir une version un peu plus d\u00e9taill\u00e9e que l\u2019EXPLAIN classique. Query 1\/ EXPLAIN format=json SELECT d,avg(price) FROM\u2026","rel":"","context":"Dans "optimisation"","block_context":{"text":"optimisation","link":"https:\/\/dasini.net\/blog\/category\/optimisation\/"},"img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":453,"url":"https:\/\/dasini.net\/blog\/2009\/02\/18\/optimisation-de-requetes-comprendre-loptimiseur-de-mysql\/","url_meta":{"origin":1363,"position":2},"title":"Optimisation de requ\u00eates: comprendre l’optimiseur de MySQL","author":"Olivier DASINI","date":"18 f\u00e9vrier 2009","format":false,"excerpt":"Le but de cet article est d'optimiser une simple requ\u00eate (SELECT avg(Population) FROM city GROUP BY CountryCode) et surtout de comprendre comment l'optimiseur proc\u00e8de, en \u00e9tudiant les r\u00e9sultats donn\u00e9s par les variables qui permettent de surveiller le serveur MySQL.","rel":"","context":"Dans "MySQL"","block_context":{"text":"MySQL","link":"https:\/\/dasini.net\/blog\/category\/mysql\/"},"img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":1196,"url":"https:\/\/dasini.net\/blog\/2012\/02\/28\/attention-au-query-cache\/","url_meta":{"origin":1363,"position":3},"title":"Attention au query cache","author":"Olivier DASINI","date":"28 f\u00e9vrier 2012","format":false,"excerpt":"Selon le livre \u00abAudit & optimisation, MySQL 5 - \u00e9ditions Eyrolles\u00bb, le cache de requ\u00eates ou query cache est un syst\u00e8me de cache m\u00e9moire interne \u00e0 MySQL, transparent pour l'application, qui ne stocke que les requ\u00eates SELECT et leurs r\u00e9sultats. L'apport de ce cache est particuli\u00e8rement d\u00e9pendant de votre application.\u2026","rel":"","context":"Dans "bench"","block_context":{"text":"bench","link":"https:\/\/dasini.net\/blog\/category\/bench\/"},"img":{"alt_text":"dasini.net - MySQL query cache","src":"https:\/\/i0.wp.com\/dasini.net\/blog\/wp-includes\/images\/query_cache_on_VS_query_cache_off_im_tiny.png?resize=350%2C200","width":350,"height":200},"classes":[]},{"id":1593,"url":"https:\/\/dasini.net\/blog\/2016\/03\/02\/30-mins-avec-mysql-query-rewriter\/","url_meta":{"origin":1363,"position":4},"title":"30 mins avec MySQL Query Rewriter","author":"Olivier DASINI","date":"2 mars 2016","format":false,"excerpt":"Parfois des requ\u00eates probl\u00e9matiques tournent sur le serveur, mais il n'est pas possible de r\u00e9gler le probl\u00e8me \u00e0 la source (Requ\u00eates venant d'un ORM par example) MySQL 5.7 fournit une API pre et post parse query rewrite. Les utilisateurs peuvent \u00e9crire leurs propre plugins ce qui permet d'\u00e9liminer le besoin\u2026","rel":"","context":"Dans "MySQL"","block_context":{"text":"MySQL","link":"https:\/\/dasini.net\/blog\/category\/mysql\/"},"img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":788,"url":"https:\/\/dasini.net\/blog\/2009\/10\/12\/mysql-query-cache\/","url_meta":{"origin":1363,"position":5},"title":"MySQL Query cache","author":"Olivier DASINI","date":"12 octobre 2009","format":false,"excerpt":"Le cache est toujours \u00e0 jour car en cas de modification d'une table, toutes les requ\u00eates en relations avec cette table sont invalid\u00e9es. Le cache de requ\u00eates est en g\u00e9n\u00e9ral utile lorsque: Les modifications sur les tables ne sont pas tr\u00e8s fr\u00e9quentes Beaucoup de requ\u00eates de lectures identiques Utilisation de\u2026","rel":"","context":"Dans "MySQL"","block_context":{"text":"MySQL","link":"https:\/\/dasini.net\/blog\/category\/mysql\/"},"img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]}],"jetpack_likes_enabled":true,"_links":{"self":[{"href":"https:\/\/dasini.net\/blog\/wp-json\/wp\/v2\/posts\/1363","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/dasini.net\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/dasini.net\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/dasini.net\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/dasini.net\/blog\/wp-json\/wp\/v2\/comments?post=1363"}],"version-history":[{"count":5,"href":"https:\/\/dasini.net\/blog\/wp-json\/wp\/v2\/posts\/1363\/revisions"}],"predecessor-version":[{"id":1367,"href":"https:\/\/dasini.net\/blog\/wp-json\/wp\/v2\/posts\/1363\/revisions\/1367"}],"wp:attachment":[{"href":"https:\/\/dasini.net\/blog\/wp-json\/wp\/v2\/media?parent=1363"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/dasini.net\/blog\/wp-json\/wp\/v2\/categories?post=1363"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/dasini.net\/blog\/wp-json\/wp\/v2\/tags?post=1363"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}