<p>Antes de arrancar, una confesión: a mí no me gustan las bases de datos. Me aburren. Prefiero escribir código de negocio, diseñar arquitecturas, resolver problemas de integración. Pero justamente por eso aprendí a respetarlas. Porque cada vez que las ignoré, me mordieron. Fuerte.</p> <p>Hoy toca hablar de índices. Un tema que muchos consideran aburrido y que termina siendo un infierno en producción.</p> <p>La historia típica es esta: alguien en el equipo corre un <code>EXPLAIN</code>, ve un full table scan, y la solución parece obvia: <em>"ponle un índice"</em>. Funciona. La query pasa de 3 segundos a 40 milisegundos. Eureka.</p> <p>Entonces le ponen índice a la siguiente columna. Y a la siguiente. Y a la siguiente. Seis meses después, los INSERT tardan 800ms y nadie entiende por qué.</p> <p>Bienvenido al anti-pattern más común en bases de datos: <strong>indexar todo por si acaso</strong>.</p> <h2> Qué es un índice (y por qué cuesta) </h2> <p>Antes de hablar de código, el concepto. Porque esto no es exclusivo de MySQL ni de PostgreSQL — es de <strong>cualquier base de datos que hayas usado o vayas a usar</strong>.</p> <p>Un índice es una <strong>estructura de datos adicional</strong> que la base mantiene en paralelo a tu tabla. Generalmente es un B-tree (o un B+tree) que ordena los valores de una columna para que buscar uno específico sea logarítmico en vez de lineal.</p> <p>Acelera las lecturas. Eso está claro.</p> <p>Lo que nadie te cuenta es el otro lado: <strong>cada índice hay que mantenerlo actualizado en cada escritura</strong>. Cuando haces un <code>INSERT</code>, la base no solo escribe la fila — actualiza <strong>todos</strong> los índices de esa tabla. Cada uno. Uno por uno.</p> <p>Si tienes 12 índices, cada <code>INSERT</code> tiene que actualizar 12 estructuras de datos. Cada <code>UPDATE</code> que toque una columna indexada recalcula ese índice. Cada <code>DELETE</code> limpia la fila y limpia los índices asociados.</p> <p>No es gratis. Nunca fue gratis.</p> <p>Y esto aplica en:</p> <ul> <li> <strong>PostgreSQL</strong> (B-tree, GIN, GiST, BRIN)</li> <li> <strong>MySQL / MariaDB</strong> (B-tree, Hash, Full-text)</li> <li> <strong>Oracle</strong> (B-tree, Bitmap)</li> <li> <strong>SQL Server</strong> (Clustered, Non-clustered)</li> <li> <strong>MongoDB</strong> (B-tree, compound, text, geospatial)</li> <li> <strong>DynamoDB</strong> (local + global secondary indexes)</li> </ul> <p>Cambia la sintaxis. Cambia el engine. El tradeoff es idéntico: <strong>escrituras más caras a cambio de lecturas más baratas</strong>.</p> <h2> El ANTES: la tabla navideña </h2> <p>Mira esta entidad. Dime si no te suena de algún proyecto:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight java"><code><span class="nd">@Entity</span> <span class="nd">@Table</span><span class="o">(</span><span class="n">name</span> <span class="o">=</span> <span class="s">"pedidos"</span><span class="o">,</span> <span class="n">indexes</span> <span class="o">=</span> <span class="o">{</span> <span class="nd">@Index</span><span class="o">(</span><span class="n">name</span> <span class="o">=</span> <span class="s">"idx_cliente"</span><span class="o">,</span> <span class="n">columnList</span> <span class="o">=</span> <span class="s">"clienteId"</span><span class="o">),</span> <span class="nd">@Index</span><span class="o">(</span><span class="n">name</span> <span class="o">=</span> <span class="s">"idx_fecha"</span><span class="o">,</span> <span class="n">columnList</span> <span class="o">=</span> <span class="s">"fecha"</span><span class="o">),</span> <span class="nd">@Index</span><span class="o">(</span><span class="n">name</span> <span class="o">=</span> <span class="s">"idx_estado"</span><span class="o">,</span> <span class="n">columnList</span> <span class="o">=</span> <span class="s">"estado"</span><span class="o">),</span> <span class="nd">@Index</span><span class="o">(</span><span class="n">name</span> <span class="o">=</span> <span class="s">"idx_total"</span><span class="o">,</span> <span class="n">columnList</span> <span class="o">=</span> <span class="s">"total"</span><span class="o">),</span> <span class="nd">@Index</span><span class="o">(</span><span class="n">name</span> <span class="o">=</span> <span class="s">"idx_moneda"</span><span class="o">,</span> <span class="n">columnList</span> <span class="o">=</span> <span class="s">"moneda"</span><span class="o">),</span> <span class="nd">@Index</span><span class="o">(</span><span class="n">name</span> <span class="o">=</span> <span class="s">"idx_sucursal"</span><span class="o">,</span> <span class="n">columnList</span> <span class="o">=</span> <span class="s">"sucursal"</span><span class="o">),</span> <span class="nd">@Index</span><span class="o">(</span><span class="n">name</span> <span class="o">=</span> <span class="s">"idx_vendedor"</span><span class="o">,</span> <span class="n">columnList</span> <span class="o">=</span> <span class="s">"vendedorId"</span><span class="o">),</span> <span class="nd">@Index</span><span class="o">(</span><span class="n">name</span> <span class="o">=</span> <span class="s">"idx_canal"</span><span class="o">,</span> <span class="n">columnList</span> <span class="o">=</span> <span class="s">"canal"</span><span class="o">),</span> <span class="nd">@Index</span><span class="o">(</span><span class="n">name</span> <span class="o">=</span> <span class="s">"idx_prioridad"</span><span class="o">,</span> <span class="n">columnList</span> <span class="o">=</span> <span class="s">"prioridad"</span><span class="o">),</span> <span class="nd">@Index</span><span class="o">(</span><span class="n">name</span> <span class="o">=</span> <span class="s">"idx_tipo"</span><span class="o">,</span> <span class="n">columnList</span> <span class="o">=</span> <span class="s">"tipo"</span><span class="o">)</span> <span class="o">})</span> <span class="kd">public</span> <span class="kd">class</span> <span class="nc">Pedido</span> <span class="o">{</span> <span class="nd">@Id</span> <span class="nd">@GeneratedValue</span> <span class="kd">private</span> <span class="nc">Long</span> <span class="n">id</span><span class="o">;</span> <span class="kd">private</span> <span class="nc">Long</span> <span class="n">clienteId</span><span class="o">;</span> <span class="kd">private</span> <span class="nc">LocalDate</span> <span class="n">fecha</span><span class="o">;</span> <span class="kd">private</span> <span class="nc">String</span> <span class="n">estado</span><span class="o">;</span> <span class="kd">private</span> <span class="nc">BigDecimal</span> <span class="n">total</span><span class="o">;</span> <span class="kd">private</span> <span class="nc">String</span> <span class="n">moneda</span><span class="o">;</span> <span class="kd">private</span> <span class="nc">String</span> <span class="n">sucursal</span><span class="o">;</span> <span class="kd">private</span> <span class="nc">Long</span> <span class="n">vendedorId</span><span class="o">;</span> <span class="kd">private</span> <span class="nc">String</span> <span class="n">canal</span><span class="o">;</span> <span class="kd">private</span> <span class="nc">String</span> <span class="n">prioridad</span><span class="o">;</span> <span class="kd">private</span> <span class="nc">String</span> <span class="n">tipo</span><span class="o">;</span> <span class="o">}</span> </code></pre> </div> <p><strong>Diez índices.</strong> Para una tabla transaccional que recibe miles de INSERTs por hora. Cada escritura paga el costo de mantener diez B-trees actualizados. Todos. Para cada fila.</p> <p>Alguien los puso en algún momento pensando "por si acaso alguien quiere buscar por canal". Nadie nunca buscó por canal. Pero el índice sigue ahí, encareciendo cada escritura, consumiendo disco, ralentizando los backups.</p> <h2> El DESPUÉS: solo lo que importa </h2> <div class="highlight js-code-highlight"> <pre class="highlight java"><code><span class="nd">@Entity</span> <span class="nd">@Table</span><span class="o">(</span><span class="n">name</span> <span class="o">=</span> <span class="s">"pedidos"</span><span class="o">,</span> <span class="n">indexes</span> <span class="o">=</span> <span class="o">{</span> <span class="nd">@Index</span><span class="o">(</span><span class="n">name</span> <span class="o">=</span> <span class="s">"idx_cliente_fecha"</span><span class="o">,</span> <span class="n">columnList</span> <span class="o">=</span> <span class="s">"clienteId, fecha"</span><span class="o">),</span> <span class="nd">@Index</span><span class="o">(</span><span class="n">name</span> <span class="o">=</span> <span class="s">"idx_estado"</span><span class="o">,</span> <span class="n">columnList</span> <span class="o">=</span> <span class="s">"estado"</span><span class="o">)</span> <span class="o">})</span> <span class="kd">public</span> <span class="kd">class</span> <span class="nc">Pedido</span> <span class="o">{</span> <span class="c1">// mismos campos</span> <span class="o">}</span> </code></pre> </div> <p><strong>Dos índices.</strong> Uno compuesto que cubre el 80% de las queries reales (buscar pedidos de un cliente en un rango de fechas) y otro para el filtro por estado que el dashboard usa todo el tiempo.</p> <p>Nada más. El resto de las columnas no necesitan índice porque <strong>nadie las filtra en producción</strong>.</p> <h2> Los números del benchmark </h2> <div class="table-wrapper-paragraph"><table> <thead> <tr> <th></th> <th>ANTES (10 índices)</th> <th>DESPUÉS (2 índices)</th> <th>Mejora</th> </tr> </thead> <tbody> <tr> <td>INSERT 5K registros</td> <td>~1240ms</td> <td>~380ms</td> <td><strong>69%</strong></td> </tr> <tr> <td>SELECT por cliente</td> <td>~5ms</td> <td>~5ms</td> <td>Sin cambio</td> </tr> <tr> <td>Espacio en disco</td> <td>2.1 GB</td> <td>380 MB</td> <td><strong>82%</strong></td> </tr> </tbody> </table></div> <p>Los SELECTs <strong>apenas cambiaron</strong> porque los 8 índices que sacamos casi nunca se usaban. Estaban ahí consumiendo disco y frenando escrituras sin que nadie los necesitara.</p> <p>El código de este benchmark está en el repo — puedes correrlo y ver los números reales en tu máquina. Cambia la cantidad de registros para ver cómo escala la diferencia.</p> <h2> Las 4 reglas para decidir qué indexar </h2> <h3> Regla 1: Mira las queries reales, no las que imaginas </h3> <p>El error más común es indexar <em>en teoría</em>. "Por si acaso alguien consulta por sucursal". Nadie va a consultar por sucursal. Pero el índice está ahí, encareciendo cada escritura para una query que no existe.</p> <p>Mira lo que tu app hace <strong>de verdad</strong>:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight sql"><code><span class="c1">-- PostgreSQL: las queries más lentas</span> <span class="k">SELECT</span> <span class="n">query</span><span class="p">,</span> <span class="n">calls</span><span class="p">,</span> <span class="n">mean_exec_time</span> <span class="k">FROM</span> <span class="n">pg_stat_statements</span> <span class="k">ORDER</span> <span class="k">BY</span> <span class="n">mean_exec_time</span> <span class="k">DESC</span> <span class="k">LIMIT</span> <span class="mi">10</span><span class="p">;</span> <span class="c1">-- MySQL: queries que hacen full scan</span> <span class="k">SELECT</span> <span class="o">*</span> <span class="k">FROM</span> <span class="n">sys</span><span class="p">.</span><span class="n">statements_with_full_table_scans</span> <span class="k">ORDER</span> <span class="k">BY</span> <span class="n">no_index_used_count</span> <span class="k">DESC</span><span class="p">;</span> <span class="c1">-- MongoDB: queries lentas</span> <span class="n">db</span><span class="p">.</span><span class="k">system</span><span class="p">.</span><span class="n">profile</span><span class="p">.</span><span class="n">find</span><span class="p">({</span><span class="n">millis</span><span class="p">:</span> <span class="p">{</span><span class="err">$</span><span class="n">gt</span><span class="p">:</span> <span class="mi">100</span><span class="p">}}).</span><span class="n">sort</span><span class="p">({</span><span class="n">ts</span><span class="p">:</span> <span class="o">-</span><span class="mi">1</span><span class="p">});</span> </code></pre> </div> <p>Si no hay una query real que use esa columna en un <code>WHERE</code>, <code>JOIN</code> o <code>ORDER BY</code>, <strong>no necesitas el índice</strong>. Punto.</p> <h3> Regla 2: Los índices compuestos son tu mejor amigo </h3> <p>Un índice compuesto en <code>(clienteId, fecha)</code> cubre automáticamente:</p> <ul> <li> <code>WHERE clienteId = ?</code> → usa la primera columna</li> <li> <code>WHERE clienteId = ? AND fecha &gt; ?</code> → usa ambas</li> <li> <code>ORDER BY clienteId, fecha</code> → usa ambas</li> <li> <code>WHERE clienteId = ? ORDER BY fecha</code> → usa ambas</li> </ul> <p>Un índice por separado en <code>clienteId</code> y otro en <code>fecha</code> <strong>no</strong> dan el mismo resultado. El optimizador elige uno de los dos, no los combina mágicamente. Un índice compuesto bien pensado reemplaza 2 o 3 índices individuales.</p> <h3> Regla 3: Las columnas de baja cardinalidad casi nunca justifican un índice solo </h3> <p>Un campo <code>estado</code> con 4 valores posibles (<code>PENDIENTE</code>, <code>PROCESADO</code>, <code>ENVIADO</code>, <code>CANCELADO</code>) filtra el 25% de la tabla por valor. En tablas grandes, eso sigue siendo un montón de filas. El optimizador a veces decide ignorar el índice y hacer un full scan porque es más rápido.</p> <p>Lo mismo con booleanos. Un índice en una columna <code>activo</code> donde el 90% es <code>true</code> es inútil — la query va a tocar el 90% de las filas de todas formas.</p> <p>Si insistes en indexar una columna de baja cardinalidad, combínala con otra columna más selectiva en un índice compuesto.</p> <h3> Regla 4: La regla del 5% </h3> <p>Si una query devuelve más del <strong>5% de las filas</strong> de la tabla, el optimizador probablemente ignore el índice y haga un full scan. Porque leer un 5% de la tabla ordenada secuencialmente es más rápido que saltar de un lado a otro siguiendo un B-tree.</p> <p>Los índices son para queries <strong>selectivas</strong>. Si tu filtro es "tráeme el 80% de las filas", indexar no ayuda.</p> <h2> La pregunta clave antes de crear un índice </h2> <p>Antes de crear un índice, pregúntate: <strong>¿esta tabla recibe más lecturas o más escrituras?</strong></p> <ul> <li><p><strong>Tabla de productos / catálogo</strong>: miles de lecturas por segundo, pocas escrituras por día. Ponle los índices que quieras. Los reads valen mucho y los writes casi no duelen.</p></li> <li><p><strong>Tabla de eventos / logs / auditoría</strong>: miles de escrituras por segundo, lecturas ocasionales para reportes. Cada índice duele mucho. Indexa lo mínimo indispensable.</p></li> <li><p><strong>Tabla de pedidos / transacciones</strong>: escrituras Y lecturas frecuentes. Aquí es donde tienes que ser quirúrgico. Indexa lo que las queries reales necesitan, nada más.</p></li> </ul> <p>No hay una respuesta universal. Hay <strong>tradeoffs</strong>. Tu trabajo es entenderlos, no ignorarlos.</p> <h2> El error de fondo </h2> <p>El problema nunca fue "faltan índices". El problema fue no preguntarse <strong>cuáles</strong>.</p> <p>Poner un índice en cada columna es como poner un semáforo en cada esquina — en algún momento, el remedio es peor que la enfermedad.</p> <p>Un índice es un <strong>contrato</strong>: "acepto pagar más en cada escritura para ganar velocidad en esta lectura específica". Si no sabes cuál es la lectura que estás optimizando, no firmes el contrato.</p> <h2> Esto es el Día 10 </h2> <p>Este artículo es parte de <strong>#100ArchitectureDays</strong> — una serie de problemas reales de arquitectura con soluciones reales. La próxima vez que alguien diga "ponle un índice", pregúntale dos cosas: <strong>¿a cuál columna?</strong> y <strong>¿por qué?</strong>. Si no puede responder las dos, no hay que indexar nada todavía.</p> <p>Sigue la saga completa en <strong>#100ArchitectureDays</strong>.</p> <p>Todo el código está en <a href="https://github.com/alafourcadev/100-architecture-days" rel="noopener noreferrer">GitHub</a> — con un benchmark que puedes correr para ver en vivo cómo los índices de más frenan los INSERTs. Si te está sirviendo, déjame una estrella — es gratis y ayuda a que más gente lo encuentre.</p>