{"id":76,"date":"2025-05-08T19:42:30","date_gmt":"2025-05-08T23:42:30","guid":{"rendered":"https:\/\/juredev.com\/blog\/?p=76"},"modified":"2025-07-31T05:51:32","modified_gmt":"2025-07-31T09:51:32","slug":"optimizacion-de-consultas-sql-consejos-practicos-para-un-mejor-rendimiento","status":"publish","type":"post","link":"https:\/\/juredev.com\/blog\/2025\/05\/optimizacion-de-consultas-sql-consejos-practicos-para-un-mejor-rendimiento\/","title":{"rendered":"Optimizaci\u00f3n de Consultas SQL: Consejos Pr\u00e1cticos para un Mejor Rendimiento"},"content":{"rendered":"\n

Si trabajas con bases de datos, sabes que una consulta SQL <\/strong>mal optimizada puede ralentizar tu aplicaci\u00f3n, frustrar a los usuarios y sobrecargar el servidor. Optimizar tus consultas no es solo una tarea t\u00e9cnica, sino una forma de mejorar la experiencia de tus usuarios y hacer que tu sistema escale sin problemas. En este art\u00edculo, te comparto consejos pr\u00e1cticos con ejemplos claros, inspirados en casos reales como tiendas online, sistemas de CRM, redes sociales o an\u00e1lisis financiero. Cada consejo incluye ejemplos de c\u00f3digo, m\u00e9tricas de impacto y herramientas para identificar problemas, as\u00ed que podr\u00e1s aplicarlos f\u00e1cilmente en tus proyectos. \u00a1Empecemos!<\/p>\n\n\n\n

1. Elige Solo las Columnas que Realmente Necesitas<\/h2>\n\n\n\n

Usar SELECT *<\/code> es tentador porque es r\u00e1pido de escribir, pero puede ser un gran error. Recuperar columnas innecesarias consume ancho de banda, memoria y tiempo de procesamiento, especialmente si tu tabla incluye datos pesados como im\u00e1genes (BLOB<\/code>) o textos largos (TEXT<\/code>). La soluci\u00f3n es simple: selecciona solo las columnas que vas a usar.<\/p>\n\n\n\n

Ejemplo Pr\u00e1ctico: Lista de Productos en una Tienda Online<\/h3>\n\n\n\n

Contexto: Imagina una tienda online que muestra una lista de productos con su nombre, precio y categor\u00eda en una p\u00e1gina web. La tabla products<\/code> tiene 1 mill\u00f3n de filas, pero incluye columnas pesadas como image<\/code> (tipo BLOB, ~500 KB por imagen) y description<\/code> (tipo TEXT, ~2 KB).<\/p>\n\n\n\n

Consulta Incorrecta (Carga Datos Innecesarios):<\/strong><\/p>\n\n\n\n

SELECT * FROM products WHERE category = 'Electronics';<\/code><\/pre>\n\n\n\n
Problema:<\/strong> Esta consulta trae todas las columnas, incluyendo image<\/code> y description<\/code>. Para 1 mill\u00f3n de filas, transfiere aproximadamente 500 GB de datos (500 KB por fila). En PostgreSQL<\/strong>, bajo carga moderada, tarda unos 10 segundos en ejecutarse.<\/p>\n\n\n\n
Consulta Optimizada (Selecci\u00f3n Espec\u00edfica):<\/strong><\/p>\n\n\n\n
SELECT name, price, category\nFROM products\nWHERE category = 'Electronics';<\/code><\/pre>\n\n\n\n
Soluci\u00f3n:<\/strong> Al seleccionar solo las columnas necesarias, reduces la transferencia a unos 10 MB (10 KB por fila). El tiempo de ejecuci\u00f3n baja a 0.5 segundos.<\/p>\n\n\n\n
C\u00f3mo Detectar el Problema:<\/strong><\/p>\n\n\n\n
En PostgreSQL<\/strong>, puedes verificar el tama\u00f1o de las columnas:<\/p>\n\n\n\n
SELECT pg_column_size(image) AS image_size, pg_column_size(description) AS desc_size\nFROM products LIMIT 1;\n-- Resultado: image_size ~ 500 KB, desc_size ~ 2 KB<\/code><\/pre>\n\n\n\n
En MySQL<\/strong>, revisa los tipos de datos:<\/p>\n\n\n\n
SELECT column_name, data_type, character_maximum_length\nFROM information_schema.columns\nWHERE table_name = 'products';<\/code><\/pre>\n\n\n\n
Beneficios:<\/strong><\/p>\n\n\n\n
    \n
  • Menos datos transferidos: De 500 GB a 10 MB.<\/li>\n\n\n\n
  • Respuesta m\u00e1s r\u00e1pida: De 10 segundos a 0.5 segundos.<\/li>\n\n\n\n
  • Perfecto para picos de tr\u00e1fico: Ideal para eventos como el Black Friday en una tienda online.<\/li>\n<\/ul>\n\n\n\n
    Consejo Extra:<\/strong> Si rara vez usas columnas pesadas como image<\/code>, considera moverlas a una tabla separada con una relaci\u00f3n 1:1. Esto mantiene tu tabla principal ligera y \u00e1gil.<\/p>\n\n\n\n
    2. Aprovecha los \u00cdndices para Acelerar B\u00fasquedas<\/strong><\/h2>\n\n\n\n
    Los \u00edndices son como el \u00edndice de un libro: te ayudan a encontrar datos r\u00e1pidamente sin revisar cada p\u00e1gina. Son ideales para acelerar filtros WHERE<\/code>, uniones JOIN <\/code>y ordenamientos ORDER BY<\/code>. Sin embargo, ten cuidado: los \u00edndices ralentizan las inserciones y actualizaciones, as\u00ed que \u00fasalos estrat\u00e9gicamente.<\/p>\n\n\n\n
    Ejemplo Pr\u00e1ctico: Reportes de Pedidos en Log\u00edstica<\/h3>\n\n\n\n
    Contexto:<\/strong> Una aplicaci\u00f3n de log\u00edstica genera reportes diarios de pedidos filtrados por region<\/code> y status<\/code>. La tabla orders<\/code> tiene 10 millones de filas.<\/p>\n\n\n\n
    Consulta Sin \u00cdndice (Lenta):<\/strong><\/p>\n\n\n\n
    SELECT id, total\nFROM orders\nWHERE region = 'EU' AND status = 'Pending';<\/code><\/pre>\n\n\n\n
    Problema:<\/strong> Sin un \u00edndice, la base de datos escanea todas las 10 millones de filas, lo que toma unos 8 segundos.<\/p>\n\n\n\n
    Consulta con \u00cdndice Compuesto:<\/strong><\/p>\n\n\n\n
    CREATE INDEX idx_orders_region_status ON orders (region, status);<\/code><\/pre>\n\n\n\n
    SELECT id, total\nFROM orders\nWHERE region = 'EU' AND status = 'Pending';<\/code><\/pre>\n\n\n\n
    Soluci\u00f3n:<\/strong> El \u00edndice permite un Index Scan, reduciendo el tiempo a 0.1 segundos.<\/p>\n\n\n\n
    C\u00f3mo Confirmar que el \u00cdndice se Usa:<\/strong><\/p>\n\n\n\n
    EXPLAIN SELECT id, total FROM orders WHERE region = 'EU' AND status = 'Pending';\n-- Resultado: Index Scan using idx_orders_region_status<\/code><\/pre>\n\n\n\n
    Beneficios:<\/strong><\/p>\n\n\n\n
      \n
    • Ejecuci\u00f3n m\u00e1s r\u00e1pida: De 8 segundos a 0.1 segundos.<\/li>\n\n\n\n
    • Ideal para reportes en tiempo real: Perfecto para dashboards de log\u00edstica.<\/li>\n\n\n\n
    • Cuidado con inserciones frecuentes: Si tu tabla recibe muchos datos nuevos (por ejemplo, 1,000 pedidos por minuto), eval\u00faa el impacto del \u00edndice.<\/li>\n<\/ul>\n\n\n\n
      Consejo Extra:<\/strong> En MySQL<\/strong>, usa EXPLAIN FORMAT=JSON<\/code> para obtener un an\u00e1lisis detallado del plan de ejecuci\u00f3n.<\/p>\n\n\n\n
      3. Simplifica los JOINs con EXISTS o Subconsultas<\/strong><\/h2>\n\n\n\n
      Los JOIN son poderosos, pero pueden volverse costosos si procesan m\u00e1s filas de las necesarias. Cuando solo necesitas verificar si algo existe (como un cliente con ciertas condiciones), usar EXISTS<\/code> o subconsultas es m\u00e1s eficiente que un JOIN.<\/p>\n\n\n\n
      Ejemplo Pr\u00e1ctico: Clientes VIP en un CRM*<\/h3>\n\n\n\n
      Contexto:<\/strong> Una aplicaci\u00f3n de CRM quiere identificar clientes \u00abVIP\u00bb que hicieron compras mayores a $10,000 en 2024. La tabla customers<\/code> tiene 500,000 filas, y orders<\/code> tiene 50 millones.<\/p>\n\n\n\n
      JOIN Costoso:<\/strong><\/p>\n\n\n\n
      SELECT DISTINCT c.id, c.name\nFROM customers c\nJOIN orders o ON c.id = o.customer_id\nWHERE o.order_date >= '2024-01-01' AND o.total > 10000;<\/code><\/pre>\n\n\n\n
      Problema:<\/strong> Procesa 50 millones de filas y genera duplicados, tomando 15 segundos.<\/p>\n\n\n\n
      Soluci\u00f3n con EXISTS:<\/strong><\/p>\n\n\n\n
      SELECT c.id, c.name\nFROM customers c\nWHERE EXISTS (\n   SELECT 1 FROM orders o\n   WHERE o.customer_id = c.id\n   AND o.order_date >= '2024-01-01'\n   AND o.total > 10000\n);<\/code><\/pre>\n\n\n\n
      Soluci\u00f3n:<\/strong> La base de datos detiene la b\u00fasqueda en cuanto encuentra una coincidencia, reduciendo el tiempo a 0.8 segundos.<\/p>\n\n\n\n
      Beneficios:<\/strong><\/p>\n\n\n\n
        \n
      • Mucho m\u00e1s r\u00e1pido: De 15 segundos a 0.8 segundos.<\/li>\n\n\n\n
      • Escalabilidad: Funciona bien incluso con tablas enormes.<\/li>\n<\/ul>\n\n\n\n
        Consejo Extra:<\/strong> En MySQL<\/strong>, si EXISTS no es lo suficientemente r\u00e1pido, prueba con IN y aseg\u00farate de que las columnas tengan \u00edndices. Usa EXPLAIN para comparar:<\/p>\n\n\n\n
        EXPLAIN SELECT c.id, c.name FROM customers c WHERE EXISTS (...);<\/code><\/pre>\n\n\n\n
        4. Filtra lo Antes Posible y Evita Funciones en \u00cdndices<\/strong><\/h2>\n\n\n\n
        Usar funciones como MONTH()<\/code> o UPPER()<\/code> en columnas indexadas impide que la base de datos aproveche los \u00edndices, lo que ralentiza las consultas. Siempre que puedas, reescribe las consultas para filtrar directamente sobre los datos originales.<\/p>\n\n\n\n
        Ejemplo Pr\u00e1ctico: Reportes Financieros<\/h3>\n\n\n\n
        Contexto:<\/strong> Una aplicaci\u00f3n de an\u00e1lisis financiero genera reportes de transacciones de mayo de 2024. La tabla transactions<\/code> tiene 100 millones de filas y un \u00edndice en transaction_date<\/code>.<\/p>\n\n\n\n
        Consulta Incorrecta (No Usa el \u00cdndice):<\/strong><\/p>\n\n\n\n
        SELECT * FROM transactions\nWHERE MONTH(transaction_date) = 5 AND YEAR(transaction_date) = 2024;<\/code><\/pre>\n\n\n\n
        Problema:<\/strong> Al usar MONTH()<\/code> y YEAR()<\/code>, la base de datos ignora el \u00edndice y escanea 100 millones de filas, tomando 20 segundos.<\/p>\n\n\n\n
        Consulta Optimizada (Aprovecha el \u00cdndice):<\/strong><\/p>\n\n\n\n
        SELECT * FROM transactions\nWHERE transaction_date BETWEEN '2024-05-01' AND '2024-05-31';<\/code><\/pre>\n\n\n\n
        Soluci\u00f3n:<\/strong> Usa el \u00edndice en transaction_date<\/code>, reduciendo el tiempo a 0.5 segundos.<\/p>\n\n\n\n
        Truco Avanzado:<\/strong> Si trabajas con tablas muy grandes, considera particionarlas por rango de fechas:<\/p>\n\n\n\n
        CREATE TABLE transactions (\n   id BIGINT,\n   transaction_date DATE,\n   amount DECIMAL(10,2)\n) PARTITION BY RANGE (transaction_date);<\/code><\/pre>\n\n\n\n
        Beneficios:<\/strong><\/p>\n\n\n\n
          \n
        • Rendimiento mejorado: De 20 segundos a 0.5 segundos.<\/li>\n\n\n\n
        • Escalabilidad: El particionamiento es ideal para bases de datos masivas.<\/li>\n<\/ul>\n\n\n\n
          Consejo Extra:<\/strong> Usa EXPLAIN ANALYZE<\/code> en PostgreSQL <\/strong>para verificar que el \u00edndice se est\u00e1 utilizando correctamente.<\/p>\n\n\n\n
          5. Paginaci\u00f3n Eficiente para Evitar Consultas Lentas<\/strong><\/h2>\n\n\n\n
          Cuando muestras resultados paginados (como un feed de publicaciones), usar OFFSET<\/code> puede ser un problema en tablas grandes porque escanea filas que no necesitas. La paginaci\u00f3n por clave (keyset pagination) es mucho m\u00e1s r\u00e1pida.<\/p>\n\n\n\n
          Ejemplo Pr\u00e1ctico: Feed de Publicaciones en Redes Sociales<\/h3>\n\n\n\n
          Contexto:<\/strong> Una red social muestra publicaciones ordenadas por post_id<\/code> en un feed. La tabla posts<\/code> tiene 50 millones de filas.<\/p>\n\n\n\n
          Consulta Lenta con OFFSET:<\/strong><\/p>\n\n\n\n
          SELECT id, content FROM posts ORDER BY post_id DESC LIMIT 10 OFFSET 10000;<\/code><\/pre>\n\n\n\n
          Problema:<\/strong> Escanea 10,010 filas para saltar las primeras 10,000, tomando 12 segundos.<\/p>\n\n\n\n
          Paginaci\u00f3n por Clave (Keyset Pagination):<\/strong><\/p>\n\n\n\n
          SELECT id, content FROM posts\nWHERE post_id < 49000000  -- \u00daltimo post_id de la p\u00e1gina anterior\nORDER BY post_id DESC LIMIT 10;<\/code><\/pre>\n\n\n\n
          Soluci\u00f3n:<\/strong> Usa el \u00edndice en post_id<\/code>, reduciendo el tiempo a 0.2 segundos.<\/p>\n\n\n\n
          C\u00f3mo Implementarlo:<\/strong> Pasa el post_id<\/code> de la \u00faltima publicaci\u00f3n en la URL, por ejemplo: \/feed?last_id=49000000<\/code>.<\/p>\n\n\n\n
          Beneficios:<\/strong><\/p>\n\n\n\n
            \n
          • Carga m\u00e1s r\u00e1pida: De 12 segundos a 0.2 segundos.<\/li>\n\n\n\n
          • Mejor experiencia: Los usuarios disfrutan de un feed que carga al instante.<\/li>\n<\/ul>\n\n\n\n
            Consejo Extra:<\/strong> Aseg\u00farate de que la columna usada para paginaci\u00f3n (como post_id<\/code>) tenga un \u00edndice.<\/p>\n\n\n\n
            6. Usa EXPLAIN para Descubrir Qu\u00e9 Est\u00e1 Pasando<\/h2>\n\n\n\n
            La herramienta EXPLAIN<\/code> es como una radiograf\u00eda de tus consultas: te muestra c\u00f3mo la base de datos las ejecuta, revelando cuellos de botella, \u00edndices faltantes o pasos costosos.<\/p>\n\n\n\n
            Ejemplo Pr\u00e1ctico: Inventario de Productos<\/h3>\n\n\n\n
            Contexto:<\/strong> Una aplicaci\u00f3n de inventario busca productos con precio mayor a $100 y pedidos en 2024. Las tablas son products<\/code> (1 mill\u00f3n de filas) y orders<\/code> (10 millones de filas).<\/p>\n\n\n\n
            Consulta Analizada:<\/strong><\/p>\n\n\n\n
            EXPLAIN ANALYZE\nSELECT p.name, o.quantity\nFROM products p\nJOIN orders o ON p.id = o.product_id\nWHERE p.price > 100 AND o.order_date >= '2024-01-01';<\/code><\/pre>\n\n\n\n
            Resultado (PostgreSQL):<\/strong><\/p>\n\n\n\n
            Nested Loop  (cost=0.85..12345.67 rows=5000 width=40) (actual time=0.050..1500.123 ms)\n  -> Seq Scan on products p  (cost=0.00..5000.00 rows=10000 width=20)\n         Filter: (price > 100)\n  -> Index Scan on orders o  (cost=0.85..7.34 rows=500 width=20)\n         Index Cond: (product_id = p.id)\n         Filter: (order_date >= '2024-01-01')<\/code><\/pre>\n\n\n\n
            Qu\u00e9 Nos Dice:<\/strong> El Seq Scan<\/code> en products<\/code> indica que falta un \u00edndice en price<\/code>. Crearlo mejora el rendimiento:<\/p>\n\n\n\n
            CREATE INDEX idx_products_price ON products (price);<\/code><\/pre>\n\n\n\n
            Impacto: <\/strong>Reduce el tiempo de 1.5 segundos a 0.3 segundos.<\/p>\n\n\n\n
            Beneficios:<\/strong><\/p>\n\n\n\n
              \n
            • Diagn\u00f3stico claro: Identifica problemas como escaneos completos (Seq Scan) o ordenamientos lentos.<\/li>\n\n\n\n
            • Optimizaci\u00f3n precisa: Sabes exactamente d\u00f3nde a\u00f1adir \u00edndices.<\/li>\n<\/ul>\n\n\n\n
              Consejo Extra:<\/strong> Usa herramientas visuales como pgAdmin (PostgreSQL<\/strong>) o MySQL Workbench para explorar los planes de ejecuci\u00f3n de forma m\u00e1s amigable.<\/p>\n\n\n\n
              7. Actualiza e Inserta en Lotes para Evitar Bloqueos<\/h2>\n\n\n\n
              Las operaciones masivas, como actualizar millones de filas, pueden bloquear tablas y afectar a los usuarios. Procesar en lotes peque\u00f1os mantiene tu sistema estable y accesible.<\/p>\n\n\n\n
              Ejemplo Pr\u00e1ctico: Descuentos en Black Friday<\/h3>\n\n\n\n
              Contexto:<\/strong> Una tienda online aplica un 10% de descuento a todos los productos de la categor\u00eda \u00abClothing\u00bb durante el Black Friday. La tabla products<\/code> tiene 5 millones de filas.<\/p>\n\n\n\n
              Consulta Problem\u00e1tica (Bloqueo Largo):<\/strong><\/p>\n\n\n\n
              UPDATE products SET price = price * 0.9 WHERE category = 'Clothing';<\/code><\/pre>\n\n\n\n
              Problema:<\/strong> Bloquea la tabla durante 30 segundos, afectando a los usuarios que intentan comprar.<\/p>\n\n\n\n
              Soluci\u00f3n en Lotes:<\/strong><\/p>\n\n\n\n
              BEGIN\n    FOR i IN 1..500 LOOP\n        UPDATE products\n        SET price = price * 0.9\n        WHERE category = 'Clothing'\n        AND id BETWEEN ((i-1)*10000 + 1) AND (i*10000);\n        COMMIT;\n        PERFORM pg_sleep(0.1); -- Pausa breve para no saturar\n    END LOOP;\nEND $$;<\/code><\/pre>\n\n\n\n
              Soluci\u00f3n:<\/strong> Procesa 10,000 filas por lote, cada uno tomando 0.1 segundos. Completa en 50 segundos sin interrumpir a los usuarios.<\/p>\n\n\n\n
              Para Inserciones Masivas:<\/strong><\/p>\n\n\n\n
              INSERT INTO orders (customer_id, total)\nVALUES (1, 100), (2, 200), ...; -- Hasta 1,000 filas por lote<\/code><\/pre>\n\n\n\n
              Beneficios:<\/strong><\/p>\n\n\n\n
                \n
              • Sin interrupciones: Los usuarios no notan bloqueos.<\/li>\n\n\n\n
              • Sistema estable: Evita picos de carga en el servidor.<\/li>\n<\/ul>\n\n\n\n
                Consejo Extra:<\/strong> Automatiza estas operaciones con scripts en Python (usando psycopg2) o procedimientos almacenados para mayor comodidad.<\/p>\n\n\n\n
                8. Monitorea y Mant\u00e9n tus Bases de Datos<\/strong><\/h2>\n\n\n\n
                Optimizar consultas no es algo que haces una vez y olvidas. A medida que tus datos crecen, necesitas monitorear el rendimiento y ajustar \u00edndices, consultas y configuraciones.<\/p>\n\n\n\n
                Herramientas \u00datiles:<\/strong><\/p>\n\n\n\n
                  \n
                • Logs de consultas lentas: Activa log_min_duration_statement<\/code> en PostgreSQL <\/strong>o slow_query_log<\/code> en MySQL.<\/li>\n\n\n\n
                • Estad\u00edsticas del motor: Usa pg_stat_statements<\/code> (PostgreSQL<\/strong>) o performance_schema<\/code> (MySQL<\/strong>).<\/li>\n\n\n\n
                • Monitoreo externo: Herramientas como New Relic, Datadog o Percona Monitoring te dan una vista completa.<\/li>\n<\/ul>\n\n\n\n
                  Ejemplo: Activar Logs en PostgreSQL<\/h3>\n\n\n\n
                  SET log_min_duration_statement = 1000; -- Registra consultas que toman m\u00e1s de 1 segundo<\/code><\/pre>\n\n\n\n
                  Beneficio<\/strong>: Detecta consultas lentas en tiempo real y act\u00faa antes de que afecten a los usuarios.<\/p>\n\n\n\n
                  Haz de la Optimizaci\u00f3n un H\u00e1bito<\/h2>\n\n\n\n
                  Optimizar consultas SQL <\/strong>es mucho m\u00e1s que aplicar trucos t\u00e9cnicos: es una forma de garantizar que tus aplicaciones sean r\u00e1pidas, escalables y agradables para los usuarios. Una consulta mal dise\u00f1ada puede ralentizar tu sistema, aumentar los costos de infraestructura y complicar el crecimiento de tu proyecto. Por el contrario, cada consulta optimizada te acerca a un sistema eficiente y preparado para manejar m\u00e1s datos y usuarios.<\/p>\n\n\n\n
                  Con estrategias como elegir solo las columnas necesarias, crear \u00edndices inteligentes, evitar operaciones pesadas y monitorear el rendimiento, puedes marcar una gran diferencia. Te invito a probar estas t\u00e9cnicas en tus proyectos, experimentar con herramientas como EXPLAIN y convertir la optimizaci\u00f3n en parte de tu rutina como desarrollador.<\/p>\n\n\n\n
                  \u00bfTienes un problema de rendimiento en tus consultas SQL<\/strong>? Empieza hoy a optimizar y lleva tus aplicaciones al siguiente nivel.<\/p>\n","protected":false},"excerpt":{"rendered":"
                  Si trabajas con bases de datos, sabes que una consulta SQL mal optimizada puede ralentizar tu aplicaci\u00f3n, frustrar a los usuarios y sobrecargar el servidor. Optimizar tus consultas no es solo una tarea t\u00e9cnica, sino una forma de mejorar la experiencia de tus usuarios y hacer que tu sistema escale sin problemas. En este art\u00edculo, […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[18],"tags":[20],"class_list":["post-76","post","type-post","status-publish","format-standard","hentry","category-guia","tag-sql"],"_links":{"self":[{"href":"https:\/\/juredev.com\/blog\/wp-json\/wp\/v2\/posts\/76","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/juredev.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/juredev.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/juredev.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/juredev.com\/blog\/wp-json\/wp\/v2\/comments?post=76"}],"version-history":[{"count":0,"href":"https:\/\/juredev.com\/blog\/wp-json\/wp\/v2\/posts\/76\/revisions"}],"wp:attachment":[{"href":"https:\/\/juredev.com\/blog\/wp-json\/wp\/v2\/media?parent=76"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/juredev.com\/blog\/wp-json\/wp\/v2\/categories?post=76"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/juredev.com\/blog\/wp-json\/wp\/v2\/tags?post=76"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}