Blog de David Rodriguez

Internet, tecnologia, programacion, SEO

Optimizacion de consultas sql con lower y trim

Febrero 19th, 2010 by David Rodriguez

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(‘emaildeprueba@prueba.com’));

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:

  1. Introducir los datos con esas opciones ya realizadas. Facilmente en php o cualquier otro lenguaje de programación podemos realizar estas funciones, con un uso de máquina mucho menor.
    $email = strtolower(trim($email));
  2. actualizar todos los datos de la tabla para no tener estos problemas en un futuro
    UPDATE tabla SET email=lower(trim(email));
  3. Ya se puede eliminar estas funciones de la consulta(query).
    SELECT * FROM tabla WHERE email=’emaildeprueba@prueba.com’;

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.

Category: Base de datos, Internet, Programacion | No Comments »

Error muy comun con between en mysql

Septiembre 25th, 2009 by David Rodriguez

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′ ;

Category: Base de datos, Internet | 2 Comments »

rownum en mysql. numero de lineas por consulta

Septiembre 11th, 2009 by David Rodriguez

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.

Category: Base de datos | No Comments »

Optimizacion de mysql con el fichero my.cnf

Marzo 26th, 2009 by David Rodriguez

Cuando un proyecto empieza a tener consistencia y a tener un numero alto de visitas, lo más normal es que la base de datos empieza a ralentizarse.

Para ello, como siempre hemos dicho, lo más importante es optimizar las consultas sql, que siempre se puede optimizar para un mejor aprovechamiento del tiempo de cpu usado por mysql.

Una vez hecho esto, hay que tomar ciertas medidas en la configuración de mysql para optimizar este motor de base de datos. Por defecto, no se aprovecha todo el potencial que tiene y según vamos necesitando, se debe modificar para optimizar este punto tambien.

Os adjunto el fichero my.cnf o my.conf que suele estár en /etc para optimizar vuestro mysql.

# Example MySQL config file for very large systems.
#
# This is for a large system with memory of 1G-2G where the system runs mainly
# MySQL.
#
# You can copy this file to
# /etc/my.cnf to set global options,
# mysql-data-dir/my.cnf to set server-specific options (in this
# installation this directory is /var/lib/mysql) or
# ~/.my.cnf to set user-specific options.
#
# In this file, you can use all long options that a program supports.
# If you want to know which options a program supports, run the program
# with the “–help” option.

# The following options will be passed to all MySQL clients
[client]
#password    = your_password
port        = 3306
socket        = /var/lib/mysql/mysql.sock

# Here follows entries for some specific programs

# The MySQL server
[mysqld]
port        = 3306
socket        = /var/lib/mysql/mysql.sock
skip-locking
key_buffer = 384M
#ax_allowed_packet = 1M
table_cache = 512
sort_buffer_size = 2M
read_buffer_size = 2M
read_rnd_buffer_size = 8M
myisam_sort_buffer_size = 64M
thread_cache_size = 8
query_cache_size = 32M

# custom
old_passwords=1
log-slow-queries=/var/log/mysql-slow-queries.log
log-error=/var/log/mysqld.log
#set-variable = max_connections=500
max_connections = 512
wait_timeout = 15
max_user_connections = 200
max_allowed_packet = 16M
max_connect_errors = 200

# Try number of CPU’s*2 for thread_concurrency
thread_concurrency = 8

# Don’t listen on a TCP/IP port at all. This can be a security enhancement,
# if all processes that need to connect to mysqld run on the same host.
# All interaction with mysqld must be made via Unix sockets or named pipes.
# Note that using this option without enabling named pipes on Windows
# (via the “enable-named-pipe” option) will render mysqld useless!
#
#skip-networking

# Replication Master Server (default)
# binary logging is required for replication
log-bin

# required unique id between 1 and 2^32 – 1
# defaults to 1 if master-host is not set
# but will not function as a master if omitted
server-id    = 1

# Replication Slave (comment out master section to use this)
#
# To configure this host as a replication slave, you can choose between
# two methods :
#
# 1) Use the CHANGE MASTER TO command (fully described in our manual) -
#    the syntax is:
#
#    CHANGE MASTER TO MASTER_HOST=<host>, MASTER_PORT=<port>,
#    MASTER_USER=<user>, MASTER_PASSWORD=<password> ;
#
#    where you replace <host>, <user>, <password> by quoted strings and
#    <port> by the master’s port number (3306 by default).
#
#    Example:
#
#    CHANGE MASTER TO MASTER_HOST=’125.564.12.1′, MASTER_PORT=3306,
#    MASTER_USER=’joe’, MASTER_PASSWORD=’secret’;
#
# OR
#
# 2) Set the variables below. However, in case you choose this method, then
#    start replication for the first time (even unsuccessfully, for example
#    if you mistyped the password in master-password and the slave fails to
#    connect), the slave will create a master.info file, and any later
#    change in this file to the variables’ values below will be ignored and
#    overridden by the content of the master.info file, unless you shutdown
#    the slave server, delete master.info and restart the slaver server.
#    For that reason, you may want to leave the lines below untouched
#    (commented) and instead use CHANGE MASTER TO (see above)
#
# required unique id between 2 and 2^32 – 1
# (and different from the master)
# defaults to 2 if master-host is set
# but will not function as a slave if omitted
#server-id       = 2
#
# The replication master for this slave – required
#master-host     =   <hostname>
#
# The username the slave will use for authentication when connecting
# to the master – required
#master-user     =   <username>
#
# The password the slave will authenticate with when connecting to
# the master – required
#master-password =   <password>
#
# The port the master is listening on.
# optional – defaults to 3306
#master-port     =  <port>
#
# binary logging – not required for slaves, but recommended
#log-bin

# Point the following paths to different dedicated disks
#tmpdir        = /tmp/
#log-update     = /path-to-dedicated-directory/hostname

# Uncomment the following if you are using BDB tables
#bdb_cache_size = 384M
#bdb_max_lock = 100000

# Uncomment the following if you are using InnoDB tables
#innodb_data_home_dir = /var/lib/mysql/
#innodb_data_file_path = ibdata1:2000M;ibdata2:10M:autoextend
#innodb_log_group_home_dir = /var/lib/mysql/
#innodb_log_arch_dir = /var/lib/mysql/
# You can set .._buffer_pool_size up to 50 – 80 %
# of RAM but beware of setting memory usage too high
#innodb_buffer_pool_size = 384M
innodb_buffer_pool_size = 1024M
innodb_additional_mem_pool_size = 20M
# Set .._log_file_size to 25 % of buffer pool size
#innodb_log_file_size = 100M
innodb_log_buffer_size = 8M
innodb_flush_log_at_trx_commit = 1
innodb_lock_wait_timeout = 50

[mysqldump]
quick
max_allowed_packet = 16M

[mysql]
no-auto-rehash
# Remove the next comment character if you are not familiar with SQL
#safe-updates

[isamchk]
key_buffer = 256M
sort_buffer_size = 256M
read_buffer = 2M
write_buffer = 2M

[myisamchk]
key_buffer = 256M
sort_buffer_size = 256M
read_buffer = 2M
write_buffer = 2M

[mysqlhotcopy]
interactive-timeout

Realizar una copia del fichero antiguo:

cp /etc/my.cnf /etc/my.cnf.back

modificar el fichero my.cnf con por el que os he puesto

y reiniciar la base de datos

/etc/rc.d/init.d/mysqld restart

Si todo va ok, tendreis vuestro motor de base de datos mysql mucho mas optimizado.

Category: Base de datos, Programacion | 1 Comment »

muchos procesos mysql unauthenticated user

Marzo 18th, 2009 by David Rodriguez

Llevamos unos días con ciertos problemas en el servidor. Nuestra arquitectura de servidores, tenemos un servidor web para las páginas, y un servidor web para la base de datos.

Encontrabamos problemas en el servidor de base de datos, ya que aunque no habia problemas con los procesos, realizando un “top” nos encontrabamos con menos de 5% de uso de cpu.

Entrando a ver los procesos de la base de datos, encontrabamos muchos procesos con “unauthenticated user” que se iban encolando y esto hacia que no llegaran a ejecutarse, antes de que saltara el timeout.

Buscamos a ver si había alguna sentencia que pudiera ralentizar el resto de peticiones, pero eso no pasaba, es decir, no habia ninguna petición que bloqueara al resto de sentencias.

Tras varios dias volviendonos locos, encontramos este post en este blog de dante robles en el cual nos ha dado la solución.

Simplemente hemos introducido en el fichero /etc/hosts los dominios y la ip desde la cual se realizan las peticiones a esta base de datos … y asunto concluido!!!!!

como algo tan sencillo te puede hacer perder tanto tiempo ….. es lo que nos pasa por no conocer como funciona mysql.

Entiendo ahora, que cuando a mysql le llega una petición, este transforma la dns en la ip, para comprobar si permite acceder al host a su base de datos, y esto es lo que estaba retardando la entrada de las siguientes peticiones.

Espero que la gente no pierda tiempo con este “problema”.

Category: Base de datos, Programacion | 1 Comment »

error distinct en mysql. error comun

Octubre 22nd, 2008 by David Rodriguez

Hay un error muy común que se nos pasa de la mente cuando utilizamos DISTINCT  en una sentencia SQL. Y es el simple hecho que DISTINCT debe ir al principio de la sentencia SQL. Es decir.SELECT DISTINCT email, nombre, apellidos FROM usuarios –> CorrectoSELECT nombre, DISTINCT email, apellidos FROM usuarios –> Incorrecto Espero que una cosa tan simple como esta, no os haga perder ni un minuto de tiempo viendo de donde viene el error. 

Category: Base de datos | No Comments »

Diferencias entre truncate y delete en mysql

Septiembre 29th, 2008 by David Rodriguez

Si os habeis preguntado alguna vez la diferencias entre truncate y delete en la base de datos mysql … aqui os pongo una pequeña explicación de cuando utilizar una u otra.

TRUNCATE

Este comando borra todas las filas de una tabla sin registrar las eliminaciones individuales en el log de transacciones.

Por ejemplo:

TRUNCATE Cursos;

Borra todos los registros de la tabla Cursos

DELETE

DELETE borra las filas de una tabla, pero registra las eliminaciones individuales en el log de transacciones. Podemos utilizar la clausula WHERE para filtrar las filas que necesitemos eliminar.

Ejemplo:

DELETE FROM Cursos  WHERE CursoId = 50;

DIFERENCIAS ENTRE TRUNCATE Y DELETE

- Ambas eliminan los datos, no la estructura.
- Solo DELETE permite la eliminación condicional de los registros.
- DELETE es una operación registrada en el log de transacciones y trucate no.
- TRUNCATE es una operación registrada en el log de transacciones, pero como un todo, en conjunto, no por eliminación individual. TRUNCATE se registra como una liberación de las páginas de datos en las cuales existen los datos.
- TRUNCATE es más rápida que DELETE.
- Ambas se pueden deshacer con un ROLLBACK.
- TRUNCATE reiniciará el contador para una tabla que contenga una columna IDENTITY.
- DELETE mantendrá el contador de la tabla para una columna IDENTITY.
- TRUNCATE es un comando DDL(lenguaje de definición de datos) mientras que DELETE es un DML(lenguaje de manipulación de datos).
- TRUNCATE no desencadena un TRIGGER, DELETE sí.

- TRUNCATE recrea una tabla.

CUANDO USARLAS

- Usar Truncate es más rapido que Delete si vas a borrar toda una tabla y no te importan los indices(identity) o bien quieres resetearlos.

- Usar Delete para borrados selectivos.

- Usar Delete en caso de tener Foreign Key, es decir .. usarla en caso de borrados en cascada.

Category: Base de datos | No Comments »