{"id":1065,"date":"2016-06-06T10:00:25","date_gmt":"2016-06-06T08:00:25","guid":{"rendered":"https:\/\/www.nicalia.com\/blog\/?p=1065"},"modified":"2026-05-25T16:00:05","modified_gmt":"2026-05-25T14:00:05","slug":"reducir-tamano-la-tabla-wp_options-wordpress","status":"publish","type":"post","link":"https:\/\/www.nicalia.com\/blog\/reducir-tamano-la-tabla-wp_options-wordpress\/","title":{"rendered":"Tutorial: Reducir de tama\u00f1o la tabla wp_options de WordPress de forma segura"},"content":{"rendered":"<p><strong>ACTUALIZADA:<\/strong> 25\/5\/226<\/p>\n<h1>C\u00f3mo reducir el tama\u00f1o de la tabla wp_options en WordPress sin romper nada<\/h1>\n<p>Un Tiempo al Primer Byte (TTFB) inusualmente alto o la aparici\u00f3n intermitente de errores 502 Bad Gateway no siempre apuntan a una falta de recursos de hardware en tu<a href=\"https:\/\/www.nicalia.com\/servidores\/vps-administrados\"> servidor VPS o dedicado<\/a>. Con frecuencia, el verdadero cuello de botella se oculta en el motor relacional de la base de datos, concretamente dentro de la tabla wp_options. Muchos <em><strong>tutoriales obsoletos se limitan a recomendar el borrado masivo de transients y una optimizaci\u00f3n superficial a trav\u00e9s de phpMyAdmin<\/strong><\/em>; sin embargo, WordPress exige un protocolo de diagn\u00f3stico estructurado y muy definido para solucionar la sobrecarga de consultas y memoria sin comprometer la estabilidad del entorno de producci\u00f3n. Si eres responsable de un e-commerce, dise\u00f1ador web o director de tecnolog\u00eda, sabes bien que el rendimiento no se soluciona con trucos de magia, sino con ingenier\u00eda.<\/p>\n<h2>Qu\u00e9 es la tabla wp_options y c\u00f3mo afecta al rendimiento<\/h2>\n<p>La tabla wp_options es el pilar central del almacenamiento de configuraciones globales, estados l\u00f3gicos y datos persistentes tanto del n\u00facleo de WordPress como de los temas y plugins instalados. A diferencia de otras tablas de la base de datos relacional que estructuran los metadatos de forma indexada o vertical, wp_options recurre a un dise\u00f1o plano de clave-valor.<\/p>\n<p>Esta tabla est\u00e1 constituida por cuatro columnas fundamentales: option_id (la clave primaria auto-incremental), option_name (el identificador \u00fanico de la configuraci\u00f3n), option_value (el payload o contenido del ajuste) y autoload (el flag de control de carga din\u00e1mica). El descontrol en el volumen f\u00edsico de esta estructura suele ser el primer causante del aumento sistem\u00e1tico de la velocidad de la web.<\/p>\n<blockquote><p><em>La tabla wp_options es el pilar central del almacenamiento de configuraciones globales, estados l\u00f3gicos y datos persistentes tanto del n\u00facleo de WordPress como de los temas y plugins instalados.<\/em><\/p><\/blockquote>\n<h2>Por qu\u00e9 el autoload puede ralentizar tu web<\/h2>\n<p>El campo autoload ejerce un control directo sobre la asignaci\u00f3n de memoria RAM del servidor web durante la inicializaci\u00f3n de absolutamente cada petici\u00f3n HTTP. Cuando WordPress procesa el ciclo de vida de una solicitud, invoca de manera interna la funci\u00f3n wp_load_alloptions(), la cual ejecuta una \u00fanica consulta consolidada a la base de datos para recuperar todas las filas cuyo estado de carga autom\u00e1tica est\u00e9 activo. El prop\u00f3sito original de esta estrategia de dise\u00f1o es poblar de inmediato el cach\u00e9 en memoria de la aplicaci\u00f3n, evitando llamadas individuales de tipo SELECT a lo largo de la ejecuci\u00f3n del c\u00f3digo.<\/p>\n<p>El problema real no est\u00e1 \u00fanicamente en el tama\u00f1o f\u00edsico global de la tabla wp_options, sino en la acumulaci\u00f3n desmedida de datos marcados para cargarse autom\u00e1ticamente en cada petici\u00f3n. <em><strong>Es muy com\u00fan que desarrolladores de plugins y temas utilicen wp_options de forma inapropiada<\/strong><\/em> para guardar grandes payloads, como respuestas JSON extensas provenientes de APIs externas, hojas de estilo CSS compiladas, logs de depuraci\u00f3n o estructuras transitorias sin expiraci\u00f3n expl\u00edcita. Al mantener el flag de autoload activo, se obliga al motor de base de datos a transmitir y a la memoria de PHP-FPM a deserializar y retener informaci\u00f3n masiva que no se requiere para renderizar la p\u00e1gina web solicitada, aumentando dr\u00e1sticamente los tiempos de carga.<\/p>\n<p>El exceso de datos autoloaded satura los hilos de ejecuci\u00f3n de MySQL y desborda los l\u00edmites f\u00edsicos de las herramientas de Object Cache, lo que puede provocar bloqueos completos del servicio bajo entornos de alto tr\u00e1fico concurrente.<\/p>\n<h3>Evoluci\u00f3n y el nuevo estandard de autoloading (WordPress 6.4 a 6.7)<\/h3>\n<p>Para atajar esta ineficiencia hist\u00f3rica, las versiones recientes de WordPress han transformado por completo el Options API. WordPress 6.4 introdujo la funci\u00f3n de recuperaci\u00f3n agrupada wp_prime_option_caches() junto con sus funciones envoltura get_options() y wp_prime_option_caches_by_group(). Este cambio de dise\u00f1o permite a los desarrolladores desactivar de forma segura la carga autom\u00e1tica de las opciones de configuraci\u00f3n de un plugin, recuper\u00e1ndolas de forma masiva en la base de datos \u00fanicamente en las p\u00e1ginas administrativas correspondientes a dicho componente, evitando ralentizar el front-end del sitio web.<\/p>\n<p>Posteriormente, a partir de WordPress 6.6 y 6.7, los antiguos valores binarios en la base de datos (yes y no) fueron declarados obsoletos en favor de un modelo sem\u00e1ntico y din\u00e1mico mucho m\u00e1s avanzado. La jerarqu\u00eda l\u00f3gica actual opera bajo los siguientes estados:<\/p>\n<ul>\n<li><strong>on:<\/strong> Fuerza la carga autom\u00e1tica obligatoria de la fila en cada solicitud de la plataforma.<\/li>\n<li><strong>off:<\/strong> Desactiva la precarga global; el registro solo se recuperar\u00e1 al invocar expl\u00edcitamente la funci\u00f3n get_option().<\/li>\n<li><strong>auto o null:<\/strong> Delega en el n\u00facleo de WordPress la decisi\u00f3n de aplicar o no el autoload bas\u00e1ndose en el peso f\u00edsico de la fila.<\/li>\n<li><strong>auto-on:<\/strong> Estado din\u00e1mico asignado a registros peque\u00f1os creados sin un flag expl\u00edcito, indicando que el sistema ha decidido cargarlos de forma autom\u00e1tica.<\/li>\n<li><strong>auto-off:<\/strong> Estado din\u00e1mico para opciones creadas sin flag expl\u00edcito pero cuyo volumen f\u00edsico supera los l\u00edmites de seguridad (exactamente cuando excede los 150 KB), lo que obliga a WordPress a desactivar autom\u00e1ticamente su precarga para proteger la memoria del servidor.<\/li>\n<\/ul>\n<h2><a href=\"https:\/\/www.nicalia.com\/blog\/wp-content\/uploads\/2016\/06\/wp-options-01.jpg\"><img decoding=\"async\" loading=\"lazy\" class=\"aligncenter size-large wp-image-3559\" src=\"https:\/\/www.nicalia.com\/blog\/wp-content\/uploads\/2016\/06\/wp-options-01-1024x572.jpg\" alt=\"Mejora el wp_options sin romper nada, optimiza la velocidad de tu web correctamente\" width=\"1024\" height=\"572\" srcset=\"https:\/\/www.nicalia.com\/blog\/wp-content\/uploads\/2016\/06\/wp-options-01-1024x572.jpg 1024w, https:\/\/www.nicalia.com\/blog\/wp-content\/uploads\/2016\/06\/wp-options-01-300x168.jpg 300w, https:\/\/www.nicalia.com\/blog\/wp-content\/uploads\/2016\/06\/wp-options-01-768x429.jpg 768w, https:\/\/www.nicalia.com\/blog\/wp-content\/uploads\/2016\/06\/wp-options-01.jpg 1200w\" sizes=\"(max-width: 1024px) 100vw, 1024px\" title=\"\"><\/a><\/h2>\n<h2>C\u00f3mo medir el tama\u00f1o real del problema<\/h2>\n<p>Antes de realizar cualquier modificaci\u00f3n o purga destructiva en el motor de almacenamiento relacional de la base de datos, es obligatorio realizar una auditor\u00eda t\u00e9cnica completa utilizando herramientas de monitoreo e interfaces de l\u00ednea de comandos.<\/p>\n<h3>Fase 1: Diagn\u00f3stico general del tama\u00f1o de la base de datos<\/h3>\n<p>Es indispensable contrastar el peso de las tablas principales para detectar desviaciones severas. En sitios con un historial largo o plataformas de comercio electr\u00f3nico, es frecuente que wp_options o wp_postmeta superen con creces el volumen f\u00edsico de los contenidos reales de la tabla wp_posts.<\/p>\n<h3>Fase 2: Cuantificaci\u00f3n del volumen acumulado en el autoload<\/h3>\n<p>Para determinar el peso exacto que asume PHP-FPM al procesar cada solicitud del sitio web, se debe calcular la suma total del tama\u00f1o de los datos autocargados. La siguiente consulta SQL integra todos los flags l\u00f3gicos tradicionales y modernos para cuantificar la carga real:<\/p>\n<pre><code>SELECT SUM(LENGTH(option_value)) AS autoload_size \r\nFROM wp_options \r\nWHERE autoload IN ('yes', 'on', 'auto-on');<\/code><\/pre>\n<p>Si el resultado de esta consulta supera el umbral cr\u00edtico de 1 MB, <em><strong>se activar\u00e1 de forma inmediata la advertencia de rendimiento<\/strong><\/em> dentro de la herramienta de Salud del Sitio de WordPress. En entornos optimizados de alto rendimiento, conviene vigilar la base de datos especialmente cuando los datos autoloaded superan los 800 KB para actuar preventivamente.<\/p>\n<h3>Fase 3: Identificaci\u00f3n de los registros ofensores<\/h3>\n<p>Para aislar con exactitud cu\u00e1les son las opciones espec\u00edficas que est\u00e1n consumiendo la memoria del servidor, ejecutamos una consulta orientada a listar de forma descendente los registros de mayor peso f\u00edsico configurados con carga autom\u00e1tica:<\/p>\n<pre><code>SELECT option_name, LENGTH(option_value) AS option_size \r\nFROM wp_options \r\nWHERE autoload IN ('yes', 'on', 'auto-on') \r\nORDER BY option_size DESC \r\nLIMIT 20;<\/code><\/pre>\n<h3>Fase 4: Auditor\u00eda avanzada mediante WP-CLI<\/h3>\n<p>Para ingenieros de sistemas y t\u00e9cnicos que operan directamente desde la terminal, la interfaz de l\u00ednea de comandos WP-CLI permite evaluar los l\u00edmites de seguridad de la tabla de forma \u00e1gil desde el directorio ra\u00edz de la instalaci\u00f3n:<\/p>\n<pre><code>wp option list --autoload=on --format=total_bytes<\/code><\/pre>\n<p>Este comando emite un diagn\u00f3stico preciso, notificando si el peso total supera los est\u00e1ndares del servidor. Complementariamente, es viable monitorizar el impacto de consultas lentas superiores a 0.1 segundos utilizando herramientas en tiempo de ejecuci\u00f3n como la extensi\u00f3n Query Monitor o sistemas de monitoreo APM empresariales como New Relic.<\/p>\n<h2>Qu\u00e9 opciones puedes limpiar con seguridad en tu base de datos<\/h2>\n<p>La depuraci\u00f3n f\u00edsica de la tabla wp_options requiere de precisi\u00f3n quir\u00fargica para liberar espacio de almacenamiento sin alterar las configuraciones activas del sitio web. El foco debe ponerse en la eliminaci\u00f3n controlada de residuos y transitorios obsoletos.<\/p>\n<h3>1. Limpieza quir\u00fargica de transitorios (transients) expirados<\/h3>\n<p>Los transients funcionan como registros temporales de cach\u00e9 interna en la base de datos. Debido a limitaciones en el dise\u00f1o nativo del n\u00facleo de WordPress, la expiraci\u00f3n del transitorio no ejecuta de forma autom\u00e1tica una llamada para su eliminaci\u00f3n f\u00edsica; las filas obsoletas solo se limpian si la aplicaci\u00f3n intenta consultarlas nuevamente de forma expl\u00edcita mediante la funci\u00f3n get_transient(). Si un plugin es desactivado, sus transitorios asociados permanecer\u00e1n indefinidamente en la base de datos.<\/p>\n<p>Muchos administradores cometen el grave error de ejecutar un borrado masivo a ciegas de todas las filas transitorias. <em><strong>Borrar transients activos provoca un pico severo de consumo de CPU<\/strong><\/em>, ya que la web se ve forzada a regenerar todos esos datos de forma simult\u00e1nea, llamando a APIs externas o ejecutando consultas pesadas. Para purgar de forma selectiva \u00fanicamente los transitorios que ya han expirado de acuerdo con su marca de tiempo Unix, garantizando una depuraci\u00f3n segura y sin riesgos de rendimiento, debes utilizar la siguiente consulta avanzada basada en una uni\u00f3n l\u00f3gica de coincidencia de claves:<\/p>\n<pre><code>DELETE a, b FROM wp_options a, wp_options b \r\nWHERE a.option_name LIKE '_transient_%' \r\nAND a.option_name NOT LIKE '_transient_timeout_%' \r\nAND b.option_name = CONCAT('_transient_timeout_', SUBSTRING(a.option_name, 12)) \r\nAND b.option_value &lt; UNIX_TIMESTAMP();<\/code><\/pre>\n<p>Si prefieres automatizar esta tarea desde la l\u00ednea de comandos<em><strong> sin interactuar con la consola de MySQL<\/strong><\/em>, WP-CLI ofrece un atajo de inmenso valor para perfiles t\u00e9cnicos y administradores de sistemas que deseen limpiar la base de datos en un segundo:<\/p>\n<pre><code>wp transient delete --expired<\/code><\/pre>\n<p>En escenarios de depuraci\u00f3n extrema o tras migraciones estructurales complejas donde requieras limpiar por completo la cach\u00e9 temporal para mitigar conflictos de c\u00f3digo, puedes forzar la purga absoluta ejecutando:<\/p>\n<pre><code>wp transient delete --all<\/code><\/pre>\n<p><strong>El superpoder de Redis sobre los transients:<\/strong> Un factor crucial a tener en cuenta al implementar cach\u00e9 de objetos persistente (como <a href=\"https:\/\/redis.io\/\" target=\"_blank\" rel=\"nofollow noopener\">Redis<\/a> o <a href=\"https:\/\/memcached.org\/\" target=\"_blank\" rel=\"nofollow noopener\">Memcached<\/a>) es que los transients modifican por completo su ciclo de vida f\u00edsico. Al activar estas tecnolog\u00edas en tu infraestructura, las funciones nativas de WordPress interceptan las llamadas de almacenamiento y desv\u00edan los transitorios para que vivan exclusivamente dentro de la memoria RAM del servidor. Como consecuencia directa, los transients dejan de escribirse y acumularse en la tabla f\u00edsica wp_options de <a href=\"https:\/\/www.mysql.com\/\" target=\"_blank\" rel=\"nofollow noopener\">MySQL<\/a>, deteniendo de ra\u00edz el bloat o engrosamiento de la base de datos relacional.<\/p>\n<h3>2. Identificaci\u00f3n de basura real de plugins desinstalados<\/h3>\n<p>Los componentes retirados suelen dejar tras de s\u00ed un volumen masivo de datos persistentes. Antes de ejecutar cualquier sentencia de eliminaci\u00f3n, es fundamental conectarse mediante protocolos seguros (SFTP\/SSH) al directorio <code>\/wp-content\/plugins\/<\/code> y comprobar que las carpetas de dichos componentes ya no existen en el sistema de archivos. Al auditar el autoload, es frecuente encontrar firmas de &#8220;infractores&#8221; comunes:<\/p>\n<ul>\n<li><code>301_redirects<\/code>: Historiales de redirecciones acumulados, logs de reescritura y configuraciones pesadas que ciertos plugins gratuitos de SEO o gesti\u00f3n de enlaces dejan de forma hu\u00e9rfana en la base de datos tras ser removidos de la plataforma.<\/li>\n<li><code>wpurp_custom_template_%<\/code>: Plantillas personalizadas y fragmentos de c\u00f3digo estructural pertenecientes al plugin WP Ultimate Recipe que persisten en el sistema incluso si ya no se utiliza la extensi\u00f3n en el servidor.<\/li>\n<li><code>um_cache_userdata_%<\/code>: Claves de cach\u00e9 de perfiles de usuario generadas din\u00e1micamente por el plugin de membres\u00edas Ultimate Member. Estas inflan la tabla de manera desmedida y deben purgarse directamente desde los ajustes avanzados de su panel interno para prevenir su regeneraci\u00f3n descontrolada.<\/li>\n<li><code>transient_beehive%<\/code>: Registros temporales y cach\u00e9s redundantes inyectadas por el plugin de anal\u00edtica Beehive Pro que no cuentan con rutinas de autodestrucci\u00f3n eficientes.<\/li>\n<\/ul>\n<p>Para remover f\u00edsicamente este tipo de residuos tras validar su procedencia, se emplean consultas estructuradas dirigidas:<\/p>\n<pre><code>DELETE FROM wp_options WHERE option_name LIKE 'wpurp_custom_template_%';<\/code><\/pre>\n<h2>Qu\u00e9 opciones no deber\u00edas tocar bajo ninguna circunstancia<\/h2>\n<p>Una limpieza demasiado agresiva sin verificar el origen de los datos puede corromper el sitio web de manera irreversible. Existen registros cr\u00edticos dentro de wp_options que jam\u00e1s deben ser eliminados ni modificados de forma manual:<\/p>\n<ul>\n<li><strong>Opciones esenciales del n\u00facleo (Core Options):<\/strong> Claves como <code>siteurl<\/code>, <code>home<\/code>, <code>blogname<\/code>, <code>active_plugins<\/code>, <code>template<\/code>, <code>stylesheet<\/code> y <code>wp_user_roles<\/code> son vitales para el enrutamiento de URLs, la carga del tema activo, los permisos de usuarios y la inicializaci\u00f3n del sitio. Su eliminaci\u00f3n corromper\u00e1 el acceso a la plataforma de inmediato.<\/li>\n<li><strong>Ajustes de plugins en uso:<\/strong> Configuraciones estructurales que guardan las credenciales de pasarelas de pago activos, configuraciones de seguridad de cortafuegos o datos de constructores visuales en producci\u00f3n.<\/li>\n<\/ul>\n<p>Por seguridad, antes de hacer cualquier modificaci\u00f3n de tipo destructivo sobre el motor de almacenamiento, es <del>un requisito ineludible<\/del> obligatorio generar una copia de seguridad (backup) completa de la base de datos.<\/p>\n<h2>Nivel pro para tiendas e-commerce: optimizaci\u00f3n avanzada en WooCommerce<\/h2>\n<p>Las plataformas de comercio electr\u00f3nico gestionadas mediante <strong>WooCommerce<\/strong> sufren una susceptibilidad cr\u00edtica de degradaci\u00f3n debido a la r\u00e1pida acumulaci\u00f3n de datos temporales din\u00e1micos de los clientes.<\/p>\n<h3>El problema de las sesiones hu\u00e9rfanas<\/h3>\n<p>WooCommerce almacena el estado de navegaci\u00f3n de los visitantes, los carritos activos y los c\u00f3digos de cup\u00f3n temporales en la tabla wp_options bajo las claves <code>_wc_session_xxx<\/code> y <code>_wc_session_expires_xxx<\/code>. Bajo configuraciones espec\u00edficas del servidor (como tener el WP-Cron nativo desactivado permanentemente mediante wp-config.php sin una alternativa real configurada a nivel de sistema operativo , o sufrir un rastreo agresivo de bots de spam que generan una sesi\u00f3n nueva por cada URL indexada), las sesiones expiradas dejan de limpiarse y se acumulan por decenas de miles, ralentizando el acceso general de los compradores.<\/p>\n<p>Si la tabla ha alcanzado un tama\u00f1o tan cr\u00edtico que los intentos de limpieza desde el panel administrativo fallan debido a limitaciones de tiempo de ejecuci\u00f3n de PHP, se debe aplicar una purga masiva directa desde la base de datos:<\/p>\n<pre><code>DELETE FROM wp_options WHERE option_name LIKE '_wc_session_%';<\/code><\/pre>\n<h3>La transici\u00f3n arquitect\u00f3nica hacia HPOS (<a href=\"https:\/\/developer.woocommerce.com\/docs\/features\/high-performance-order-storage\/\" target=\"_blank\" rel=\"nofollow noopener\">High-Performance Order Storage<\/a>)<\/h3>\n<p>Para resolver la degradaci\u00f3n de rendimiento a largo plazo de una tienda online, la decisi\u00f3n de ingenier\u00eda m\u00e1s recomendada consiste en realizar la transici\u00f3n hacia el sistema de almacenamiento de pedidos de alto rendimiento (HPOS). Por defecto, WooCommerce almacena el hist\u00f3rico de pedidos, facturas e informaci\u00f3n de transacciones dentro de la tabla general de metadatos de WordPress (wp_postmeta), forzando la inyecci\u00f3n de m\u00faltiples filas verticales por cada transacci\u00f3n efectuada.<\/p>\n<p>Al habilitar la funci\u00f3n HPOS desde los ajustes internos del sistema, WooCommerce migra de forma limpia toda esta informaci\u00f3n hist\u00f3rica estructurada hacia tablas dedicadas de pedidos de uso exclusivo (como wc_orders o wc_order_addresses). Esta separaci\u00f3n arquitect\u00f3nica reduce dr\u00e1sticamente el volumen de transacciones de lectura y escritura sobre las tablas compartidas de WordPress, aislando el n\u00facleo operativo del sitio de posibles bloqueos l\u00f3gicos en la base de datos.<\/p>\n<h2>Herramientas de limpieza y el impacto de tu infraestructura de hosting<\/h2>\n<p>Para entornos donde se prefiere evitar la ejecuci\u00f3n directa de comandos SQL, existen <em><strong>plugins de optimizaci\u00f3n y limpieza<\/strong><\/em> reputados en el directorio oficial de WordPress. No obstante, la compatibilidad y seguridad de estas herramientas var\u00edan de forma sustancial seg\u00fan la infraestructura de alojamiento utilizada:<\/p>\n<ul>\n<li><strong><a href=\"https:\/\/es.wordpress.org\/plugins\/advanced-database-cleaner\/\" target=\"_blank\" rel=\"nofollow noopener\">Advanced Database Cleaner<\/a> y <a href=\"https:\/\/es.wordpress.org\/plugins\/wp-sweep\/\" rel=\"nofollow noopener\" target=\"_blank\">WP-Sweep<\/a>:<\/strong> Son herramientas ideales para categorizar minuciosamente las opciones hu\u00e9rfanas, los transitorios activos y las tablas remanentes de plugins desinstalados. <strong>WP-Sweep<\/strong> destaca especialmente porque realiza tareas de limpieza respetando de forma estricta las funciones l\u00f3gicas nativas del n\u00facleo de WordPress para evitar inconsistencias de datos.<\/li>\n<li><strong>Advertencia cr\u00edtica sobre WP-Optimize:<\/strong> Aunque es una soluci\u00f3n integrada todo en uno muy popular, debes tener en cuenta que en entornos de hosting administrado especializado, las funciones de optimizaci\u00f3n estructural de <a href=\"https:\/\/es.wikipedia.org\/wiki\/InnoDB\" target=\"_blank\" rel=\"nofollow noopener\">tablas InnoDB<\/a> son bloqueadas o resultan incompatibles de forma autom\u00e1tica. Esto se debe a que el proveedor ya gestiona estas tareas de mantenimiento de forma directa a nivel de servidor. En dichos escenarios, el uso de <strong>WP-Sweep<\/strong> es significativamente m\u00e1s seguro y compatible.<\/li>\n<li><strong><a href=\"https:\/\/es.wordpress.org\/plugins\/artiss-transient-cleaner\/\" target=\"_blank\" rel=\"nofollow noopener\">Transient Cleaner<\/a>:<\/strong> Una alternativa excelente y especializada de forma exclusiva si el administrador \u00fanicamente desea buscar y eliminar sistem\u00e1ticamente transitorios expirados de forma segura mediante procesos automatizados sin intervenir en ning\u00fan otro par\u00e1metro de la base de datos.<\/li>\n<\/ul>\n<h2>Prevenci\u00f3n estructural: \u00edndices compuestos y compactaci\u00f3n de datos<\/h2>\n<p>Una vez ejecutada la limpieza y el saneamiento l\u00f3gico de la tabla wp_options, se deben implementar estrategias t\u00e9cnicas a nivel de infraestructura para acelerar de forma sostenida los tiempos de respuesta del sitio.<\/p>\n<h3>Adici\u00f3n de un \u00edndice compuesto optimizado<\/h3>\n<p>Las instalaciones nativas de WordPress suelen indexar la columna autoload de manera simple, lo cual resulta ineficiente debido a su baja cardinalidad (los \u00fanicos estados disponibles son variaciones de afirmaci\u00f3n y negaci\u00f3n). Para lograr una mejora significativa de rendimiento y evitar que el motor de la base de datos tenga que realizar un escaneo completo de la tabla (Full Table Scan) en cada consulta de opciones, se recomienda a\u00f1adir un \u00edndice compuesto que fusione de forma bidimensional el estado del autoload y el nombre de la opci\u00f3n:<\/p>\n<pre><code>ALTER TABLE wp_options ADD INDEX wp_options_autoload_option_name (autoload, option_name);<\/code><\/pre>\n<p>Este \u00edndice compuesto permite al motor relacional de la base de datos filtrar y entregar de forma instant\u00e1nea el conjunto de opciones con carga autom\u00e1tica activa sin necesidad de evaluar de manera secuencial la totalidad de las filas de la tabla.<\/p>\n<p><strong>Nota sobre la indexaci\u00f3n:<\/strong> Al implementar esto, debes considerar el principio de balance en motores SQL: los \u00edndices aceleran dr\u00e1sticamente las lecturas (operaciones SELECT), pero a\u00f1aden un peque\u00f1o overhead matem\u00e1tico en los tiempos de escritura (operaciones INSERT, UPDATE y DELETE), ya que MySQL se ve obligado a actualizar el \u00e1rbol del \u00edndice indexado con cada nuevo registro en el disco f\u00edsico. En la tabla wp_options, este intercambio t\u00e9cnico es sumamente favorable, dado que las consultas de lectura superan de forma masiva a las transacciones de escritura durante el ciclo de vida ordinario de la aplicaci\u00f3n.<\/p>\n<h3>Compactaci\u00f3n f\u00edsica de datos reclamando espacio en disco<\/h3>\n<p>Debido a los mecanismos operativos del motor de almacenamiento InnoDB de MySQL y <a href=\"https:\/\/www.nicalia.com\/blog\/mariadb-vs-mysql\/\">MariaDB<\/a>, la eliminaci\u00f3n masiva de registros l\u00f3gicos en una tabla de base de datos no reduce de manera autom\u00e1tica el peso f\u00edsico de los archivos guardados en el disco duro del servidor. En su lugar, el espacio previamente ocupado por los registros eliminados se mantiene en un estado de fragmentaci\u00f3n interna para futuras inserciones de datos. Para reconstruir de forma f\u00edsica la tabla wp_options, optimizar sus \u00edndices, recuperar el espacio en disco liberado y compactar la estructura interna de archivos, se debe ejecutar la siguiente instrucci\u00f3n SQL:<\/p>\n<pre><code>OPTIMIZE TABLE wp_options;<\/code><\/pre>\n<p>Dado que esta consulta bloquea de forma temporal el acceso de escritura a la tabla mientras se genera una copia limpia y reordenada en el disco del servidor, se recomienda encarecidamente programar su ejecuci\u00f3n durante periodos de mantenimiento del sistema o de bajo tr\u00e1fico concurrente en la web.<\/p>\n<blockquote><p><em>Mantener una base de datos optimizada requiere un monitoreo constante de la infraestructura de sistemas. En <strong>Nicalia<\/strong>\u00a0ponemos a tu disposici\u00f3n nuestra infraestructura optimizada de hosting de alta gama junto con un equipo de soporte t\u00e9cnico especializado, capacitado para auditar, limpiar y acelerar tu entorno WordPress con total seguridad y sin interrumpir tus operaciones comerciales.<\/em><\/p><\/blockquote>\n","protected":false},"excerpt":{"rendered":"<p>ACTUALIZADA: 25\/5\/226 C\u00f3mo reducir el tama\u00f1o de la tabla wp_options en WordPress sin romper nada Un Tiempo al Primer Byte (TTFB) inusualmente alto o la [&hellip;]<\/p>\n","protected":false},"author":11,"featured_media":3558,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[92,95,91],"tags":[],"_links":{"self":[{"href":"https:\/\/www.nicalia.com\/blog\/wp-json\/wp\/v2\/posts\/1065"}],"collection":[{"href":"https:\/\/www.nicalia.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.nicalia.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.nicalia.com\/blog\/wp-json\/wp\/v2\/users\/11"}],"replies":[{"embeddable":true,"href":"https:\/\/www.nicalia.com\/blog\/wp-json\/wp\/v2\/comments?post=1065"}],"version-history":[{"count":4,"href":"https:\/\/www.nicalia.com\/blog\/wp-json\/wp\/v2\/posts\/1065\/revisions"}],"predecessor-version":[{"id":3560,"href":"https:\/\/www.nicalia.com\/blog\/wp-json\/wp\/v2\/posts\/1065\/revisions\/3560"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.nicalia.com\/blog\/wp-json\/wp\/v2\/media\/3558"}],"wp:attachment":[{"href":"https:\/\/www.nicalia.com\/blog\/wp-json\/wp\/v2\/media?parent=1065"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.nicalia.com\/blog\/wp-json\/wp\/v2\/categories?post=1065"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.nicalia.com\/blog\/wp-json\/wp\/v2\/tags?post=1065"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}