Desventajas de citar enteros en una consulta Mysql?

Tengo curiosidad por la desventaja de citar los números enteros en MySQL consultasDesventajas de citar enteros en una consulta Mysql?

Por ejemplo

SELECT col1,col2,col3 FROM table WHERE col1='3';

SELECT col1,col2,col3 FROM table WHERE col1= 3;

Si hay un costo de rendimiento, ¿cuál es el tamaño de la misma y por qué ocurre? ¿Hay alguna otra desventaja aparte de ese rendimiento?

Gracias Andrew

Editar: La razón de esta pregunta
1. Porque quiero aprender la diferencia porque soy curiosa
2. Estoy experimentando con una forma de pasar las claves compuestas de mi base de datos en mi código php como psudo-Id-keys (PIK). Estos PIK son los utilizados para apuntar al registro. Por ejemplo, dada una clave principal (AreaCode, Categoría, RecordDtm)

Mi PIK en la url se vería así:

index.php?action=hello&Id=20001,trvl,2010:10:10 17:10:45

Y yo seleccionaría este registro así:

$Id = $_POST['Id'];//equals 20001,trvl,2010:10:10 17:10:45 
$sql = "SELECT AreaCode,Category,RecordDtm,OtherColumns.... FROM table WHERE (AreaCode,Category,RecordDtm) = ({$Id}); 
$mysqli->query($sql): 
......and so on.

En este punto, la consulta no funcionará debido a la fecha y hora (que debe citarse) y está abierta a la inyección sql porque no he escapado de esos valores. Dado el hecho de que no siempre sabré cómo se construyen mis PIK, escribiría una función que divide el Id PIK en las comas, limpia cada parte con real_escape_string y la vuelve a juntar con los valores citados. Por ejemplo: $ Id = "'20001', 'trvl', '2010: 10: 10 17:10:45'" Por supuesto, en esta función que se está rompiendo y limpiando el Id podría verificar si el valor es un número o no. Si es un número, no lo cites. Si es algo más que una cadena, cítelo.

Fuente

2011-02-07 andrew

¿Por qué no hacer siempre lo correcto en lugar de preocuparse por el rendimiento de tener el analizador de consultas corregir sus errores? –

¿Por qué no siempre se apega a * algo * en lugar de preocuparse por optimizaciones prematuras? – strager

Porque quiero aprender un poco más acerca de por qué no siempre ponemos comillas alrededor de todos los valores en las consultas. Estoy experimentando con una manera de pasar las claves compuestas de la base de datos como ID de un solo psudo en el código php. – andrew

-1

Have a look at this. Hicieron algunas evaluaciones de rendimiento entre diferentes tipos de campos.

Fuente

2011-02-07 06:16:35

Eso es tipos de datos, no conversión implícita. En segundo lugar, los tamaños de tipos de datos son diferentes: VARCHAR (4) toma la misma cantidad de bytes que INT. –

De acuerdo a mí, creo que no hay costo de rendimiento/tamaño en el caso que ha mencionado. Incluso si lo hay, entonces es muy insignificante y no afectará su aplicación como tal.

Fuente

2011-02-07 06:18:27

Sí, pero por supuesto este es un ejemplo simplificado. No tengo una sola consulta, que es así de simple. Creo que @Chris Henry explica bien el hecho de que en una consulta más compleja causaría un problema de rendimiento. – andrew

@Andrew - @Chris explica la sobrecarga de rendimiento en combinación con Joins, que es correcta. Pero en el caso de que solo sea la conversión de tipo implícita para eqaulity check in where cláusula, aún es insignificante. Comprueba la respuesta de @David también, que da valores experimentales. –

El costo de rendimiento es que siempre que mysql necesita hacer una conversión de tipo de cualquier cosa que le dé al tipo de datos de la columna. Por lo tanto, con su consulta

SELECCIONE col1, col2, col3 FROM table WHERE col1 = '3';

Si col1 no es un tipo de cadena, MySQL necesita convertir '3' a ese tipo. Este tipo de consulta no es realmente un gran problema, ya que la sobrecarga de rendimiento de esa conversión es insignificante.

Sin embargo, cuando intenta hacer lo mismo cuando, por ejemplo, une 2 tablas que tienen varios millones de filas cada una.Si las columnas de la cláusula de ON no son el mismo tipo de datos, a continuación, MySQL tendrá que convertir varios millones de filas cada vez de ejecutar la consulta, y que es donde la sobrecarga de rendimiento entra en acción.

Fuente

2011-02-07 06:23:12

No entiendo muy bien eso. ¿No solo convertiría el tipo de datos una vez para toda la consulta? Es decir, convierte '3' a 3 al principio y luego lo usa? – andrew

Para su consulta, sí, la conversión se realizará una vez. Sin embargo, cuando se une, para hacer una comparación correcta, las columnas en las que se unirá deben ser del mismo tipo, convirtiendo así cada fila en la tabla. –

interesante.Puedo ver cómo eso realmente ralentizaría el rendimiento. Gracias – andrew

Da la impresión incorrecta sobre el tipo de datos para la columna. Como externo, supongo que la columna en cuestión es CHAR/VARCHAR & elija las operaciones correspondientes.

De lo contrario, MySQL, como la mayoría de las otras bases de datos, convertirá implícitamente el valor a cualquier tipo de datos de columna. No tengo problemas de rendimiento con esto, pero existe el riesgo de que el suministro de un valor que requiera una conversión explícita (usando CAST or CONVERT) desencadene un error.

Fuente

2011-02-07 06:23:33

En mi práctica, he tenido casos en los que mysql inesperadamente no arrojó el valor constante (entero entre comillas), sino el campo en sí. Por lo tanto, el índice no fue utilizado. – zerkms

¿Qué son CAST y CONVERT? – andrew

@andrew: Supuse que tenía claro que son lo que usa para cambiar explícitamente los tipos de datos, pero agregué un enlace a la documentación por si acaso. –

Las cadenas también tienen un orden de clasificación diferente de los números.

comparación:

SELECT 312 < 41

(rendimientos 0, porque 312 numéricamente viene después de 41)

SELECT '312' < '41'

(rendimientos 1, porque '312' lexicográficamente viene antes del '41')

Dependiendo de la forma en que se genere su consulta, el uso de comillas puede dar resultados incorrectos o ninguno.

Los números se deben usar como tales, por lo tanto, nunca use comillas a menos que tenga un motivo especial para hacerlo.

Fuente

2014-06-03 10:37:28 Thomas

Desventajas de citar enteros en una consulta Mysql?

Respuesta

Cuestiones relacionadas