Guía de EXPLAIN ANALYZE en MySQL: cómo leer el plan de ejecución de verdad

Cuando trabajamos con performance en MySQL, entender el plan de ejecución es fundamental.

EXPLAIN nos da una idea pero EXPLAIN ANALYZE nos dice la verdad.

Si hacemos: 

EXPLAIN ANALYZE SELECT ...

Ejecuta la query (Ojo! si la query demora tanto que no termina la ejecución, ya esta no podemos usarlo) y devuelve:

• El plan de ejecución
• Métricas reales de ejecución
• Comparación entre estimaciones y realidad

Ejemplo típico:

-> Nested loop inner join  (cost=0.787 rows=1.25)

   (actual time=0.0644..0.0705 rows=1 loops=1)

    -> Index lookup on tabla1 ...

       (cost=...) (actual time=... rows=... loops=...)

    -> Index lookup on tabla2 ...

       (cost=...) (actual time=... rows=... loops=...)

Esto es un árbol de ejecución:

• De arriba hacia abajo
• Cada nodo es una operación

Conceptos clave (los más importantes):

cost

(cost=0.787 rows=1.25)

Es una estimación del optimizador.

Incluye:

• I/O esperado
• CPU estimado
• Lecturas de índice / tabla

⚠️ Importante:

❌ No es tiempo real

❌ No está en milisegundos

✔️ Solo sirve para comparar planes

rows (estimado)

rows=1.25

Cantidad estimada de filas.

Puede ser decimal porque:

• Es un promedio estadístico
• Ej: 1.25 filas por iteración

actual time

actual time=0.0644..0.0705

Tiempo real en milisegundos:

• Primer valor → tiempo hasta la primera fila
• Segundo valor → tiempo hasta la última fila

actual rows

rows=1

Filas reales procesadas.

loops

loops=1

Cuántas veces se ejecutó ese paso.

Relación clave

filas totales ≈ rows × loops

Tipos de operaciones (nodos del plan)

Nested Loop Join

MySQL usa principalmente este tipo de join.

Funcionamiento:

1. Toma una fila de la tabla A
2. Busca coincidencias en tabla B
3. Repite

Index Lookup

Index lookup on tabla using index_name

Búsqueda usando índice:

✔️ Rápido

✔️ Ideal

Covering Index Lookup

El índice tiene todas las columnas necesarias.

✔️ No accede a la tabla

✔️ Más eficiente

Table Scan

Table scan on tabla

Escaneo completo.

❌ Costoso

❌ Señal de posible problema

Range Scan

Range scan on index

Usa índice, pero en un rango:

WHERE fecha BETWEEN ...

✔️ Bueno, pero no tan óptimo como lookup exacto

Filter

Filter: (condición)

Filtra filas después de leerlas.

⚠️ Si aparece mucho → puede faltar índice

Sort

Ordenamiento (`ORDER BY`)

❌ Puede usar memoria o disco

Temporary Table

Using temporary

MySQL crea tabla intermedia y puede impactar performance

Cómo leer un plan (estrategia real)

Paso 1: leer de abajo hacia arriba

• Primero las hojas (tablas base)
• Luego los joins

Paso 2: comparar estimado vs real

rows=1000 vs actual rows=10

Mala estimación → posible mal plan

Paso 3: mirar loops

Detecta:

• nested loops costosos
• operaciones repetidas

Paso 4: identificar scans

Buscar:

Table scan

Candidato a optimización

Problemas comunes detectables

1. Mala estimación

2. Full table scan innecesario

3. Nested loops costosos

4. Filtros tardíos

Veamos un ejemplo:

-> Nested loop inner join  (rows=1.25)

   (actual rows=1 loops=1)

    -> Covering index lookup on autores

       (rows=1 actual rows=1)

    -> Index lookup on libros

       (rows=1.25 actual rows=1)

Interpretación:

1. Encuentra 1 autor

2. Estima 1.25 libros por autor

3. Realmente hay 1

✔️ Plan correcto

✔️ Estimación aceptable

EXPLAIN ANALYZE es la herramienta más poderosa para entender performance en MySQL.

Pero requiere cambiar la mentalidad:

• No mirar solo el resultado
• Entender cómo MySQL llega a él

std::optional en C++

En muchos lenguajes modernos existe alguna forma de representar “un valor que puede no existir”:

• Optional en Java
• Option en Scala
• Maybe en Haskell
• Option en Rust (Some/None)

En C++, la respuesta oficial es std::optional, introducido en C++17 y mejorado muchísimo en C++23 con operaciones monádicas.

¿Qué problema resuelve?

Antes de optional, era común devolver:

• nullptr
• valores mágicos (-1)
• flags adicionales
• excepciones

Ejemplo clásico:

int findUserId(const std::string& name) {

    if(name == "emanuel")

        return 10;

    return -1;

}

Problema:

• -1 no expresa claramente ausencia
• alguien podría olvidarse de validarlo
• el contrato del método no es explícito

Con std::optional:

#include <optional>

std::optional<int> findUserId(const std::string& name) {

    if(name == "emanuel")

        return 10;

    return std::nullopt;

}

Ahora el tipo expresa claramente: “puede devolver un entero… o no”.

Crear un optional

std::optional<int> number = 10;

Vacío:

std::optional<int> empty = std::nullopt;

Verificar si tiene valor

if(number.has_value()) {

    std::cout << "Tiene valor";

}

o más idiomático:

if(number) {

    std::cout << "Tiene valor";

}

Obtener el valor

std::cout << number.value();

Ojo! Si no tiene valor, lanza excepción.

Más seguro:

if(number) {

    std::cout << *number;

}

Valor por defecto

std::optional<int> x;

std::cout << x.value_or(0);

Resultado: 0

Muy parecido a:

• orElse() en Java
• getOrElse() en Scala

¿Por qué es mejor que punteros?

Muchas APIs antiguas usan punteros nullable:

User* findUser();

Problemas:

• ownership ambiguo
• riesgo de dangling pointers
• semántica poco clara

Con optional:

std::optional<User> findUser();

El contrato queda explícito y seguro.

En programación funcional, una mónada permite:

• encadenar operaciones
• evitar checks manuales
• propagar automáticamente ausencia/error

Antes de C++23 esto era incómodo.

Había que hacer:

if(result) {

    ...

}

todo el tiempo.

C++23 agregó operaciones monádicas oficiales.

transform

Equivalente a map.

Transforma el valor si existe.

std::optional<int> number = 10;

auto result =

    number.transform([](int x) {

        return x * 2;

    });

std::cout << *result;

Resultado: 20

Si el optional está vacío, no ejecuta nada.

and_then

Equivalente a flatMap.

Permite encadenar funciones que devuelven optional.

std::optional<int> parse(const std::string& s) {

    if(s == "42")

        return 42;

    return std::nullopt;

}

auto result =

    parse("42")

        .and_then([](int x) -> std::optional<int> {

            if(x > 0)

                return x * 2;

            return std::nullopt;

        });

Diferencia entre transform y and_then

transform convierte:

optional<T> -> optional<U>

cuando la función devuelve un valor normal, and_then convierte:

optional<T> -> optional<U>

pero la función YA devuelve optional.

Evita nested optionals: optional<optional<int>>

or_else

Permite ejecutar lógica si está vacío.

std::optional<int> value;

value.or_else([] {

    std::cout << "No había valor";

    return std::optional<int>{0};

});

Ahora podemos escribir código mucho más declarativo:

auto result =

    parse("42")

        .transform([](int x) {

            return x * 2;

        })

        .and_then([](int x) -> std::optional<int> {

            if(x < 100)

                return x;

            return std::nullopt;

        })

        .or_else([] {

            return std::optional<int>{0};

        });

Esto ya se parece muchísimo a:

• Scala
• Haskell
• Rust
• Kotlin

¿Cuándo usar optional?

Ideal para:

• búsquedas
• parseos
• resultados opcionales
• operaciones que pueden fallar naturalmente

¿Cuándo NO usarlo?

• errores complejos
• información detallada de fallos

En esos casos es mejor:

• std::expected (C++23)
• excepciones

std::optional empezó en C++17 como una forma segura de representar ausencia de valor.

Pero en C++23 evolucionó muchísimo:

• transform
• and_then
• or_else

lo convierten en una herramienta claramente influenciada por programación funcional y mónadas como Maybe.

C++ sigue siendo multiparadigma, pero cada vez incorpora más ideas del mundo funcional… sin dejar de ser C++.

Errores más comunes al usar particionado en MySQL (y cómo evitarlos)

El particionado en MySQL es una herramienta poderosa, pero también tiene varias reglas “ocultas” que suelen generar errores frustrantes.

1. La clave primaria no incluye la columna de partición

Este es el clásico:

PARTITION BY RANGE (anio_publicacion)

PRIMARY KEY (id_libro)

Error: A PRIMARY KEY must include all columns in the table's partitioning function

Solución

PRIMARY KEY (id_libro, anio_publicacion)

MySQL necesita garantizar unicidad global entre particiones. Por eso tiene que ser primary key la partición. 

2. Índices UNIQUE que no incluyen la columna de partición

No solo afecta a la PK:

UNIQUE (email)

También falla si email no incluye la columna de partición.

Solución: 

UNIQUE (email, anio_publicacion)

3. Pensar que el particionado reemplaza índices

Error conceptual muy común:

> “Particiono y ya no necesito índices”

❌ Incorrecto

Particionado → reduce datos a escanear

Índices → optimizan acceso dentro de la partición

Se complementan, no compiten.

4. No usar la columna de partición en las consultas

Ejemplo:

SELECT * FROM logs WHERE usuario = 'Juan';

MySQL tiene que escanear todas las particiones.

Mejor:

SELECT * FROM logs 

WHERE fecha >= '2026-01-01'

AND usuario = 'Juan';

Activa partition pruning

5. Definir mal los rangos (RANGE)

Ejemplo peligroso:

PARTITION p2023 VALUES LESS THAN (2023),

PARTITION p2024 VALUES LESS THAN (2024)

 ¿Dónde van los valores de 2023? (error lógico)

Correcto:

PARTITION p2023 VALUES LESS THAN (2024)

6. Olvidarse de MAXVALUE

PARTITION p2024 VALUES LESS THAN (2025)

¿Qué pasa con datos futuros?

Solución:

PARTITION pFuture VALUES LESS THAN MAXVALUE

Evita errores al insertar nuevos datos.

7. Usar particionado en tablas pequeñas

Overkill total.

Problema:

• Más complejidad
• Sin beneficios reales
• Incluso puede empeorar performance

8. Pensar que particionado = sharding

Error conceptual importante.

Diferencia

Particionado → dentro de una misma tabla (mismo servidor)

Sharding → distribución en múltiples servidores

9. Usar funciones no determinísticas o inválidas

Ejemplo:

PARTITION BY RANGE (YEAR(NOW()))

❌ No permitido

10. Problemas con AUTO_INCREMENT

Cuando combinás:

• AUTO_INCREMENT
• PK compuesta
• Particionado

Puede volverse confuso

Tip:

El AUTO_INCREMENT:

• Debe estar en una clave indexada
• Y respetar la estructura de la PK

12. Creer que DELETE masivo es la mejor opción

DELETE FROM logs WHERE fecha < '2023-01-01';

Lento, bloqueante

Mejor con particionado:

ALTER TABLE logs DROP PARTITION p2022;

Instantáneo

El particionado en MySQL:

✔️ Puede mejorar muchísimo la performance

❌ Pero introduce restricciones de diseño importantes

La clave es entender que:

• No es transparente
• Afecta claves, índices y consultas
• Debe planificarse desde el diseño

Particionado de Tablas en MySQL: Qué es, tipos y cuándo usarlo

El particionado en MySQL es una técnica que permite dividir una tabla grande en partes más pequeñas (particiones), manteniendo la ilusión de que sigue siendo una única tabla.

Esto es clave cuando trabajamos con:

• Grandes volúmenes de datos (millones o billones de filas)
• Consultas que pueden beneficiarse de “leer menos datos”
• Mantenimiento más eficiente (archivar, borrar, etc.)

Imaginemos una tabla de logs:

logs(id, fecha, usuario, accion)

Con millones de registros, consultas como:

SELECT * FROM logs WHERE fecha >= '2026-01-01';

terminan escaneando demasiados datos.

Con particionado, MySQL puede hacer partition pruning:

• Solo accede a las particiones relevantes
• Reduce I/O y mejora performance

Tipos de particionado en MySQL

 RANGE (por rango)

Ideal para fechas o valores ordenados.

CREATE TABLE logs (

  id INT,

  fecha DATE,

  mensaje VARCHAR(255)

)

PARTITION BY RANGE (YEAR(fecha)) (

  PARTITION p2023 VALUES LESS THAN (2024),

  PARTITION p2024 VALUES LESS THAN (2025),

  PARTITION pFuture VALUES LESS THAN MAXVALUE

);

Muy usado para:

• Logs
• Eventos
• Datos históricos

LIST (por valores específicos)

CREATE TABLE usuarios (

  id INT,

  pais VARCHAR(50)

)

PARTITION BY LIST COLUMNS(pais) (

  PARTITION p_latam VALUES IN ('Argentina', 'Brasil'),

  PARTITION p_europa VALUES IN ('España', 'Francia')

);

Útil cuando tenés categorías bien definidas.

HASH (distribución uniforme)

CREATE TABLE pedidos (

  id INT,

  cliente_id INT

)

PARTITION BY HASH(cliente_id)

PARTITIONS 4;

MySQL distribuye automáticamente los datos.

KEY (similar a HASH pero interno)

CREATE TABLE sesiones (

  id INT,

  usuario_id INT

)

PARTITION BY KEY(usuario_id)

PARTITIONS 4;

Usa funciones hash internas de MySQL.

Limitaciones importantes

Antes de usar particionado, hay que tener en cuenta:

• Todas las claves primarias deben incluir la columna de partición
• No todas las engines soportan particionado (InnoDB sí)
• No reemplaza índices (se complementan)
• Puede complicar el diseño si no se usa bien

Cuándo usar particionado:

✔️ Tablas muy grandes (millones de filas)

✔️ Consultas filtradas por la columna de partición

✔️ Necesidad de borrar datos antiguos fácilmente

Cuándo NO usar particionado:

❌ Tablas pequeñas

❌ Consultas que no usan la columna de partición

❌ Como reemplazo de índices

Kotlin 2.4.0

La versión 2.4.0 de Kotlin sigue consolidando muchas características que venían evolucionando desde releases anteriores.

Más que agregar “una gran feature”, esta versión termina de estabilizar varias piezas importantes del ecosistema.

El nuevo compilador K2 dejó de sentirse “experimental” y pasó a ser la base real del futuro de Kotlin.

¿Qué aporta?

• Compilaciones más rápidas
• Mejor análisis de tipos
• Mensajes de error más claros
• Infraestructura más simple para futuras features

K2 no es solamente una optimización, es prácticamente una reescritura del compilador.

Los Context Parameters siguen evolucionando y acercan a Kotlin a ideas similares a:

• implicits de Scala
• type classes funcionales
• dependency injection implícita

Ejemplo:

context(Logger)

fun processOrder() {

    log("Processing order")

}

Esto permite escribir APIs mucho más declarativas.

Kotlin sigue empujando fuerte el desarrollo multiplataforma; en 2.4.0 hay mejoras importantes en:

• compilación incremental
• interoperabilidad con iOS
• performance de Kotlin/Native
• sharing de código entre plataformas

El garbage collector y el manejo de memoria continúan mejorando para Kotlin/Native. 

Esto impacta directamente en:

• apps iOS
• aplicaciones embebidas
• performance general

Históricamente Kotlin/Native era uno de los puntos más débiles del ecosistema. Las últimas versiones muestran una mejora enorme.

También hay mejoras en:

• IntelliJ IDEA
• Gradle
• debugging
• análisis estático
• tiempos de indexing

Muchas veces estas mejoras no aparecen en los titulares, pero son las que realmente cambian la experiencia diaria.

Lo más interesante de Kotlin 2.4.0 quizás no sea una feature puntual.

Es que muchas ideas que antes parecían experimentales ahora empiezan a sentirse “normales”:

• K2
• Multiplatform
• Native
• Context Parameters

Kotlin está entrando en una etapa mucho más madura del lenguaje.

Cómo usar EXPLAIN en MySQL para optimizar tus consultas

EXPLAIN te muestra el plan de ejecución de una consulta SQL.

En otras palabras, responde preguntas como:

• ¿Qué tablas se recorren?
• ¿En qué orden?
• ¿Se están usando índices?
• ¿Cuántas filas se estiman procesar?

EXPLAIN 

SELECT * 

FROM libro 

WHERE titulo = 'El Quijote';

Salida típica:

| id | select_type | table | type | possible_keys | key  | rows | Extra       |

| -- | ----------- | ----- | ---- | ------------- | ---- | ---- | ----------- |

| 1  | SIMPLE      | libro | ALL  | idx_titulo    | NULL | 1000 | Using where |

Qué podemos saber con esto, sin ser un erudito: 

type = ALL → Full Table Scan ❌

key = NULL → no está usando ningún índice

Esto significa que MySQL recorre toda la tabla.

Veamos agregar un indice: 

CREATE INDEX idx_titulo ON libro(titulo);

Volvemos a ejecutar:

EXPLAIN 

SELECT * 

FROM libro 

WHERE titulo = 'El Quijote';

Nueva salida:

| type | key        | rows |

| ---- | ---------- | ---- |

| ref  | idx_titulo | 1    |

✅ Ahora sí:

• Usa índice
• Escanea pocas filas
• Mucho más eficiente

Veamos las columnas clave de EXPLAIN

type (MUY importante)

Indica cómo accede a la tabla:

| type   | Significado             |

| ------ | ----------------------- |

| ALL    | Full scan (malo) ❌      |

| index  | Scan de índice completo |

| ref    | Uso de índice 👍        |

| eq_ref | Uso óptimo 🚀           |

| const  | Mejor caso posible 💎   |

key

• Índice que se está utilizando
• Si es `NULL` → problema 😬

rows

• Cantidad estimada de filas a procesar
• Mientras menor, mejor

Extra

Algunos valores importantes:

| Extra           | Significado             |

| --------------- | ----------------------- |

| Using where     | Filtro aplicado         |

| Using index     | Index-only scan 🚀      |

| Using temporary | Tabla temporal ⚠️       |

| Using filesort  | Ordenamiento costoso ⚠️ |

Veamos un ejemplo con JOIN

EXPLAIN

SELECT l.titulo, a.nombre

FROM libro l

JOIN autor a ON l.autor_id = a.id

WHERE a.nombre = 'Cervantes';

👉 Cosas a observar:

• Orden de las tablas
• Índices en autor.nombre y libro.autor_id
• Tipo de join (`ref`, `eq_ref`, etc.)

Problema típico: filesort

EXPLAIN

SELECT * 

FROM libro

ORDER BY fecha_publicacion;

Si ves: Using filesort

MySQL está ordenando en memoria (o peor, en disco)

Solución:

CREATE INDEX idx_fecha ON libro(fecha_publicacion);

EXPLAIN ANALYZE (MySQL 8+)

Mysql agrega el analyze que es propio de mysql, por lo menos no conozco en otras bases. (si conocen me dicen en los comentarios) Analyze corre la query y nos tira data más precisa. Tema que hay que esperar a que ejecute la query. 

EXPLAIN ANALYZE

SELECT * 

FROM libro 

WHERE titulo = 'El Quijote';

Que diferencia tiene con explain clave:

| EXPLAIN             | EXPLAIN ANALYZE |

| Estimaciones         | Ejecución real  |

| No ejecuta query   | Ejecuta query   |

| Rápido                   | Más preciso     |

Ejemplo:

-> Index lookup on libro using idx_titulo

(cost=0.35 rows=1)

(actual time=0.01..0.02 rows=1 loops=1)

Como conclusión, EXPLAIN no es opcional: es una herramienta esencial.

Te permite:

• Entender cómo piensa MySQL
• Detectar problemas de performance
• Validar el uso de índices
• Optimizar queries complejas

Un buen flujo de trabajo sería:

1. Escribir la query

2. Ejecutar EXPLAIN

3. Detectar problemas

4. Agregar índices / refactorizar

5. Validar con EXPLAIN ANALYZE

Nunca andar tirando índices a lo loco o trabajar a tientas. 

Crear un mini lenguaje que compile a LLVM IR (paso a paso)

En el post anterior vimos qué es LLVM y por qué cambió la forma de construir compiladores.

Ahora vamos a lo interesante: crear un mini lenguaje propio y compilarlo a LLVM IR

Vamos a construir un lenguaje súper simple que permita esto:

sum(10, 20)

Y lo transforme en LLVM IR listo para compilar.

Nuestro “compilador” va a tener:

• Parser (muy básico)
• AST (árbol)
• Generador de LLVM IR

Paso 1: Definir el lenguaje

Nuestro lenguaje soporta:

Función: sum(a, b)

Números enteros

Ejemplo válido:

sum(4, 5)

Paso 2: Representar el AST

En pseudocódigo:

java id="y0yqg3"

interface Expr {}

class Number implements Expr {

    int value;

}

class Sum implements Expr {

    Expr left;

    Expr right;

}

Paso 3: Parser (ultra simple)

Para simplificar, parseamos a mano:

java id="x7p0a1"

Expr parse(String input) {

    // sum(10,20)

    String inside = input.substring(4, input.length() - 1);

    String[] parts = inside.split(",");

    return new Sum(

        new Number(Integer.parseInt(parts[0])),

        new Number(Integer.parseInt(parts[1]))

    );

}

Sí, es naive, pero suficiente para entender el flujo

Paso 4: Generar LLVM IR

Acá está la magia 💣

java id="l6c0qw"

String generate(Expr expr) {

    if (expr instanceof Sum s) {

        return """

        define i32 @main() {

            %a = add i32 %d, %d

            ret i32 %a

        }

        """.formatted(

            ((Number)s.left).value,

            ((Number)s.right).value

        );

    }

    throw new RuntimeException("Unsupported");

}

Resultado

Entrada:

sum(10, 20)

Salida:

llvm id="0a8v8l"

define i32 @main() {

  %a = add i32 10, 20

  ret i32 %a

}

Ya es LLVM IR válido

Paso 5: Ejecutarlo

Guardás el archivo como main.ll y usás:

bash id="3e7twz"

lli main.ll

o lo compilás con:

bash id="z4c9yb"

llc main.ll

Aunque el ejemplo es simple, reproduce el flujo real:

1. Texto → AST

2. AST → IR

3. IR → código ejecutable

Exactamente lo que hacen lenguajes como Rust o compiladores como Clang

Lo difícil NO es generar código máquina.

Lo difícil es definir bien el lenguaje y su semántica.

LLVM te resuelve:

• optimización
• portabilidad
• generación de código

SELECT FOR UPDATE en MySQL

Cuando trabajamos con sistemas concurrentes (varios usuarios o procesos accediendo a los mismos datos), uno de los problemas más comunes es la inconsistencia de datos.

Ahí es donde entra en juego una herramienta clave de MySQL:

SELECT ... FOR UPDATE

Esta sentencia que:

1. Lee filas de una tabla

2. Las bloquea para escritura

3. Hasta que la transacción finalice (COMMIT o ROLLBACK)

Esto garantiza que nadie más pueda modificar esas filas mientras vos trabajás con ellas.

Veamos un ejemplo: 

START TRANSACTION;

SELECT * 

FROM cuentas 

WHERE id = 1

FOR UPDATE;

UPDATE cuentas 

SET saldo = saldo - 100 

WHERE id = 1;

COMMIT;

En este caso:

Se bloquea la fila con id = 1

Nadie más puede modificarla hasta el COMMIT

¿Por qué es importante? Imaginá este escenario sin bloqueo:

1. Proceso A lee saldo = 100

2. Proceso B lee saldo = 100

3. Ambos descuentan 50

4. Resultado final: ❌ saldo = 50 (incorrecto)

Con FOR UPDATE:

1. Proceso A bloquea la fila

2. Proceso B espera

3. Se ejecuta A completamente

4. Luego B trabaja con datos actualizados

✔️ Resultado correcto

¿Cómo funciona internamente?

Ojo, Solo funciona con motores como InnoDB

Usa bloqueo a nivel de fila (row-level locking)

Otros SELECT FOR UPDATE:

• Quedan esperando
• Otros SELECT normales, pueden leer (dependiendo del isolation level)

Para no cagarla podemos usar SKIP LOCKED

SELECT * FROM tareas

WHERE estado = 'pendiente'

FOR UPDATE SKIP LOCKED;

✔️ Ignora filas bloqueadas

✔️ Ideal para workers concurrentes

Ojo, no sé si es tan aplicable, si queremos modificar todas las filas queremos modificar todas, no solo las no loqueadas.  

NOWAIT

SELECT * FROM cuentas

WHERE id = 1

FOR UPDATE NOWAIT;

❌ Falla inmediatamente si la fila está bloqueada

✔️ Útil cuando no querés esperar

Cosas a tener en cuenta:

• Siempre usar dentro de una transacción
• Puede generar deadlocks
• Usar índices para evitar locks innecesarios
• No funciona bien con tablas sin InnoDB

VisualVM vs .NET Tooling

¿Por qué en Java hay “una herramienta” y en .NET hay muchas?

Cuando venís del mundo Java, es muy común preguntarte: ¿Dónde está el VisualVM de .NET?

La respuesta corta es: no existe uno solo.

La respuesta interesante es: no existe por diseño.

En el ecosistema Java, herramientas como VisualVM se volvieron estándar porque la JVM expone un modelo bastante unificado:

• JMX (Java Management Extensions)
• Heap dumps
• Thread dumps
• GC metrics

Todo eso se puede consumir desde una sola herramienta.

¿Qué ofrece VisualVM?

• Profiling de CPU
• Análisis de memoria (heap)
• Monitoreo de threads
• Plugins

Resultado: una experiencia “tipo panel de control” donde ves todo.

En .NET moderno, el enfoque es distinto. En lugar de una herramienta central, tenés un ecosistema de herramientas especializadas.

Visual Studio (Profiler integrado)

Es lo más parecido a VisualVM:

• CPU profiling
• Memory profiling
• Timeline
• UI completa

Es la opción más “todo en uno”, pero:

❌ Es pesada

❌ No siempre usable en producción

CLI tools (el corazón real de .NET)

.NET adopta un enfoque más tipo Unix:

• dotnet-counters → métricas en vivo
• dotnet-trace → trazas de ejecución
• dotnet-dump → dumps
• dotnet-gcdump → GC
• dotnet-stack → threads

Cada herramienta hace una cosa… pero la hace muy bien.

Esto permite:

• Usarlas en producción
• Automatizarlas
• Integrarlas con pipelines

PerfView

• Muy potente
• Usado internamente por Microsoft
• Basado en ETW (Event Tracing for Windows)

❌ Curva de aprendizaje alta

❌ UX poco amigable

Herramientas comerciales

• dotTrace
• ANTS Profiler
• .NET Memory Profiler

Estas sí se sienten más como VisualVM:

✔️ UI amigable

✔️ Experiencia integrada

❌ Son pagas

Records vs Project Valhalla en Java

Java viene evolucionando fuerte en dos direcciones:

• Java Records → escribir menos código
• Project Valhalla → ejecutar más rápido

A primera vista parecen competir… pero en realidad se complementan.

• Usá Records → claridad, simplicidad, APIs
• Usá Valhalla (Value Types) → rendimiento, memoria
• Usá ambos → lo ideal en sistemas complejos

Records: el rey de la simplicidad

record User(String name, int age) {}

✔ Inmutables

✔ Menos boilerplate

✔ equals, hashCode, toString automáticos

¿Cuándo usar Records?

DTOs / APIs

record ProductDTO(String name, double price) {}

Perfecto para:

• REST APIs
• serialización JSON
• comunicación entre capas

Modelos simples

record Money(double amount, String currency) {}

Cuando te importa más la legibilidad que el rendimiento

Lógica de negocio

• servicios
• respuestas intermedias

El overhead de objetos no suele ser un problema

Limitación clave, un record:

• vive en el heap
• tiene identidad
• usa referencias

Valhalla: el rey del rendimiento

Ejemplo conceptual:

value class Point {

    int x, y;

}

✔ Sin identidad

✔ Sin overhead de objeto

✔ Datos contiguos en memoria

¿Cuándo usar Value Types?

Grandes volúmenes de datos

value class Point {

    int x, y;

}

List<Point>

Mucho más eficiente que objetos tradicionales

Simulaciones

• físicas
• partículas
• coordenadas

Miles o millones de instancias

Alto rendimiento

• trading
• analytics
• cálculos intensivos

Menos GC = mejor performance

¿Qué cambia realmente?

Sin Valhalla:

List<Point> // lista de referencias

Con Valhalla:

[x1, y1, x2, y2, x3, y3]

Datos planos → mejor cache → más velocidad

Cuándo NO usar Valhalla

• Entidades (`User`, `Order`)
• Objetos con identidad
• Integración con frameworks clásicos

Si necesitás identidad → no es value type

Lo mejor: combinarlos

Acá está la clave real 👇

Caso 1: Record + Value Type

value class Point {

    int x, y;

}

record Circle(Point center, double radius) {}

Tenés:

API clara (record)

datos eficientes (value)

Caso 2: separación por capas

// API

record PointDTO(int x, int y) {}

// Core

value class Point {

    int x, y;

}

Separás:

• interfaz → legible
• core → performante

Caso 3: colecciones grandes

value class Price {

    double amount;

}

List<Price>

Sin boxing → sin referencias → 🔥

Futuro: value records

Se viene algo así:

value record Point(int x, int y) {}

Combina:

• simplicidad (record)
• eficiencia (value type)

Conclusión, no es una pelea, es una estrategia:

• Records → hacen feliz al desarrollador
• Valhalla → hace feliz a la JVM

Java vs C#: Records y Value Types vs Records y Structs

Durante años, C# llevó ventaja en expresividad y control de memoria.

Pero con Java Records y Project Valhalla, Java está alcanzando… y en algunos aspectos, intentando superarlo.

👉 La pregunta es:

 ¿Java está copiando a C#… o lo está mejorando?

Empecemos por records: empate técnico

En C#

record Person(string Name);

En Java

record Person(String name) {}

✔ Inmutables

✔ Comparación por valor

✔ Menos boilerplate

Conclusión: Empate total — ambos lenguajes convergieron al mismo concepto

Value Types vs Structs

En C#: struct

struct Point {

    public int X;

    public int Y;

}

✔ Tipo por valor

✔ Generalmente en stack

✔ Muy eficiente

Problemas:

Boxing (se convierte en objeto)

Copias implícitas

Comportamiento a veces confuso

 En Java: Value Types (Valhalla)

value class Point {

    int x, y;

}

✔ Sin identidad

✔ Sin overhead de objeto

✔ Puede ser “flattened”

Y lo más importante: No cambia su naturaleza según el contexto

Diferencia clave

C# → tipo híbrido (a veces valor, a veces objeto)

Java → tipo consistente (siempre value type)

Punto para Java (a nivel diseño)

Memoria y layout

• Stack vs Heap
• Depende del contexto
• Puede generar copias innecesarias

 Java (Valhalla)

• Flattening automático
• Mejor locality
• Optimización por la JVM

Ejemplo mental:

En java esto: 

List<Point>

Podría ser:

[x1, y1, x2, y2, x3, y3]

Mucho más eficiente que referencias

Generics (el golpe fuerte de Java)

C#

List<int> 

Soportado desde hace años

Java (hoy)

List<Integer>  (boxing)

Java (con Valhalla)

List<int> ✔

List<Point> ✔

Sin boxing y sin referencias

Este es uno de los mayores avances de Java

Complejidad del modelo mental

En C#

• class vs struct
• boxing/unboxing
• copias implícitas
• Puede ser confuso

En Java

• class vs value class
• sin identidad vs con identidad
• Más simple conceptualmente

Ecosistema y madurez

C#

✔ Ya está en producción

✔ Frameworks adaptados

✔ Casos reales

 Java (Valhalla)

⚠️ En desarrollo

⚠️ APIs en evolución

⚠️ Falta adopción

Hoy no podés usarlo en producción estándar

¿Quién lo hizo mejor?

Hoy: C#

Porque:

• ya funciona
• es estable
• está probado

 A futuro: Java (posiblemente)

Porque:

• evita errores históricos (boxing, copias)
• diseño más consistente
• mejor integración con la JVM

HTTP 418: I'm a teapot

Si alguna vez viste el código HTTP 418, probablemente pensaste: “¿Esto es real o me están trolleando?”

Spoiler: ambas cosas.

¿Qué significa el error 418?

El código HTTP 418 – "I'm a teapot" es un código de error del cliente (4xx) que, literalmente, significa:

 “Soy una tetera y no puedo hacer café” 

La idea es simple:

El cliente hace una request (ej: “haceme café” ☕)

El servidor responde:

  “No puedo, soy una tetera”

Este código nace en 1998 en el RFC 2324, llamado:

Hyper Text Coffee Pot Control Protocol (HTCPCP)

Sí, un protocolo para controlar cafeteras por internet… y sí, fue publicado el 1 de abril (April Fools). 

La especificación decía cosas como:

• Método HTTP: BREW
• Headers para azúcar o leche
• Y este glorioso error 418

 ¿Es un chiste o es real?

Las dos:

• Es parte “oficial” del ecosistema HTTP (aunque reservado/no usado formalmente) 
• No tiene uso serio en producción
• Pero muchos frameworks lo incluyen igual

Ejemplos reales:

• Java / Spring: podés devolver 418
• .NET: `StatusCodes.Status418ImATeapot`
• Node / Go / Python también lo soportan 

¿Se usa en la vida real?

No debería… pero igual aparece:

• Easter eggs en APIs
• Testing de errores
• Bloqueo de bots
• Mensajes humorísticos para developers

Incluso hay devs que lo usan para decir: “Tu request es absurda”

Dejo link: https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/418

Proyecto Valhalla en Java: Tipos de Valor y el Futuro del Rendimiento

Cuando hablamos de la evolución de Java, uno de los proyectos más interesantes (y menos comprendidos) es Project Valhalla.

Si alguna vez sentiste que Java es “pesado” por culpa de los objetos… este proyecto apunta directamente a eso.

Project Valhalla es una iniciativa dentro de OpenJDK cuyo objetivo principal es introducir:

Tipos de valor (Value Types / Inline Classes)

Esto permite representar datos sin el costo de los objetos tradicionales.

En Java, casi todo es un objeto… y eso tiene consecuencias:

Integer x = 10;

Esto implica:

• Heap allocation
• Indirección (punteros)
• Presión sobre el GC
• Mala localización en memoria (cache-unfriendly)

Incluso algo simple como una lista de enteros:

List<Integer>

Es en realidad:

List -> referencias -> objetos Integer

¿Qué propone Valhalla?

Valhalla introduce un nuevo tipo de clases: Clases inline (value classes)

Ejemplo conceptual:

value class Point {

    int x;

    int y;

}

Esto permite:

• Sin identidad (no == por referencia)
• Sin overhead de objeto
• Layout compacto en memoria

¿Por qué esto es importante?

Mejora de rendimiento

• Menos uso de heap
• Mejor uso de CPU cache
• Menos GC

Estructuras más eficientes

Ejemplo:

List<Point>

Con Valhalla podría ser:

[ x1, y1, x2, y2, x3, y3 ]

👉 En lugar de:

[ ref -> Point, ref -> Point, ref -> Point ]

Conceptos clave de Valhalla

Value Objects

• No tienen identidad, la identidad esta dada por su propio valor
• Son inmutables (conceptualmente)
• Se comparan por contenido

Flattening

El JVM puede “aplanar” estructuras:

class Line {

    Point p1;

    Point p2;

}

En memoria:

[x1, y1, x2, y2]

Specialized Generics (futuro)

Uno de los grandes problemas actuales:

List<int> ❌

List<Integer> ✅ (pero lento)

Valhalla busca permitir:

List<int> ✅

Sin boxing

Cambios importantes a tener en cuenta

• No todo será automáticamente value type
• Cambia el modelo mental (menos identidad, más datos)
• Impacta librerías y frameworks

Project Valhalla aún está en desarrollo activo.

No es parte estable de Java todavía, pero ya hay:

• Prototipos en OpenJDK
• Features en incubación

Veamos un ejemplo: 

 Antes (Java actual)

class Complex {

    double re;

    double im;

}

• Objeto en heap
• Referencias

Con Valhalla (ideal)

value class Complex {

    double re;

    double im;

}

• Datos contiguos
• Sin overhead

Project Valhalla busca algo muy ambicioso:

Combinar lo mejor de OOP con la eficiencia de lenguajes de bajo nivel

En otras palabras:

• Mantener la simplicidad de Java
• Reducir el costo de abstracción

En C# tenemos el struct que es muy similar a lo que busca Valhalla.

Dejo link: https://openjdk.org/projects/valhalla/

C++26: El salto más grande desde C++11

La nueva versión del estándar, C++26, ya está prácticamente cerrada… y no es una actualización menor.

Estamos hablando de una versión que introduce:

• Reflection (reflexión)
• Mejoras reales en seguridad de memoria
• Contracts (programación por contratos)
• Un nuevo modelo async/concurrencia

En conjunto, esto posiciona a C++ como un lenguaje que quiere competir con Rust en seguridad y con lenguajes modernos en expresividad… sin perder su filosofía de zero-overhead. 

Reflection: C++ ahora puede “mirarse a sí mismo”

La reflection en tiempo de compilación es probablemente el cambio más disruptivo.

¿Qué significa?

Que el código puede inspeccionar tipos, atributos y estructuras en compile-time.

Antes:

• Macros
• Templates imposibles de leer
• Mucho boilerplate

Ahora:

• Metaprogramación más directa
• Generación automática de código
• Mejor tooling

Ejemplo conceptual:

enum Color { red, green, blue };

static_assert(enum_to_string(Color::red) == "red");

Esto antes era doloroso; ahora es natural.

Es compile-time es decir, no tiene costo en runtime

Impacto real:

• Serialización automática
• ORMs más simples
• Validaciones generadas
• DSLs internas más potentes

Seguridad de memoria (sin romper C++)

C++26 no intenta ser “safe by default” como Rust.

En cambio, introduce mejoras pragmáticas:

• Librerías con chequeo de bounds
• Mejor manejo de variables no inicializadas
• Eliminación de ciertos comportamientos indefinidos
• Opciones “hardened” del estándar

No requiere reescribir tu código existente

Esto es muy C++:

• No rompe compatibilidad
• Permite adopción gradual

Contracts: diseño por contrato (por fin)

Después de años de idas y vueltas, llegan los contracts:

[[pre: x > 0]]

[[post: result >= 0]]

int sqrt(int x);

También aparece:

contract_assert(...)

¿Qué aportan?

• Validación de precondiciones
• Validación de postcondiciones
• Documentación ejecutable
• Mejor debugging

Es básicamente traer ideas de:

• Eiffel
• Ada
• .NET Code Contracts

Pero ahora en C++ estándar.

Nuevo modelo async: sender/receiver

C++ llevaba años con:

• std::thread
• std::future
• async

Pero nada realmente composable.

Ahora aparece un modelo basado en sender / receiver

Características:

• Composición funcional de tareas
• Concurrencia estructurada
• Mejor integración con coroutines
• Pipeline de operaciones async

Esto unifica:

• paralelismo
• asincronía
• ejecución

Similar conceptualmente a:

• Reactive Streams
• Rx
• pipelines funcionales

C++26 no es una evolución incremental.

Es un intento claro de:

• Modernizar el lenguaje
• Mantener compatibilidad
• Competir con Rust y lenguajes modernos

Dejo link: https://www.infoq.com/news/2026/04/cpp-26-reflection-safety-async/

Records vs Clases vs Lombok vs Kotlin vs Scala

¿Cuál es la mejor forma de modelar datos? Desde los Struct de c++ nos venimos preguntando esto. Vamos a ver algunas opciones modernas que nos provee la plataforma java. 

Cuando trabajamos con objetos que representan datos (DTOs, Value Objects, etc.), distintos lenguajes ofrecen soluciones para evitar el boilerplate.

En este post comparamos:

• Records en Java
• Clases tradicionales
• Lombok
• Data classes en Kotlin
• Case classes en Scala

1. Clase tradicional (Java)

public class Persona {

    private final String nombre;

    private final int edad;

    public Persona(String nombre, int edad) {

        this.nombre = nombre;

        this.edad = edad;

    }

    public String getNombre() { return nombre; }

    public int getEdad() { return edad; }

    @Override public boolean equals(Object o) { ... }

    @Override public int hashCode() { ... }

    @Override public String toString() { ... }

}

Ventajas

• Total control
• Compatible con todo (JPA, frameworks)

Desventajas

• Mucho boilerplate
• Propenso a errores

2. Records (Java)

public record Persona(String nombre, int edad) {}

Ventajas

• Ultra conciso
• Inmutabilidad garantizada
• Sin dependencias

Desventajas

• Menos flexible
• No sirve bien con JPA
• No herencia

3. Lombok (@Data)

import lombok.Data;

@Data

public class Persona {

    private String nombre;

    private int edad;

}

Ventajas

• Reduce mucho código
• Mutable o inmutable (configurable)

Desventajas

• Dependencia externa
• "Magia" en compilación (puede confundir)
•  Problemas en tooling/debug

4. Data Classes (Kotlin)

data class Persona(val nombre: String, val edad: Int)

Ventajas

• Muy conciso
• Inmutable por defecto
• copy() incluido
• Destructuring

val (nombre, edad) = persona

Desventajas

• Requiere usar Kotlin
• Interoperabilidad Java no siempre perfecta

5. Case Classes (Scala)

case class Persona(nombre: String, edad: Int)

Ventajas

• Inmutables
• Pattern matching nativo
• copy() automático
• Muy expresivas

persona match {

  case Persona(nombre, edad) => println(nombre)

}

Desventajas

• Curva de aprendizaje
• Ecosistema más complejo

Y entonces? Y ninguno es super mejor, pero podemos tener estas reglas: 

Java Records

Ideal para:

• DTOs simples
• APIs REST
• Código moderno sin dependencias

Son el "mínimo viable elegante" en Java.

Lombok

Ideal para:

• Proyectos legacy
• Equipos que ya lo usan

 Soluciona el problema… pero no es parte del lenguaje.

Kotlin

La mejor experiencia general para modelado de datos.

• copy()
• destructuring
• null-safety

Es claramente superior en ergonomía.

Scala

El más poderoso conceptualmente.

• Pattern matching real
• Inmutabilidad fuerte
• Integración con FP

Pero más complejo.

 Clases Java

 Siguen siendo necesarias cuando:

• Usás JPA
• Necesitás mutabilidad
• Requerís control total

Si estás en Java moderno → Records

Si querés máxima productividad → Kotlin

Si buscás poder expresivo → Scala

Si estás en legacy → Lombok o clases