OVH Community, your new community space.

Ayuda con MySQL: insensibilidad a mayúsculas


MarcosBL
26/11/2010, 09:13
Orujo on the Top Power, apalabrado !

Lo de InnoDB vs MyISAM depende creo yo, más que del tamaño de tu BD, de las necesidades de cada caso:

- MyISAM realiza locks a nivel de toda la tabla, una query mal hecha puede dejar durante 5 minutos una tabla bloqueada, impidiendo el acceso de nadie a la web. Por contra, en velocidad, sobre todo ded lectura, MEA sobre InnoDB
- InnoDB realiza estos locks a nivel de registro, mucho más eficiente. Además dispone de varios mecanismos de recuperación ante desastres, binlogs, etc... sin embargo su velocidad es bastante menor...
- Luego estan los engines alternativos, como los basados en geolocalización, o SphinxSQL para búsquedas Full Text, etc... en cada caso, su engine.

Aunque es cierto lo que comentas, dev2k, que en InnoDB según crece el número de registros, la velocidad se mantiene estable, mientras que la de MyISAM va degradando poco a poco, no es menos cierto que esa degradación, si tenemos tablas bien diseñadas, y los índices adecuados, no la notaremos al menos hasta llegar a N millones de registros.

Por poner de muestra un botón, yo tengo una tabla en la que se escribe en batches un par de veces al dia, y que luego se utiliza mayormente como lectura. Debido a esto, decidí en su dia crearla sobre MyISAM, para optimizar al máximo los reads, y va ya por cerca de 12 millones de registros, realizando mis queries sobre ella siempre por debajo de 0.001 segundos, más que suficiente en mi caso.

No me enrollo más, simplemente comentar mi punto de vista, que no existe un engine MySQL "mejor", sino un engine MySQL "más adaptado a mi caso"

dev2k
25/11/2010, 23:15
Una nota, es más recomendable innoDB que MyISAM para estorage, sobre todo para bases de datos pesadas/conflictivas, el mysql responde bastante mejor

MySAM para bases de datos pequeñas (<1000 registros) tiene un acceso muy rapido y totalmente recomendable, pero conforme empieza a crecer el rendimiento de consulta se reduce segun porcenje de crecimiento.
Para estos casos es recomendable usar innoDB :_)

Power
25/11/2010, 22:08
Cita Publicado inicialmente por MarcosBL
Entre unos y otros, no vamos a dar ninguno a tomar cañitas entonces !
MarcosBL, tú puedes conmutar tus cañitas por ese orujo gallego de 65º del que tenemos noticias.

Saludos

MarcosBL
25/11/2010, 21:54
Entre unos y otros, no vamos a dar ninguno a tomar cañitas entonces !

Power
25/11/2010, 21:48
Hola,

Pues sí, debía estar bastante ceporro cuando hice las pruebas en el servidor de backup y creí ver que se comportaba sensible a las mayúsculas.
(O eso, o ha habido malvados espíritus binarios que han cambiado mi configuración)

Gracias a todos por ayudarme.
He aprendido algo nuevo (y muy útil), que no sabía.
Y da gusto sentirse tan arropado por los colegas cuando uno tiene problemas.

Ya sabéis que tenéis pagadas unas cervecitas cuando nos reunamos en el Congreso de Usuarios de OVH.

Saludos

MarcosBL
25/11/2010, 21:31
Me despistó el que dijera que en otro server iba bien, por eso tiré por el encoding de la conexión, pero si, como ya sabeis _ci es _case_insensitive

luis_sanz
25/11/2010, 20:43
gracias PacoSS, efectivamente _ci es lo que hace esto, y con tu aportacion lo he recordado, todo esto lo note hace tiempo cuando pase a usar como norma general utf8_general_ci, ahora recuerdo que fue ahi donde me di cuenta de que no funcionaban algunos scripts pero como no era nada serio preferi seguir con _ci y cambiar un par de consultas..

y power.. menudos sueños que tienes, yo en vez de soñar que mis DB furulan de lujo, sueño que estoy en el caribe con 4mulatas jejeje..
volviendo al tema, si no cambiaste eso te aseguro que es imposible que funcionara porque ya me volvi yo loco hace AÑOS y probando diferentes versiones de mysql hasta que me di cuenta que era eso

PacoSS
25/11/2010, 19:52
Ni gracias ni leches: paypal -> sueltalamosca@delacartera.com


Power
25/11/2010, 18:16
Hola,

¡¡¡ Acojo... , perdón, estupendísimo !!!.

Y yo que por más vueltas que le había dado al manual no había encontrado esa tabla con la explicación tan sencilla. ¡¡¡ Seré burro !!!

Está claro. Estoy utilizando latin1_swedish_ci que es insensible a mayúsculas.
Y que antes me reconocía mayúsculas y minúsculas debo haberlo soñado.
(Alguna prueba errónea que dí por buena)

Muchas gracias PacoSS por tan valiosa ayuda.

Saludos

PacoSS
25/11/2010, 17:36
nO HAy dE qUe.

Mira que me he encontrado en el manual de mysql:

---8<-------8<-------8<-------8<-------8<-------8<-------8<-------8<----

mysql> SHOW COLLATION LIKE 'latin1%';
+---------------------+---------+----+---------+----------+---------+
| Collation | Charset | Id | Default | Compiled | Sortlen |
+---------------------+---------+----+---------+----------+---------+
| latin1_german1_ci | latin1 | 5 | | | 0 |
| latin1_swedish_ci | latin1 | 8 | Yes | Yes | 1 |
| latin1_danish_ci | latin1 | 15 | | | 0 |
| latin1_german2_ci | latin1 | 31 | | Yes | 2 |
| latin1_bin | latin1 | 47 | | Yes | 1 |
| latin1_general_ci | latin1 | 48 | | | 0 |
| latin1_general_cs | latin1 | 49 | | | 0 |
| latin1_spanish_ci | latin1 | 94 | | | 0 |
+---------------------+---------+----+---------+----------+---------+

Las colaciones para latin1 tienen los siguientes significados:
Colación Significado
latin1_german1_ci Alemán DIN-1
latin1_swedish_ci Sueco/Finlandés
latin1_danish_ci Danés/Noruego
latin1_german2_ci Alemán DIN-2
latin1_bin Binario según codificación latin1
latin1_general_ci Multilingüe (Europa Occidental)
latin1_general_cs Multilingüe (ISO Europa Occidental), sensible a mayúsculas
latin1_spanish_ci Español moderno

Las colaciones tienen las siguientes características generales:

*

Dos conjuntos de caracteres distintos no pueden tener la misma colación.
*

Cada conjunto de caracteres tiene una colación que es la colación por defecto. Por ejemplo, la colación por defecto para latin1 es latin1_swedish_ci.
*

Hay una convención para nombres de colaciones: empiezan con el nombre del conjunto de caracteres al que están asociados, normalmente incluyen el nombre del idioma, y acaban con _ci (no distingue entre mayúsculas y minúsculas), _cs (distingue entre mayúsculas y minúsculas), o _bin (binario).
---8<-------8<-------8<-------8<-------8<-------8<-------8<-------8<----

¿Tu como andas de colaciones?

Power
25/11/2010, 17:14
Hola,
Cita Publicado inicialmente por PacoSS
...uno que quería lo contrario, o sea, lo que tu tienes.
Pues tendré que cambiarle el servidor

Cita Publicado inicialmente por PacoSS
Mira a ver que tipo de índice tienes en esa base de datos sobre ese campo.
Para ese tipo de campos uso índices simples tipo INDEX, e incluso en tablas diminutas no utlizo índices.

Gracias PacoSS por interesarte en mi problema.

Saludos

PacoSS
25/11/2010, 16:42
Googleando un poco, me he encontrado uno que quería lo contrario, o sea, lo que tu tienes.
Un gurú le contesta seco y tajante: "con un indice fulltext te evitarias problemas (si trabajas en myisam)"

Mira a ver que tipo de índice tienes en esa base de datos sobre ese campo.

Power
25/11/2010, 15:12
Hola Luis_sanz,

Muchas gracias por tu aportación.

He probado la query que propones con tildes y, efectivamente ¡¡ he flipado !!
Parece que traga mayúsculas, minúsculas, letras acentuadas y hasta fideos de sobre.

Pero no entiendo como ocurre porque hasta hace poco, creo que no me ocurría. ¿O lo habré soñado?

Lo peor es que no puedo ponerme a cambiar un montón de scripts que tengo instalados en diversas webs del servidor y que se utilizan para identificar usuario y contraseña de entrada en aplicaciones.

Y los cambios de pruebas de collation me dan pavor.
Tuve malas experiencias en el pasado jugando con ese tema.
Ahora prefiero dejar la que viene por defecto.

Saludos

luis_sanz
25/11/2010, 14:49
HOLA POWER

si eso te parece raro prueba con esta busqueda
Código:
SELECT * FROM usuarios WHERE usuario = 'Pépé'
jejej.. vas a quedar mas flipao aun

el caso es que no se porq pasa esto y tampoco es que me importe, porque no hago busquedas de este tipo, pero creo que esta directamente influido por la codificacion de caracteres de la DB.. miralo por ahi.

PD.. por si no quedo claro, a mi tambien me pasa

Power
25/11/2010, 10:57
Hola,

Asombrosamente, en el servidor de backup, ahora
Código:
SELECT * FROM usuarios WHERE usuario = 'Pepe'
Responde con datos independientemente de que se ponga Pepe, pEPE o pepe.
Ahora opera como el servidor principal (mal).

Todas las bases de datos del servidor principal están replicadas en el servidor backup (incluida la BD mysql).
Parece que se hubiese "contagiado".

Pues no sé que hacer porque antes funcionaba todo correctamente y no era lo mismo el usuario Pepe que el usuario pepe.
(Y esto es más grave en el tema de passwords).

¿Alguien más puede ayudarme?
Gracias.

Saludos

Power
25/11/2010, 10:35
Hola,

Gracias MarcosBL por echarme una mano.
(Estoy bastante desesperado con el tema)

Código:
select 'A' like 'a'
Devuelve 1 en ambos servidores.
(Es normal, porque like es una comparación insensible a mayúsculas).

Código:
select 'A' = 'a'
Sorprendentemente, en ambos servidores devuelve 1.

Código:
select 'A' like binary 'a'
Responde 0 en ambos servidores.

Y la variable collation-server tiene el valor latin1_swedish_ci en ambos servidores.

No sé por donde tirar, ya que ambos servidores MySQL parecen casi iguales (a excepción de la versión).

Help !!!!!!

Saludos

MarcosBL
25/11/2010, 09:40
¿ Qué te devuelven estas consultas en ambas máquinas?

// Debería devolver true según comentas
select 'A' like 'a'
// Debería devolver false independientemente de la configuración del servidor
select 'A' like binary 'a'
Prueba también a introducir en tu fichero de configuración (y reiniciar MySQL):
collation-server = utf8_bin
Más info: http://dev.mysql.com/doc/refman/4.1/...binary-op.html

Power
24/11/2010, 23:49
Hola,

Al supervisar unos scripts de PHP acabo de darme cuenta de que el MySQL de mi servidor principal es insensible a mayúsculas/minúsculas.

Ejemplo:
Código:
SELECT * FROM usuarios WHERE usuario = 'Pepe'
Me selecciona el mismo registro independientemente de que ponga Pepe, pepe, PEPE o PePe.

He comparado con mi servidor backup y en éste no ocurre.

La versión del Mysql de mi servidor principal es 5.1.51 y la de mi servidor backup es 5.1.53

He comparado las variables de ambos servidores que podrían tener relación con este problema (character..., collation...) y no encuentro diferencias entre ambos.

He buscado en los manuales de MySQL y tampoco encuentro explicación.

¿Podríais echarme una mano?
Gracias anticipadas.

Saludos