Vamos a empezar por el principio: voy a intentar hacer un post que es bastante necesario para los usuarios medios/avanzados de WordPress que hacen mantenimientos de sus sitios o de los sitios web WordPress de sus clientes. Hoy vamos a intentar entender la base de datos de WordPress, su estructura, sus tablas y sus puntos débiles.
Como dije en el primer párrafo: empecemos por el principio.
WordPress es un CMS desarrollado en PHP que guarda los datos y ciertas partes de la configuración en una base de datos MySQL o MariaDB. Evidentemente, la base de datos es muy importante, ya que contiene lo más importante de un sitio web: EL CONTENIDO.
- ¿Dónde se guarda tu contraseña de usuario? En la base de datos.
- ¿Dónde se guarda la configuración de Yoast SEO? En la base de datos.
- ¿Dónde se guardan tus posts y páginas? En la base de datos.
- ¿En WooCommerce, dónde se guardan tus pedidos? En la base de datos.
- ¿Dónde se guarda…? Bueno, no voy a seguir porque podría estar así todo el día.
En resumen, la DB de WordPress es muy importante y, en muchos casos, es necesario entenderla y saber qué podemos borrar y qué no.
La base de datos de WordPress se va llenando de “mierda” con el tiempo y poco a poco puede complicarnos ciertas labores básicas. Por ejemplo, con las copias de seguridad o con “slow queries” cada vez que algún plugin realiza una consulta un poco compleja a la base de datos.
Vamos a desglosar este artículo en los siguientes puntos o secciones, pero empezaremos por la teoría.
¿Quieres
recibir mis articulos?
No te pierdas todos mis trucos para WordPress, CMS, Marketing Digital y WPO.
Base de datos de WordPress
Como he dicho, vamos a empezar con la teoría.
WordPress, de forma nativa, puede trabajar con bases de datos MySQL y también con MariaDB, ya que es un fork de MySQL y son totalmente compatibles. Además, mediante librerías externas también podemos hacer que WordPress funcione con SQLite, muy útil para casos en los que el hosting no ofrece la posibilidad de tener bases de datos MySQL.
Cuando instalamos WordPress, la instalación base crea las tablas necesarias en la base de datos MySQL o MariaDB. Las tablas que se crean son 12 y son las siguientes:
- wp_commentmeta: Contiene metadatos de los comentarios del blog, guardados en la tabla wp_comments.
- wp_comments: Contiene los comentarios, es decir, el contenido de los comentarios del blog.
- wp_links: Aquí se guardan los enlaces si la funcionalidad está activada. Antiguamente siempre venía activada al instalar WordPress.
- wp_options: Es una de las tablas más importantes de WordPress, ya que guarda toda la configuración e incluso algunos plugins pueden guardar datos de contenido ahí. En el 99% de los casos, las slow queries ocurren en consultas realizadas a esta tabla en instalaciones muy “saturadas”.
- wp_postmeta: Contiene metadatos relacionados con los posts de la tabla wp_posts. En algunas ocasiones, cuando usamos themes o plantillas muy “completas”, se puede llenar muy rápido con datos irrelevantes y causar slow queries también.
- wp_posts: Almacena el contenido de los posts, páginas y cualquier custom-post que se registre en la instalación de WordPress. Por ejemplo, los productos de un WooCommerce.
- wp_termmeta: Contiene los metadatos de las categorías y etiquetas. En algunos casos, esta tabla también ha sido protagonista de problemas y errores que provocaban altos consumos de recursos de CPU.
- wp_terms: Contiene las categorías y las etiquetas de la instalación WordPress.
- wp_term_relationships: Almacena la asociación entre los posts y las categorías y etiquetas con las que están relacionados.
- wp_term_taxonomy: Aquí se guardan las descripciones de las etiquetas y categorías, es decir, es una tabla relacionada con wp_terms.
- wp_usermeta: Contiene metadatos de los usuarios registrados en la instalación de WordPress y que podemos encontrar en wp_users.
- wp_users: Contiene los datos de los usuarios que tenemos en WordPress.
Las tablas las he puesto con el prefijo por defecto, “wp_”, pero podríamos sustituirlo por otro y, de hecho, es lo recomendable para mejorar la seguridad del CMS.
Este es el esquema generado con MySQL WorkBench de la base de datos por defecto de un WordPress con los distintos tipos de campos de datos:
Adicionalmente, cuando un plugin necesita guardar datos en la base de datos de WordPress (algo muy común) puede hacerlo en las tablas existentes o, por el contrario, crear tablas nuevas en la DB. Esto depende del tipo de datos que vaya a guardar el plugin.
Para que te hagas una idea, cuando instalamos WooCommerce en WordPress se añaden las siguientes tablas:
- wp_wc_download_log
- wp_wc_product_meta_lookup
- wp_wc_tax_rate_classes
- wp_wc_webhooks
- wp_woocommerce_api_keys
- wp_woocommerce_attribute_taxonomies
- wp_woocommerce_downloadable_products_permissions
- wp_woocommerce_log
- wp_woocommerce_order_itemmeta
- wp_woocommerce_order_items
- wp_woocommerce_payment_tokementa
- wp_woocommerce_paypal_tokens
- wp_woocommerce_sessions
- wp_woocommerce_shipping_zones
- wp_woocommerce_shipping_zone_locations
- wp_woocommerce_shipping_zone_methods
- wp_woocommerce_tax_rates
- wp_woocommerce_tax_rate_locations
Como ves, se añaden muchas más tablas a la base de datos MySQL de WordPress. Cuando esas tablas se empiezan a llenar y a acumular datos, es cuando la base de datos de WordPress empieza a coger peso.
En el caso de WooCommerce, existe un problema mayor. A pesar de ser la solución para ecommerce más utilizada del mundo, con una cuota de mercado aplastante frente a la competencia, WooCommerce es un plugin para WordPress y depende de la arquitectura de WordPress para muchas cosas, como la base de datos.
En una tienda online WooCommerce todos los productos se meten en la tabla wp_posts y wp_postmeta, exactamente igual que si metemos entradas al blog. Por esta razón, cuando trabajamos con grandes catálogos de productos en WooCommerce podemos tener problemas con las consultas lanzadas a la base de datos para obtener los listados de los productos.
Existen plugins como Premmerce WooCommerce Performance Optimizer que sirven para crear índices de ciertas tablas de la base de datos que suelen almacenar muchos datos, con el fin de que las consultas SQL realizadas a esas tablas sean mucho más rápidas.
Optimizar la base de datos de WordPress
¿Y cuál es la razón por la que podemos querer optimizar el tamaño de la base de datos de WordPress? Ya que no podemos modificar la estructura de la base de datos de WordPress, lo que debemos hacer es aligerar la base de datos innecesarios.
¿Cómo podemos optimizar la base de datos MySQL o MariaDB de un WordPress?
Existen varias formas, algunas manuales y otras automáticas. Evidentemente, las manuales requieren conocimientos más o menos avanzados sobre SQL y la estructura propia de la base de datos. Las formas automáticas se realizan mediante plugins para WordPress.
Antes de nada, vamos a aclarar ciertas cosas que nos podemos encontrar en la base de datos de WordPress y que podemos limpiar en algunos casos para conseguir reducir el tamaño:
- Transients: Los transients son datos que se guardan en la tabla wp_options de WordPress y que funcionan como cache en base de datos para el funcionamiento de algunos plugins y themes. El problema de los transients es que, en instalaciones muy complejas, suelen acumularse muchos y, si no se borran, se quedan almacenados dando problemas con el tamaño y la complejidad.
- Revisiones y borradores guardados: El editor de WordPress guarda borradores y revisiones de los posts y páginas (y otros custom-posts) abiertos cada cierto tiempo. Por un lado, las revisiones y borradores pueden servirnos de ayuda si tenemos algún problema de pérdida de datos aunque, por otro lado, ocupan espacio en la base de datos de WordPress.
- Objetos de las papeleras: Normalmente los objetos que están en la papelera son porque no los queremos, así que podemos vaciar por completo las papeleras para liberar espacio en la base de datos de WordPress.
- Trackbacks y Pingbacks: Los trackbacks y pingbacks pueden ser útiles para mucha gente, pero no para la mayoría. Actualmente, los pingbacks y trackbacks están desuso y casi siempre están desactivados. Sin embargo, en caso de tener alguno antiguo en nuestro WordPress podemos borrarlo de las tablas de la base de datos.
- Metadatos huérfanos: Para la tabla wp_users, para la tabla wp_comments y para la tabla wp_posts existen tablas META que guardan metadatos del contenido de las tablas anteriormente mencionadas. En algunos casos, pueden quedarse metadatos huérfanos que debemos limpiar para evitar que ocupen espacio innecesario en la base de datos.
Vamos a mostrar métodos automáticos para optimizar la DB de WordPress, es decir, mediante plugins para WordPress. Finalmente, hablaremos de los métodos manuales para limpiar algunos elementos de la base de datos MySQL / MariaDB de WordPress.
Tal vez te pueda interesar también este videotutorial simple que he publicado en mi canal de Youtube:
Plugin WP Database Tools para WordPress
Antes de nada, quiero aclarar que WP Database Tools es un plugin creado por nosotros, por Raiola Networks.
Lo que intentamos con WP Database Tools es que sea un “pack” de herramientas para optimizar y gestionar la base de datos de WordPress.
Y precisamente hemos empezado por integrar una herramienta de limpieza de las tablas de la base de datos de WordPress, que además permite saber de qué plugin o theme es cada tabla, cada options o cada cronjob.
Además, nos permite detectar tablas, options y cronjobs de plugins que han sido desinstalados y están ocupando espacio y consumiendo recursos en nuestro hosting, donde tenemos instalado nuestro WordPress.
Este plugin está en constante desarrollo, y lo sé porque nosotros somos los desarrolladores.
Aunque las funciones integradas en la versión 1.0 han sido las de limpieza, puliendo poco a poco el reconocimiento de datos y el API externa, poco a poco se van añadiendo más cosas.
Nos centramos en reconocer autoloads, transients, options huerfanos, etc… es decir, todos los elementos que hay en la base de datos de WordPress y que pueden dañar el rendimiento.
Puedes encontrar más información sobre este plugin en este post más extenso: https://alvarofontela.com/limpiar-base-de-datos-wordpress/
Si quieres ir directamente a la página del plugin, puedes ir desde aquí: https://wpdatabasetools.com/
Plugin WP Optimize para WordPress
El plugin WP Optimize para WordPress es uno de los plugins más conocidos para limpiar y optimizar la base de datos de WordPress.
Se trata de un plugin gratuito y que, actualmente, tiene algunas funcionalidades añadidas relacionadas con el WPO general de WordPress.
Aunque también nos hará un listado completo de las tablas de la base de datos de WordPress, detectando las tablas huérfanas (de plugins desactivados) y permitiéndonos borrarlas para ahorrar espacio en la base de datos:
Como he dicho, es un plugin de los más conocidos y de los más utilizados. Aunque reconozco que su limpiador no es el más potente, su funcionalidad para detectar tablas huérfanas es de las más útiles y potentes, ya que normalmente las tablas huérfanas con el paso del tiempo suelen traer bastantes problemas.
Si quieres más información acerca del plugin WP Optimize para WordPress, puedes hacer clic aquí: https://es.wordpress.org/plugins/wp-optimize/
Plugin WP Rocket para WordPress
Finalmente, como siempre, vuelvo a hablar de WP Rocket para WordPress. Aunque es un plugin de cache, también tiene un módulo de optimización de la base de datos de WordPress que podemos aprovechar, pese a que es mucho más simple que cualquiera de las dos opciones que hemos comentado anteriormente.
Como he dicho, se trata de un optimizador bastante básico. Tanto es así que yo, en mis clases de WPO, me lo suelo saltar ya que no lo tengo ni como opción.
Pero si usas WP Rocket y tienes pánico a instalar muchos plugins en tu WordPress, su limpiador de bases de datos puede ayudarte.
Si quieres más información acerca de WP Rocket para WordPress: https://alvarofontela.com/wprocket
También quiero mencionar, antes de acabar, que la herramienta de limpieza y optimización de base de datos de uno de los competidores de WP Rocket, Swift Performance, es algo más completa.
Plugin WP-DBManager para WordPress
WP-DBManager es un plugin gratuito muy simple que nos permitirá realizar algunas acciones interesantes en la base de datos de WordPress.
Ofrece bastante información sobre la base de datos y las tablas:
Nos permite optimizar y reparar la base de datos MySQL o MariaDB, así como eliminar tablas que nosotros queramos, como las que guardan logs o registros que no son necesarios para el funcionamiento normal de WordPress:
Evidentemente, todo esto también lo podemos realizar de igual forma con phpMyAdmin, pero resulta bastante útil poder hacerlo directamente con un plugin para WordPress.
Si quieres más información acerca de WP-DBManager, puedes encontrarla en la ficha del plugin en el repositorio de plugins de WordPress: https://es.wordpress.org/plugins/wp-dbmanager/
Optimización manual mediante consultas SQL
Todos los plugins anteriormente mencionados funcionan de una forma relativamente fácil, ya que simplemente ejecutan sentencias SQL en la base de datos.
Para ejecutar consultas SQL podemos hacerlo de distintas formas. Por un lado, podemos utilizar la herramienta PHPMyAdmin que tienen el 99,9% de los hosting:
La pestaña “SQL” que puedes ver en la imagen anterior es la que nos permitirá ejecutar sentencias SQL directamente en el servidor MySQL / MariaDB.
Empezamos con la eliminación de revisiones del editor de WordPress, con esta sentencia SQL las borraremos todas de la base de datos de WordPress:
1 2 3 4 5 6 7 | DELETE a,b,c FROM wp_posts a LEFT JOIN wp_term_relationships b ON ( a.ID = b.object_id) LEFT JOIN wp_postmeta c ON ( a.ID = c.post_id ) LEFT JOIN wp_term_taxonomy d ON ( b.term_taxonomy_id = d.term_taxonomy_id) WHERE a.post_type = 'revision' AND d.taxonomy != 'link_category'; |
Las revisiones normalmente, si no las utilizamos, sobran todas y solo ocupan espacio.
Con esta otra sentencia eliminarás todos los comentarios marcados como SPAM que hay en la base de datos de WordPress:
1 | DELETE FROM wp_comments WHERE comment_approved = 'spam'; |
Y con esta otra sentencia SQL puedes borrar todos los comentarios que no han sido aprobados:
1 | DELETE from wp_comments WHERE comment_approved = '0'; |
Con esta otra sentencia podemos limpiar los tags que no tienen ningún post asociado, lo cual es muy útil cuando hay una cantidad brutal de etiquetas / tags y no podemos seleccionarlas de forma manual:
1 2 3 | DELETE FROM wp_terms WHERE term_id IN (SELECT term_id FROM wp_term_taxonomy WHERE count = 0 ); DELETE FROM wp_term_taxonomy WHERE term_id not IN (SELECT term_id FROM wp_terms); DELETE FROM wp_term_relationships WHERE term_taxonomy_id not IN (SELECT term_taxonomy_id FROM wp_term_taxonomy); |
Con esta otra sentencia SQL eliminarás todos los pingbacks y trackbacks que tenga la base de datos de WordPress. Muy útil si ya los tienes previamente desactivados:
1 2 | DELETE FROM wp_comments WHERE comment_type = 'pingback'; DELETE FROM wp_comments WHERE comment_type = 'trackback'; |
Con este código eliminarás TODOS los transients que existan dentro de la base de datos de WordPress, en la tabla wp_options:
1 | DELETE FROM wp_options WHERE option_name LIKE ('%\_transient\_%') |
Es recomendable borrar los transients cada cierto tiempo para evitar que se sobrecargue la base de datos con contenido temporal.
Finalmente, también podemos optimizar la base de datos de WordPress con la función de optimización de phpMyAdmin:
Para ello, como puedes ver en la imagen anterior, seleccionamos todas las tablas de la DB de WordPress y seleccionamos la opción de optimizar en el desplegable.
Crear índices en la base de datos de WordPress
Una forma de optimizar la velocidad de carga al hacer consultas a la base de datos de WordPress es utilizando índices.
Realmente, un “índice” es lo que indica la palabra. Funciona como el índice de un libro y nos permiten encontrar contenido de forma más rápida dentro de una base de datos. Por eso, reduce los tiempos de respuesta de las consultas y también el consumo de recursos.
En instalaciones WordPress muy grandes se suelen utilizar índices en la tabla wp_options.
Podemos hacer esto de forma manual o utilizando plugins que nos mantendrán actualizado el índice sin que nosotros tengamos que mantenerlo.
Existen distintos plugins gratuitos para mantener un índice de todas las opciones que tengan el parámetro “autoload” en la tabla wp_options. Las opciones con el parámetro “autoload” son cargadas por la función wp_load_alloptions() y que se cargan en TODO el sitio web de forma global, aunque en algunas partes no son necesarias.
El problema es que, cuantos más registros tenga la tabla wp_options de WordPress, más registros tendrán el campo “autoload” en activado. Como resultado, tendremos problemas de slow queries en las cargas.
El plugin Add Index To Autoload te permitirá mantener un índice de las tablas con autoload de wp_options: https://wordpress.org/plugins/add-index-to-autoload/
Si quieres implementar de forma manual un índice para la tabla wp_options y los parámetros con autoload, puedes seguir el siguiente manual: https://guides.wp-bullet.com/add-mysql-index-wordpress-wp_options-table/
Optimizar la base de datos de WooCommerce
Cuando trabajamos con WordPress + WooCommerce, uno de los problemas que nos encontramos al trabajar con grandes catálogos es que tenemos problemas con las consultas grandes a la base de datos.
Como he dicho antes, el problema en gran parte viene por la arquitectura que tiene una tienda online creada con WooCommerce, donde los productos se guardan en la tabla donde se guardarían los posts en WordPress.
Existen plugins que nos permiten crear índices de la DB para la tabla wp_options y el parámetro autoload, pero también existe un plugin que nos permite crear índices de las tablas de contenido con el fin de acelerar un poco las consultas cuando tenemos en un WooCommerce un catalogo muy grande de productos.
El plugin Premmerce WooCommerce Performance Optimizer es un complemento que teóricamente, entre otras cosas, ajusta ciertas cosas en la forma en la que se cargan los productos desde la DB en WooCommerce con el fin de acelerar la carga.
La teoría dice que se consiguen mejores resultados, aunque tampoco puedo garantizar una mejoría ya que no lo he probado con webs lo suficientemente grandes. Estos son los tests que hizo su desarrollador y que nos ofrece en su blog oficial: https://premmerce.com/testing-online-store-500k-products-powered-woocommerce/
Puedes encontrar más información sobre Premmerce WooCommerce Performance Optimizer y su utilización en el post que he publicado sobre cómo optimizar WooCommerce y su WPO: https://alvarofontela.com/wpo-optimizar-woocommerce-tienda-online/
Reparar la base de datos de WordPress
Existen distintos métodos para reparar una base de datos de WordPress con daños o inconsistencia de datos.
¿Cómo puede dañarse una base de datos MySQL o MariaDB de WordPress? Pues fácil, una de las razones suele ser las constantes caídas del servidor MySQL / MariaDB hasta que algo se dañe.
Con phpMyAdmin podemos reparar la base de datos de WordPress:
Pero WordPress también trae un mecanismo de reparación de la base de datos que podemos activar desde el wp-config.php con el siguiente parámetro:
1 | define('WP_ALLOW_REPAIR', true); |
Si no sabes editar el wp-config.php de tu WordPress, puedes ver el siguiente vídeotutorial:
Después de añadir el parámetro al wp-config.php, nos vamos al navegador e introducimos la URL de tu sitio web como en este ejemplo:
1 |
Lo que obtendremos es un asistente que nos permitirá reparar o reparar y optimizar la base de datos MySQL.
Y esto es un ejemplo de caso en el que algunas tablas se reparan y otras no pueden repararse por distintas razones:
Cualquiera de estos dos métodos para reparar la DB de WordPress no son infalibles y, en muchos casos, es necesario jugar con las copias de seguridad existentes y reimplantar ciertas tablas para conseguir devolver la integridad a la base de datos y la consistencia a los datos.
Optimizar un servidor MySQL o MariaDB
Para finalizar, vamos a hablar de las optimizaciones que podemos hacer de un servidor de base de datos MySQL o MariaDB.
Existen unos cuantos parámetros que podemos tocar, sobre todo para adaptar el funcionamiento del servidor a las necesidades de la aplicación o aplicaciones que se ejecutan.
Cuando me toca optimizar servidores con webs muy pesadas y exigentes, normalmente utilizo el script MySQL Tuner, desarrollado en Perl.
Con el script MySQL Tuner analizo el rendimiento y la utilización del servicio MySQL o MariaDB durante las últimas 24 horas con un funcionamiento normal. Posteriormente, lo ejecuto para ver qué cambios tengo que hacer en los parámetros del archivo de configuración my.conf.
Si quieres más información acerca del script MySQL Tuner, puedes encontrarla aquí: https://github.com/major/MySQLTuner-perl
Como digo siempre en mis ponencias y en mis clases de WPO, para mí el primer paso para optimizar las consultas y el funcionamiento general de la base de datos es optimizar el funcionamiento del servidor MySQL o MariaDB mediante la configuración y correcta parametrización de los archivos de configuración.
En el caso de un servidor de hosting compartido especializado en WordPress, como los servidores de Raiola Networks, los parámetros de configuración de MariaDB están correctamente configurados para funcionar con la mayoría de CMS, especialmente el query_cache y los diferentes caches que se pueden configurar en el motor de base de datos.
49 Responses
Muy interesante artículo. Soy usuario entre novato e intermedio de Wordpress, con un sitio web en desarrollo y los datos que aportas en el artículo me han resultado útiles. Muchas gracias.
Muchas gracias Pablo, me alegro de que te sirva 🙂
Hola Alvaro… Como normalmente te sigo y creo que eres un crack jajaja. Y aunque no viene a cuento con este artículo, el Wp Rocket esta haciendo mal las redicciones de URL al “/” …. Aunque el canonical está en la URLs, por ejemplo, puedes ver que tienes https://alvarofontela.com/entendiendo-base-datos-mysql-wordpress/ sin “/” y se carga el artículo, y el https://alvarofontela.com/entendiendo-base-datos-mysql-wordpress/ por separado y se carga….
Los bichos de Wp Rocket no han dicho nada, pero desde https://docs.wp-rocket.me/article/131-redirection-to-enforce-trailing-slash-on-urls que fue publicado el 10 de Octubre de este año. (POR CIERTO, SI UTILIZÁIS EL PLUGIN, entre jpg|png|jpeg|css|xml|txt|js|….añadir también la extensión |ico| que parece mentira que hagan estos errores los de Wp Rocket en no tener en cuenta el Favicon).
Es para que tengas conocimiento, aquí cada cual que adopte la opción oportuna. Un saludo y gracias por el buen contenido de la web, Pau
Muchas gracias por avisar Pau, voy a revisar, pero en mi caso el problema viene por otro lado, por Nginx, ya que hace una semana y poco hice un cambio de servidor y creo que me olvide de ajustar el tema de los slash en Nginx para que redireccion de sin slash a con slash siempre.
Un saludo y muchas gracias.
Hola. Consulta. Al instalar wordpress localhost, no me aparece el cartel de finalizada la instalación…sino uno de conexion critica. Las 12 tablas se generan en la base de datos, pero la wp_users está vacia. Le inserto un usuario y clave en en wp_users para poder acceder luego por localhost/ , logro entrar pero no me aparece el dashboard…solo aparece mi pagina en blanco. Probe en 2 portatiles y me pasa lo mismo. Podrás guiarme ?
Hola Pablo, es un caso bastante raro, pero sin saber mas datos no puedo ayudarte.
Si puedes, envíame a través del formulario de contacto el error exacto y el stack que estas usando, ya que no es el típico error que suelen dar las instalaciones de WordPress, tiene que ser algo del stack por instalarlo en local…
Muy buen contenido y muy bien desmenuzado, Álvaro!
La verdad es que los temas de BD y otros aspectos técnicos de WP no son mi fuerte y este post me lo guardo en la lista de Musts.
Un abrazo, compañero!
Gracias Edu 😉
Hola. La explicacion esta muy interesante. Me saco muchas dudas. Pero tengo una pregunta. Si quiero manejar mis propias bases de datos que ya tengo creadas para mi sistema comercial con tablas de articulos clientes proveedores y demas. Se puede conectar wordpress a esa base de dato y hacer consultas o carga de datos.? Gracias.
Hola Sergio, con PHP siempre podrías hacerlo, pero debes tener cuidado con las actualizaciones y con distintos procedimientos “complejos”, ya que al núcleo de WordPress no le “gusta” que se lo salten (y evidentemente esas consultas no puedes hacerlas a través del núcleo de WordPress.
Lo que puedes hacer es crear un API PHP para esas tablas de clientes, proveedores y demás, y partir de ahí con una conexión desde WordPress.
Alvaro. Muchas gracias por la informacion brindada. Esa era mi gran duda. Bueno vamos a ver q hacemos porque necesito si o si interactuar con mis bases de datos q ya tengo en funcionamiento desde mis sistemas q no son web.
Gracias.
Buenas te doy un 10 al artículo. Impresionante.
Tuve un problema gordo de low queries en mi hosting compartido .
Hice limpieza de la BD a través Perfmatters y desactivó pinkbacks, revisiones, etc.. (por cierto gracias a tu recomendación)
Además desactivé el cron de WP y el Heartbeat como me sugirieron y me lo resolvió.
¿Faltaría algo más?
Por otro lado quisiera algún sistema o plugin para monitorizar la BD.
He indagado en el post que recomiendas y me llevan al servicio New Relic , que tal lo ves?
https://guides.wp-bullet.com/add-mysql-index-wordpress-wp_options-table/
Hola Isa, puedes utilizar el plugin Query Monitor para ver las slow queries y dependiendo de lo que te diga, puedes tomar decisiones: https://alvarofontela.com/query-monitor-solucionar-detectar-problemas-wordpress/
New Relic esta muy bien, pero es arma pesada, es decir, requiere la instalación de una extensión PHP (que en un hosting compartido no puedes hacerlo), requiere una cuenta en New Relic, que no es barata, etc…
New Relic es ideal para hacer debug en instalaciones MUY complejas, donde hay muchas capas de ejecución y New Relic permite ir por partes con un monitor externo.
Muy buen artículo, muchas gracias por compartir tus conocimientos.
Muchas gracias a ti por leerme Leonardo 🙂
Una consulta Alvaro: me toca idear una tienda online para un amigo comerciante y, al mismo tiempo, un software de facturación e inventario para su negocio, y me pregunto si es posible integrar ambos con los recursos de Wordpress, principalmente desde PHP/MySql/ que es donde me puedo defender mejor. Desde ya, agradezco cualquier orientación al respecto ya que las opciones que encontré en la web son muy variadas y “sofisticadas”, pero creo que ninguna cumple con ésos requisitos; lo que me da a pensar que quizás esté pidiendo demasiado. Gracias y perdón por extenderme tanto. Saludos.
Hola Leonardo, depende completamente del programa que utilices para eso.
A nivel TPV, existen POS para WooCommerce que funcionan bastante bien (https://alvarofontela.com/configurar-tpv-pos-woocommerce/), pero si buscas algo mas potente a nivel contabilidad, depende del software que utilices.
WooCommerce tiene una REST API para este tipo de conexión por webservice, pero como te he dicho, depende del software, y es el software quien tiene que darte la solución para la conexión.
Hola! Mi duda es algo compleja. Tengo Tutor LMS en mi wordpress y necesito estar duplicando cursos, lecciones, combinándolos, etc., pero esas funciones no existen en el plugin, y para duplicar un curso con todo su contenido tengo qué volver a hacerlo desde cero. ¿Habrá alguna forma de hacerlo duplicando segmentos de la base de datos? Lo he intentado pero solo se duplican los titulos sin el contenido. Lo mismo pasa si uso el plugin Duplicate Page. No importa si tengo que tomar varias horas de curso, pero si me pudieras recomendar algo te lo agradeceré enormemente! Saludos!
Bufff, Juan, es un tema complejo si, no conozco como funciona Tutor LMS, pero si guarda los datos en la tabla de posts, no solo tendrías que clonar los datos de posts, sino postmeta, y ahí esta el problema, ya que es una tabla difícil de limpiar, imaginate para clonar…eso es la puta jungla…
Se me ocurre una cosa…desconozco el plugin ya que nunca lo he usado, pero… ¿tiene función de importar y exportar? Si la tiene, podrías exportar el curso con sus lecciones y después volver a importarlo. Siempre teniendo en cuenta que no sobreescriba el actual y que no cause ningún problema de duplicado.
Ok! Eso me aclara más el asunto. No tiene función de importar y exportar los cursos ni lecciones, tiene pero solo es para los cuestionarios. Voy a estar respaldando la base de datos antes de cada cambio, y trataré de duplicar los postmeta. ¿Será igual que duplicar los post? ¿O habrá algún plugin externo que pueda hacer esto?si no, por lo que me dices, creo que será más fácil seguir como hasta ahora, volviendo a hacer cada curso desde cero. Te agradezco enormemente, te felicito por tu página, y ojalá conozcas algún plugin así. Saludos!
Pues no te se decir si seria como los posts, la tabla postmeta es un puto circo, no hay una coherencia “real” porque los posts y las paginas es facil saber que tienen X campos de forma nativa, pero un custom_post como pueden ser en este caso las lecciones, los cuestionarios y los cursos, pueden tener tantos metacampos como le salga de las narices al autor del plugin, entonces es fácil dejarse cosas atrás.
Si la pregunta es: “¿es posible hacerlo?” Si, es posible, pero o te miras la documentación, o lo consultas con el autor para que te pase un desglose de lo que hace en la DB o haces prueba error.
Hola Álvaro:
Excelente post, como es costumbre en ti. Un plugin que también utilizo para limpiar la base de datos es “Plugins Garbage Collector”, que permite eliminar las tablas remanentes creadas por plugins ya desinstalados.
¡Saludos!
Hola Ramiro, antes de nada, muchas gracias por tus palabras.
No conocía ese plugin, lo acabo de probar y mola mucho, yo antes la limpieza de tablas la hacia manualmente con phpMyAdmin, pero este plugin facilita mucho el asunto.
Buenas, excelente artículo.
Soy nuevo en WordPress y deseo poder leer y escribir sobre mis propias tablas desde mi sitio realizado en WordPress. Tengo bastante experiencia con SQL, MySQL y phpMyAdmin. Me podría dar alguna sugerencia? Quizas un plugin?
Hola Pablo, depende de lo que quieras hacer te puede servir un CRUD o no, de todas formas, lo que te recomiendo siempre y cualquier plugin que uses lo va a hacer, es pasar por el núcleo de WordPress para comunicarte con las tablas, ya que comunicarse externamente con MySQL o MariaDB puede causarte problemas en el futuro.
Buen dia, por favor necesito orientaciones sorbe la compatibilidad de Wordpres con la base de datos postgres, es compatible?
Hola Mariuxi, oficialmente WordPress no es compatible con PostgreSQL, pero existe algun fork como este para permitirlos: https://medium.com/@shoaibhassan_/install-wordpress-with-postgresql-using-apache-in-5-min-a26078d496fb
Lo que no se, es si son estables y se actualizan.
Hola, buscamos una solución para integrar un sitio hecho en WordPress con un sistema de recepción y administración de quejas sabes si hay algún plugin ya hecho para esto? Si no, existe como se podrá integrar la base de datos de quejas con el sitio de WordPress?
Hola Gabriel, pues desconozco si hay algo para esto, pero con Gravity Forms y Gravity View dependiendo de lo que necesites podrías crearlo sin problema en WordPress.
Hola buenas noches
Una consulta como puedo utilizar a conexión existente entre wodpress y la base de datos, en php yo comúnmente tengo un archivo de conexión y dentro de el una variable con los datos de la base, y posteriormente utilizar dicho archivo de conexion donde lo requiriera.
Pero en wordpress no se como utilizar la conexión existente, me podrias ayudar.
Hola Francisco, teóricamente si, puedes usar la conexión a través del core de WordPress para sacar datos en el front-end, pero claro, tienes que usar los métodos de WordPress.
Existe documentación oficial sobre el tema: https://developer.wordpress.org/reference/classes/wpdb/
Hola Alvaro,
eh iniciado con WP hace poco, y desde hace aprox. 3 semanas estoy teniendo unos incovenientes con la BD de WP , las conexiones que usa el usuario que configure en el archivo wp-config.php para que pueda funcionar mi site, en algun momento determinado se generan demasiadas conexiones y la BD se staurá y la web deja de funcionar y tira el error (error de conexion a la BD) , leí que podria ser algun plugin, pero cuando se llena de conexiones el Mysql , quite todos los pluguin manualmente y las conexiones seguian activan . No se si tienes alguna idea de lo que pueda estar sucediendo , porque se generan demasiadas conexiones de usuario de Msql en la BD de WP ? y solo es el usuario que e creado para esta BD, es de alli donde pude comprobar que solo es con el WP el error.
Gracias por la respuesta. Saludos
Hola Angello, pues…después de desactivar los plugins, tienes que matar las conexiones MySQL abiertas, si ya lo has hecho y pese a tener todos los plugins desactivados, sigues teniendo saturación, es posible que sea del hosting, por que te ofrece muy pocos recursos o porque tiene unos limites muy bajos.
Evidentemente, mira si puede ser tambien el theme, ya que hace sus consultas.
Puedes ver las consultas que se realizan en cada pagina con Query Monitor: https://alvarofontela.com/query-monitor-solucionar-detectar-problemas-wordpress/
Gracias por responder Alvaro.
habia olvidado mencionar que no son querys , el processlist del mysql me arroja que es solo una conexion con tipo “sleep” mientras que los querys si se realizan y luego se cierran. Ahora puede que las conexiones “sleep” que se quedan abiertas sean “querys” realizados y se quedaron abiertos ? si esto es asi, talvez tenga un error con el theme. Cabe mencionar tambien que es un host alojado en mi NOC , es decir un server web local. Al probar subiendo el limite de las conexiones en Mysql , las conexiones abiertas subieron tambien, es decir consumio todo el recurso que le puse, si antes tenia 100 conexiones maximas , se saturaba, subia a 500 y consumia las 500, entonces sigo creyendo que tiene que ver con algun tema del WP , que aun desconozco. Utilice el Query Monitor para realizar mis pruebas donde mostraba querys lentas pero aun asi no me ayudó a solucionar el tema de porque se siguen generando mas y mas conexiones.
Saludos
Hola Angello, pues posiblemente el problema venga por algo de configuración o algo del WordPress, que no cierre las conexiones.
Esto no tiene porque ser de MySQL, normalmente el problema es de PHP: script o configuración del interprete o servidor web.
Un sysadmin habilidoso puede decirte que es exactamente lo que esta dejando abiertas esas conexiones.
Hola Alvaro,
Gracias nuevamente por las respuestas y el apoyo que brindas.
Después de seguir investigando aún no doy con la solución de porque el WP genera muchas conexiones y estas no se cierran, pero al no encontrar una solución encontre un control , por ahora eh coloado “max_users_conecctions” individuales para cada usario de cada bd de wp que manejo , asi evito que llegan al máximo permitido por mi MySql , si bien es cierto que cuando los limito y llegan a su tope , igual llega a tirar el error de “Error databa base connection” en los font end, pero el impacto es minimo a comparación de antes que tumbaba por varios minutos. Ahora las conexiones terminan de cerrarse despuesd eun tiempo y practicamente no se refleja de cara al cliente. Pues como mencione el impacto es minimo. Si alguien más tuviera mi mismo problema creo que este es un control muy útil por ahora, lo ideal seria encontrar la razon de porque las conexiones se generan una tras otra y cortar la raíz, pero hasta ubicar el problema esto me a ayudado bastante.
Gracias, Saludos
Hola Angello, como tu bien dices, el parámetro «max_users_conecctions» es un parche y no es escalable hacer crecer una web así ya que la tasa de error ira aumentando.
También podrías configurar el connect_timeout en un valor menor al prederminado.
Hola Álvaro! Gracias por todo lo que me has resuelto en varios artículos pero hoy a ver si me puedes ayudar con un problema que me ha surgido.
Tengo creado una especie de CRM en php a medida para la empresa de un amigo.
Eso ya está funcionando.
Tiene un WP con Woocommerce, activo y funcionando.
Ahora quisiera sacar datos de las tablas de WP y Woocommerce para que pueda usar las dos cosas a la vez, la idea es sincronizar las DB en su momento.
Soy incapaz de encontrar las tablas con los datos que introducen los clientes en el formulario al hacer la compra. (nombre, apellidos…) Los datos de pago no los necesito, pero el resto sí son vitales.
Al ver las 156 tablas en phpmyadmin y repasarlas no soy capaz de dar con ello, me puedes ayudar?
Muchas gracias de antemano y sigue así!!
Hola Carlos, te voy a dar una mala noticia.
Los pedidos son un custom-post mas de WordPress y se guarda en la tabla wp_posts igual que el resto de contenidos del sitio web.
Por si lo quieres buscar, el tipo de contenido es shop_order, pero ten en cuenta que habra datos en wp_posts y wp_postmeta.
Este tipo de sincronizaciones es mejor hacerla desde el REST API, ya que desde la DB de WordPress dudo que consigas sacar nada en limpio al haber tantos datos mezclados.
hola que tal alvaro, excelente los post, me puedes indicar en BD donde ubico a los vendedores de un producto woocommerce, ya se que el producto se encuentra en la tabla wp_posts y es de tipo (post_type=’product’).
Tengo una tienda multivendedores así que el vendedor no es único, asumí que el vendedor seria el mismo que publica el producto (post_author) y al ver la BD con phpmyadmin así pareciera asi que he realizado un canje en el ID, (Post_authors, guarda el ID del usuario [vendedor que postea en teoria]) por el ID de otro vendedor pero al mostrar el producto me sigue indicando que el vendedor es el antiguo.
Si me puedes dar luces de donde busco esa realcion (producto / vendedor) agradecido
Hola Andri, de forma nativa WooCommerce no tiene una estructura de datos para “Vendedores”, por lo que dependera de la forma de implementarlo.
Si tienes una tienda multivendedor, la forma de guardar esos vendedores intermedios va a depender del plugin con el que lo hagas, si usas Dokan por ejemplo, los vendedores son usuarios con un rol especifico.
Lo normal, es que siempre sean usuarios con un rol específico y usersmetas especificos, es decir, sin depender del post_author.
Se puede dar de altas de nuevos clientes en la base de wordpress por por algun webservise o similar? Gracias
Hola Selia, si, se puede hacer mediante el REST API de WordPress.
excelente articulo, alvaro. tengo un problema con un plug de transporte (shipping) que me ha llenado la lista de “Ubicaciones no cubiertas por tus otras zonas” en envios con mas de 400 entradas, esa list o puede ser removida desde el WP, hay que entrar y queiar uno por uno, un rollo por que por lo largo de esa lista (supongo) abrirla demora como 90 segundos y cada entrada borrada otra ves 90 seg, he tratado de borrar esos datos usan do sql , pero no logro encontrar datos o pistas que me permitan relacionar algo para encontrar esos registros y en que DB se encuentran. he borrado el plugin de trasnpote pero la lista permance, no pudo borar el woocomerce por que la tienda esta activa y cargada hasta arriba. si me puedes dar alguna pista te lo agradeceria
Hola Diego, te contesto en el comentario de abajo.
perdona una correccion , pero el problem esta en el plugin del transporte , al desactivarlo la lista de woocomm se limpia. el nombre del plugin es “Packlink PRO Shipping”
Conozco PackLink, y creo recordar, por si lo necesitas en otra ocasión, que los registros se guardan en wp_posts como si fuera un CPT más. Esto puede dificultar el borrado, la verdad… porque dentro de esta tabla está todo el contenido.
Hola Álvaro. Tengo un problema. Necesito cambiar en la base de datos LEFT JOIN por INNER JOIN para que la carga (el consumo) derivada de estas consultas no sea tan elevada. Soy un usuario básico y no sé cómo hacerlo. ¿Puedes ayudarme?
Hola Guillermo, lo siento, hace años que tire más por la rama empresarial y estoy muy oxidado en SQL. Pero puedes contactar con mis compañeros de Raiola Networks desde aquí: https://raiolanetworks.es/contacto/