Si necesitamos tener una consulta SQL en una base de datos MySQL y sacar por ejemplo todos los datos númericos de una columna, podemos hacerlo de la siguiente forma:
SELECT campos FROM tabla
WHERE columna REGEXP ‘^[0-9]+$’
De esta forma sacamos los registros de la tabla en los que columna solo contiene números.
Para acceder como usuario root a todas las bases de datos de un motor MySql dentro de plesk, lo podemos hacer de la siguiente forma, si tenemos acceso de root a una consola
mysql -uadmin -p`cat /etc/psa/.psa.shadow`
Si deseamos analizar el fichero de logs de mysql , lo primero que tenemos que tener es activado en el fichero de configuración my.cnf que guarde todas las consultas con un tiempo mayor al que quieras.
> vi /etc/my.cnf
log-slow-queries=/var/log/mysql-slow-queries.log
slow_query_log=1
long_query_time=3
#log-queries-not-using-indexes
Le hemos puesto que escriba todas las consultas que sobrepasen los 3 segundos. Podemos descomentar la ultima linea y también se escribirán las consultas con join de las tablas que no tengan indices declarados o no los tengan bien declarados. Podemos ver una configuración optima de my.cnf
Una vez reiniciemos el servicio de mysql, tendremos en la ruta determinada, el fichero de log a analizar.
> /etc/rc.d/init.d/mysqld restart
Para analizar el fichero de log de MySQL, tenemos el siguiente mysqldumpslow donde podemos saber todas las opciones que podemos sacar del fichero.
mysqldumpslow -s c -t 10 /var/log/mysql-slow-queries.log > /root/slowqueries.txt
En nuestro caso, sacamos las 10 consultas más lentas que tenemos, ordenadas por el numero de veces que se ha producido esta lentitud, y las metemos en un fichero para luego analizarlas. Tambien podriamos sacar esto por pantalla eliminando la ultima parte de la ruta.
Hace unos días tuvimos un corte de luz en nuestros servidores, y una tabla de la base de datos MySql quedo corrupta. Al intentar hacer una consulta sobre esa tabla, nos generaba el siguiente error de mysql:
Error Mysql 1030 Got error 134 from storage engine
Para solucionar esto, debemos reparar la tabla en cuestion ejecutando las siguientes consultas:
> check table NOMBRETABLA;
para ver los errores que tenemos en la tabla
> repair table NOMBRETABLA;
para solucionar los errores en esa tabla y dejar la tabla otra vez operativa.
Si queremos cambiar la contraseña de root en MAMP, podemos utilizar el siguiente comando en el terminal:
/Applications/MAMP/Library/bin/mysqladmin -u root -p password NUEVAPASS
Donde NUEVAPASS es la contraseña nueva que queramos poner.
Nos pide la contraseña antigua, y una vez metida, ya está hecho el cambio.
Si utilizamos en nuestras búsquedas MATCH AGAINST de MySQL, tenemos una limitación de 4 caracteres. Cualquier palabra menor a 4 caracteres no la encontrará.
Para modificar esta configuración, debemos abrir el fichero /etc/my.cnf
y añadir lo siguiente:
[mysqld]
ft_min_word_len=3
[myisamchk]
ft_min_word_len=3
guardamos el fichero y reiniciamos el servicio del mysql.
/etc/rc.d/init.d/mysqld restart
Una vez reiniciado el servicio de la base de datos MySQL, debemos reconstruir los indices FULLTEXT que tengamos en las tablas. Para ello modificar TABLA-BASEDEDATOS por cada una de las tablas en las que tengamos indices FULLTEXT.
La forma de realizarlo es:
repair table TABLA-BASEDEDATOS quick;
Si aparecen errores o avisos de numothersock en tu panel de virtuozzo … lo normal es leer la ayuda y ver que te sirve de poco ..
numothersock
The number of sockets other than TCP ones. Local (UNIX-domain) sockets are used for communications inside the system. UDP sockets are used, for example, for Domain Name Service (DNS) queries. UDP and other sockets may also be used in some very specialized applications (SNMP agents and others).
Puede que el problema sea del servidor de correo PostFix. En ese caso prueba a limitar los procesos de envio de postfix y ver si se resuelve el problema.
#postconf -e ‘default_process_limit=20’
#/usr/local/psa/admin/sbin/mailmng –reload-service
De esta forma, limitamos el numero de procesos de envio SMTP a 20, que por defecto en PostFix es 100, y eliminamos problemas de cuelgues y lentitud del servidor.
Muchas veces utilizamos para buscar algún campo String en una base de datos MySql, confirmamos con lower y trim para poner todo el texto en minúsculas y eliminar espacios en blanco, tanto el principio como al final del registro.
SELECT * FROM tabla WHERE lower(trim(email))=lower(trim(‘[email protected]’));
Eliminar esas funciones sql en MySql reduce la consulta en un 70% con un número alto de registros.
La mejor solución para esto es:
Es importante reducir el uso de CPU por parte de las consultas a base de datos, que es lo que nos puede retardar las respuestas al cliente. Como siempre hemos comentado, es muy importante optimizar las sentencias SQL para optimizar los tiempos de respuesta de la pagina web. Hay muchas cosas además de Indexar las tablas para optimizar una base de datos mysql.
Cuando hacemos una comparación de fechas en Mysql, es muy facil cometer un error que puede no verse reflejado en las pruebas que se hagan.
SELECT * FROM tabla WHERE fecha BETWEEN ‘2009-09-01’ AND ‘2009-09-30’ ;
Esta consulta algunas veces dará resultados válidos y otros invalidos. El problema es que si el campo fecha es un campo TIMESTAMP, no hace la comprobación unicamente por la fecha como nosotros queremos.
Para asegurarnos que hace la comparación unicamente con la fecha debemos añadir el comando DATE.
La consulta correcta sería :
SELECT * FROM tabla WHERE DATE(fecha) BETWEEN ‘2009-09-01’ AND ‘2009-09-30’ ;
Puede que necesitemos realizar un numrow de oracle en mysql. Es sencillo tratandolo como variables.
SELECT @rownum:=@rownum+1 AS rownum, aux.* FROM
(
SELECT *
FROM table
WHERE 1) aux, (SELECT @rownum:=0) r
Puedes emular la inicialización de la variable a 0 como si fuera una tabla auxiliar.