Tag: Mysql (page 1) - Userlinux.net

Al hilo del anterior post donde intentamos salvar la prematura muerte de MySQL en manos de Oracle, la respuesta ha sido -creo yo- rotunda y en forma de comunicado de prensa. Oracle afirma:

• Asegurar la disponibilidad de las APIs de las máquinas de almacenamiento.
• Continuar mejorando MySQL en el futuro bajo la GPL, incluyendo a su versión 6.
• Invertir más en el desarrollo de MySQL de lo que lo hizo Sun en el último año fiscal (U$S 24 Millones).
• No requerir que los clientes contraten los servicios de soporte de Oracle para obtener una licencia comercial de MySQL.
• Fundar un Consejo Asesor constituído por clientes y usuarios para que ayuden a dirigir las prioridades del desarrollo de MySQL.

Espero que sea suficiente, que quede constancia del comunicado y que jamás tengamos que volver a leerlo ;). (Gracias a David por el comentario).

Comando del día. Hace nada me pidieron un backup de una tabla de MySQL y sentí la necesidad de hacerlo en una linea (obviamente, tras 3 pruebas). Si, sé que es una tontería pero tuvo su gracia. Vamos al lío.

Para empezar no sabía si se podía hacer un dumpeo con mysqldump de una tabla en concreto, siempre lo había usado para bases de datos completas pero man me lo dejó muy claro: si después de la base de datos especificas una tabla lo haré encantado.

Por exigencia del guión, cuando conectas con Sphinx para hacer una búsqueda, éste devuelve los id's de los resultados coincidentes ordenados por relevancia (al menos en nuestro caso, que usamos el método SetFieldWeights).

[matches] => Array
(
 [100] => Array ( [weight] => 100 )
 [50]  => Array ( [weight] => 70 )
 [200] => Array ( [weight] => 30 )
 [30]  => Array ( [weight] => 30 )
)

La pregunta es, ¿cómo hacer que MySQL respete ese mismo orden?. Vamos, que si tenemos un "SELECT * FROM productos WHERE id IN (100, 50, 200, 30)" y queremos los resultados justamente en ese orden (100, 50, 200 y 30) tendremos que indicarlo en MySQL de alguna forma, puesto que por defecto (al menos en nuestras pruebas / instalaciones) ordena por la primary key...

Cuando queremos matar de forma masiva conexiones de MySQL podemos ejecutar una query como la que sigue:

mysql> SELECT concat('KILL ',id,';') FROM information_schema.processlist WHERE user='root';
+------------------------+
| concat('KILL ',id,';') 
+------------------------+
| KILL 3101;			 
| KILL 2946;			 
+------------------------+
2 rows IN SET (0.00 sec)
mysql> SELECT concat('KILL ',id,';') FROM information_schema.processlist WHERE user='root' INTO OUTFILE '/tmp/a.txt';
Query OK, 2 rows affected (0.00 sec)
mysql> source /tmp/a.txt;
Query OK, 0 rows affected (0.00 sec)

Fulminado de MySQL Performance Blog.

Para almacenar una cadena en MySQL podemos utilizar varios tipos de campo, como nunca recuerdo la diferencia entre los normales, los medium y los long, ahí queda la nota mental:

• Char: 0-255 caracteres.
• Varchar: 0-255 caracteres.
• Tinytext: 0-255 caracteres.
• Text: 65.535 caracteres.
• Mediumtext: 16.777.215 caracteres.
• Longtext: 4.294.967.295 caracteres.

Si, nos ha extrañado, pero los campos de tipo mediumtext albergan más cantidad de datos que los text. Fin de la nota mental.

Update: A raíz del comentario de Wu me gustaría aclarar que la diferencia entre CHAR y VARCHAR es la forma en la que se almacenan los datos en MySQL. Por ejemplo entre un CHAR(4) y un VARCHAR(4) guardando el dato "ab" tendríamos que:

CHAR(4)	"ab  "
VARCHAR(4)	"ab"

Como vemos en los campos de tipo CHAR siempre se reserva el espacio que hemos designado para su uso, mientras que en los VARCHAR la asignación es dinámica siempre y cuando no se sobrepase el límite impuesto.

El TINYTEXT, junto a sus hermanos TEXT, MEDIUMTEXT y LONGTEXT son de tipo BLOB (binary large object) y su almacenamiento es distinto a CHAR ó VARCHAR.