El error al completo es: “Cannot load from mysql.proc. The table is probably corrupted” y la verdad que no es un error menor porque básicamente no puedes hacer ni consultas de cierto tipo con MySQL/MariaDB.
Por lo general, en un servidor que tengas instalado este sistema gestor de base de datos, MySQL o su alternativa libre MariaDB, en ciertas actualizaciones de versión de este software, luego tienes que reconfigurar ciertos datos internos de gestión de la base de datos.
Como veis la idea es la siguiente:
El problema que tiene este método es que phpMyAdmin tiene que ser subido/bajado repetidas veces y para que os hagáis una idea de su peso, la versión actual ocupa un total de 27,4 MB siendo 1.538 archivos si tenéis que hacer esta subida por FTP y con una línea ADSL… vais a perder mucho tiempo.
La solución: aligerar lo que no es necesario
Si entráis dentro del paquete que se descarga veréis que hay algunas carpetas que no son necesarias y que tienen bastante peso, ¿de cuáles os hablo?
Tras borrar estas carpetas, volvemos a ver cuánto peso queda y tenemos que se ha reducido a prácticamente la mitad: 14,2MB aunque el número de archivos no lo ha hecho en la misma medida, 1.399 archivos.
Seguro que te ha salido alguna vez este error y aunque sabías que no era importante, querías arreglarlo: Arreglar el error de Apache2 “Could not reliably determine the server’s fully qualified domain name, using 127.0.0.1 for ServerName” – Desde Linux
Porque con WordPress ya digo que puedes hacer prácticamente de todo, un ejemplo más: Cómo ofrecer contenidos premium en WordPress sin complicaciones – Ayuda WordPress
Si manejas a diario MySQL, habrá veces que necesites ver quién está consumiendo sus recursos, para ello nada mejor que: Aplicaciones en terminal para revisar el rendimiento de MySQL – Desde Linux
81 líneas de código Python para lanzar un navegador con una interfaz gráfica de usuario decente, sé que es mérito de las librerías que usa, pero no deja de ser muy interesante: Sencillo navegador de sólo 81 líneas de código – Ubuntizando el planeta
Los comentarios en muchas ocasiones aportan más información que las propias entradas en un blog así que hay que saber cómo manejarlos para que tu público quiera interactuar más, una posibilidad es esta: Cómo destacar y enterrar comentarios – Ayuda WordPress
El que para mí es juego por definición de Linux porque fue el primero que disfruté: SuperTux:
El SuperMario de Linux – Desde Linux
Una de las características que debe tener todo modelo relacional medianamente serio, es el uso de claves foráneas que deben ir especificadas en la construcción de las diferentes tablas de forma que conozcan que campos hacen referencia a qué otros campos. Esto con InnoDB es perfectamente posible en MySQL.
Aquí tenéis la documentación y un ejemplo de cómo crear restricciones de clave foránea de MySQL:
CREATE TABLE padre(
id INT NOT NULL,
PRIMARY KEY (id)
) ENGINE=INNODB;
CREATE TABLE hijo(
id INT,
id_padre INT,
INDEX par_ind (id_padre),
FOREIGN KEY (id_padre)
REFERENCES padre(id)
ON DELETE CASCADE
) ENGINE=INNODB;El ejemplo es sencillo pero a la vez muy común, es muy frecuente tener una tabla hija que haga referencia al id de su tabla padre: por ejemplo el típico ejemplo de factura y línea factura.
Error: Can’t create table ‘xxx’ (errno: 150)
Haciendo algo similar a esto, esta mañana he sufrido un error (el del título) que nunca antes me había pasado. He empezado a comprobar y tras dar muchas vueltas he dado con el fallo: los dos tipos de datos deben ser idénticos.
Y cuando idénticos digo: mismo tipo de datos, misma longitud, signed o unsigned los dos, si es not null igual el otro.
Esto es lo lógico pero a mí se me había escapado un detalle, uno era signed y el otro unsigned y he perdido unos minutos hasta dar con el error (tras la primera y típica reacción “será problema de MySQL”).
Cuando trabajamos con bases de datos, normalmente tendremos casos en los que existan valores nulos tanto en nuestras tablas como en el resultado de nuestras consultas. Sin embargo, esta realidad, también provoca que algunas acciones como las ordenaciones sean problemáticas. Para poder superar estas dificultades disponemos de funciones como coalesce() (buscad dentro del enlace).La función coalesce()
¿Qué hace esta función? Recibe una serie de parámetros y devuelve el primero que no es nulo.
Forma de uso
Por lo tanto, si tenemos una columna edad, por ejemplo, que puede ser nulo o no serlo, y ponemos:
COALESCE(edad, 0) esta función devolverá la edad si no es nula y si es nula, el primer valor no nulo de la lista de parámetros, como sólo hay dos parámetros, será el siguiente, 0.
Ordenando con valores nulos
Siguiendo este ejemplo podríamos hacer una ordenación a nuestro antojo, es decir, si queremos ordenar primero las fechas de los más mayores, es decir, en sentido descendente y poner al final los valores nulos, podríamos hacer justo:
SELECT nombre, apellidos FROM personas ORDER BY (edad, 0)
USE mi_base_de_datos
O con el lenguaje que estemos usando la elegimos y trabajamos sobre ella o como mucho haciendo consultas entre varias bases de datos.
Sin embargo, hoy trabajando en un proyecto que estoy haciendo para un cliente de CODECTION, he tenido la necesidad de listar y operar sobre los nombres de las tablas de una base de datos. ¿Cómo lo he hecho?
SHOW FULL TABLES FROM mi_base_de_datos
Y obtenéis un listado de todas las tablas que hay en esa base de datos.
De hecho, podéis hacer consultas del tipo:
SHOW FULL TABLES FROM mi_base_de_datos LIKE '%busqueda%'
Así tenéis una más herramientas todavía para trabajar con nuestra querida MySQL.
Las taxonomías por defecto son dos, que aunque internamente se implementan igual, externamente funcionan de forma diferente. Las categorías actúan comos los capítulos de un libro, como la tabla de contenido inicial, partiendo el contenido del blog en temáticas y las etiquetas actúan como el índice final donde se referencias temáticas de forma cruzada, el llamado índice de palabras (que dan lugar a nubes de etiquetas similares a las que os muestro a continuación).
Si manejáis otro tipo de datos, podéis crear vuestras propias taxonomías y así personalizar al máximo esta potencialidad para conseguir que WordPress sea una auténtica plataforma para desarrollar aplicaciones web.
Por cualquier razón, podéis queréis tener una lista de tipo <select><option> en HTML de las categorías, podéis usar las siguientes funciones que he creado y que uso para esto mismo:
function get_list_categories(){
return get_list_subcategories(0);
}
function get_list_subcategories($parent){
$result = "";
$args = array(
'taxonomy' => "category",
'parent' => $parent,
'hide_empty' => 0
);
$categories = get_categories($args);
foreach($categories as $category)
$result .= '<option value="'.$category->cat_ID.'">' . $category->cat_name . '</option>';
return $result;
}Si tenéis dudas preguntadme pero básicamente hay dos llamadas:
Internamente básicamente tiene funcionalidad la segunda función y hace una llamada a la función de la API
get_categories
Hace unos días hablamos de cómo activar la caché de MySQL. Espero que la hayáis probado y que hayáis visto cómo vuestros tiempo de consulta se reducen considerablemente con sólo activarla. Os dije que os comentaría cómo monitorizarla y de esa promesa, esta entrada.Soy de los que dice que algo por bien que funcione, si no puede medirse, no funciona tan bien. Las sensaciones son esos y aunque veamos que el tiempo de ejecución ha caído, no sabemos nada sobre la caché. Todos los que hayáis estudiado algo relacionado con la informática, conoceréis conceptos como la tasa de fallos y de aciertos de cualquier caché y ésta, no podía ser menos.
¿Cómo podemos ver esos datos? Veamos.
Comprobar si la caché está activada
Para esta labor usaremos el siguiente comando (siempre desde la consola de MySQL):
SHOW VARIABLES LIKE 'have_query_cache';
Que nos devolverá si está activada lo siguiente:
+------------------+-------+ | Variable_name | Value | +------------------+-------+ | have_query_cache | YES | +------------------+-------+
Parámetros de estado
Para ver todos los parámetros del estado de la caché, una vez sabemos que está activada hacemos:
SHOW STATUS LIKE 'Qcache%';
Y el resultado es el siguiente:
+-------------------------+-----------+
| Variable_name | Value |
+-------------------------+-----------+
| Qcache_free_blocks | 3409 |
| Qcache_free_memory | 501720656 |
| Qcache_hits | 3265000 |
| Qcache_inserts | 1321208 |
| Qcache_lowmem_prunes | 0 |
| Qcache_not_cached | 72160 |
| Qcache_queries_in_cache | 10027 |
| Qcache_total_blocks | 24143 |
+-------------------------+-----------+
¿Cómo saber desde la consola de MySQL esta información? Con la siguiente orden, fijaos que el DESCRIBE TABLE no ofrece esta información, sólo la información referente al tipo de dato de cada columna, así que tenemos que usar:
SHOW TABLE STATUS WHERE Name = 'nombre_tabla'
