1 Utilice siempre el tipo de datos adecuado<\/strong><\/h2>\nUna de las mejores pr\u00e1cticas m\u00e1s importantes de MySQL es usar tipos de datos basados \u200b\u200ben la naturaleza de los datos. El uso de tipos de datos irrelevantes puede consumir m\u00e1s espacio o generar errores.<\/p>\n
Por ejemplo: el uso de varchar (20) en lugar del tipo de datos DATETIME para almacenar valores de fecha y hora generar\u00e1 errores en los c\u00e1lculos relacionados con la fecha y la hora. Adem\u00e1s, es posible que se almacenen datos no v\u00e1lidos.<\/p>\n
2 Use CHAR (1) sobre VARCHAR (1)<\/strong><\/h2>\nVARCHAR (1) toma bytes adicionales para almacenar informaci\u00f3n, por lo que si ingresa un solo car\u00e1cter, es mejor usar CHAR (1).<\/p>\n
3 Use el tipo de datos CHAR para almacenar solo datos de longitud fija<\/strong><\/h2>\nPor ejemplo: si la longitud de los datos es inferior a 1000, usar char (1000) en lugar de varchar (1000) consumir\u00e1 m\u00e1s espacio.<\/p>\n
4 Evite el uso de formatos de fecha regionales<\/strong><\/h2>\nCuando utilice el tipo de datos DATETIME o DATE, utilice siempre el formato de fecha AAAA-MM-DD o el formato de fecha ISO adecuado para su motor SQL. Los formatos regionales como DD-MM-YYYY o MM-DD-YYYY no se almacenar\u00e1n correctamente.<\/p>\n
5 columnas de clave de \u00edndice<\/strong><\/h2>\nEs deseable que la consulta devuelva el resultado r\u00e1pidamente, as\u00ed que aseg\u00farese de indexar las columnas que se usan en las cl\u00e1usulas JOIN.<\/p>\n
En caso de que use la declaraci\u00f3n UPDATE que involucre m\u00e1s de una tabla, aseg\u00farese de indexar todas las columnas que se usan para unir las tablas.<\/p>\n
6 No use funciones sobre columnas indexadas…<\/strong><\/h2>\n\u2026 porque entonces el \u00edndice pierde su prop\u00f3sito.<\/p>\n
Por ejemplo, suponga que desea obtener datos donde los dos primeros caracteres del c\u00f3digo de cliente son AK. Escribe:<\/p>\n
SELECT columns FROM table WHERE customer_code like 'AK%'<\/code><\/p>\ny no escribas<\/p>\n
SELECT columns FROM table WHERE left (customer_code,2)='AK\u2019<\/code><\/p>\n\u00bfPor qu\u00e9? El primer ejemplo har\u00e1 uso del \u00edndice, lo que resultar\u00e1 en un tiempo de respuesta m\u00e1s r\u00e1pido.<\/p>\n
7 Use SQL SELECT * solo si es necesario<\/strong><\/h2>\nSiguiendo la lista de las mejores pr\u00e1cticas de MySQL, no use ciegamente SELECT * en el c\u00f3digo. Si la tabla tiene muchas columnas, se devolver\u00e1n todas. Esto ralentizar\u00e1 el tiempo de respuesta, especialmente si env\u00eda el resultado a una aplicaci\u00f3n front-end.<\/p>\n
En su lugar, escriba expl\u00edcitamente los nombres de las columnas que realmente se necesitan.<\/p>\n
Nota: recuerde que todas las instrucciones SELECT requieren una cl\u00e1usula WHERE.<\/p>\n
8 Use la cl\u00e1usula ORDER BY solo si es necesario<\/strong><\/h2>\nSi desea mostrar el resultado en la aplicaci\u00f3n frontal, deje que ORDENE el conjunto de resultados. Si hace esto en SQL, el tiempo de respuesta puede ralentizarse en el entorno multiusuario.<\/p>\n
9 Elija un motor de base de datos adecuado<\/strong><\/h2>\nSi desarrolla una aplicaci\u00f3n que lee datos con m\u00e1s frecuencia que escribe (por ejemplo, un motor de b\u00fasqueda), elija el motor de almacenamiento MyISAM.<\/p>\n
Elegir el motor de almacenamiento incorrecto afectar\u00e1 el rendimiento.<\/p>\n
10 Utilice la cl\u00e1usula EXISTS siempre que sea necesario<\/strong><\/h2>\nPara verificar la existencia de datos, use la cl\u00e1usula EXISTS, que es m\u00e1s r\u00e1pida en el tiempo de respuesta. Por ejemplo, utilice:<\/p>\n
If EXISTS(SELECT * from Table WHERE col=\u2019some value\u2019)<\/code><\/p>\nNo utilice :<\/p>\n
If (SELECT count(*) from Table WHERE col=\u2019some value\u2019)>0<\/code><\/p>\n11 EXPLICA tus consultas SELECT<\/strong><\/h2>\nSi usa la palabra clave EXPLAIN, puede obtener informaci\u00f3n sobre lo que MySQL est\u00e1 haciendo para ejecutar su consulta. Esto puede ayudarlo a detectar problemas con sus consultas o estructuras de tablas (por ejemplo, cuellos de botella).<\/p>\n
Una consulta EXPLAIN muestra qu\u00e9 \u00edndices se est\u00e1n utilizando, c\u00f3mo se escanea, clasifica la tabla, etc.<\/p>\n
Todo lo que tiene que hacer es agregar la palabra clave EXPLICAR delante de una consulta SELECCIONAR (preferiblemente una consulta compleja con uniones). Adem\u00e1s, si usa phpmyadmin para esto, sus resultados se mostrar\u00e1n en una buena tabla.<\/p>\n
12 Use LIMIT 1 cuando obtenga una fila \u00fanica<\/strong><\/h2>\nA veces, sabe de antemano que est\u00e1 buscando solo una fila al consultar sus tablas. Por ejemplo, es posible que obtenga un registro \u00fanico o simplemente verifique la existencia de cualquier n\u00famero de registros que satisfagan su cl\u00e1usula WHERE.<\/p>\n
En tales casos, querr\u00e1 usar la funci\u00f3n de l\u00edmite de MySQL para aumentar el rendimiento. Esta es otra de las mejores pr\u00e1cticas de MySQL: simplemente agregue LIMIT 1 a su consulta. De esta forma, el motor de la base de datos no tendr\u00e1 que recorrer toda la tabla o el \u00edndice. Dejar\u00e1 de escanear cuando encuentre solo 1 registro de lo que est\u00e1 buscando.<\/p>\n
\/\/ do I have anyusersfrom Alabama?<\/code><\/p>\n\/\/ qu\u00e9 NO hacer:
\n$r = mysql_query(\u00abSELECCIONAR * DESDE usuario DONDE estado = ‘Alabama’");
\nif (mysql_num_rows($r) > 0) {
\n\/\/ \u2026
\n}<\/p>\n
\/\/ mucho mejor:
\n$r = mysql_query(\u00abSELECCIONE 1 DEL usuario DONDE estado = ‘Alabama’ L\u00cdMITE 1");
\nsi (mysql_num_rows($r) > 0) {
\n\/\/ \u2026
\n}<\/p>\n
13 Indexe y use los mismos tipos de columna para las uniones<\/strong><\/h2>\nOtro consejo vital de las mejores pr\u00e1cticas de MySQL: si su aplicaci\u00f3n tiene muchas consultas JOIN, aseg\u00farese de que las columnas por las que se une est\u00e9n indexadas en ambas tablas. Esto afecta la optimizaci\u00f3n interna de la operaci\u00f3n de combinaci\u00f3n de MySQL.<\/p>\n
Adem\u00e1s, las columnas unidas deben ser del mismo tipo. Por ejemplo, si une una columna DECIMAL a una columna INT de otra tabla, MySQL no podr\u00e1 usar ninguno de los \u00edndices. Incluso las codificaciones de caracteres deben ser del mismo tipo para las columnas de tipo cadena.<\/p>\n
\/\/ looking for companies in my state $r = mysql_query(\"SELECT company_name FROM users LEFT JOIN companies ON (users.state = companies.state) WHERE users.id = $user_id\");<\/code><\/p>\n\/\/ ambas columnas de estado deben estar indexadas
\n\/\/ y ambas deben ser del mismo tipo y codificaci\u00f3n de caracteres
\n\/\/ o MySQL podr\u00eda realizar exploraciones de tablas completas<\/p>\n
14 Ocultar MySQL de Internet<\/strong><\/h2>\nLos administradores de bases de datos experimentados y el personal de seguridad lo saben: nunca aloje la base de datos en la ra\u00edz del servidor web.<\/p>\n
Para las aplicaciones habilitadas para la Web, MySQL debe estar oculto detr\u00e1s de un firewall. La comunicaci\u00f3n debe habilitarse solo entre los servidores de aplicaciones y sus servidores web.<\/p>\n
Otra opci\u00f3n es usar MySQL skip-networking. Cuando est\u00e1 habilitado, MySQL solo escucha las conexiones de socket locales e ignora todos los puertos TCP.<\/p>\n
15 Utilice los tipos de datos m\u00e1s peque\u00f1os posibles<\/strong><\/h2>\n![\"22](\"https:\/\/wordpress.mediadoma.com\/wp-content\/uploads\/2022\/01\/post-206970-61e8d4b73d55e.jpg\")
<\/a><\/p>\nDejame contarte una historia. Cuando asist\u00eda a la universidad, la filosof\u00eda era que \u00abla memoria es escasa\u00bb. Esos eran los d\u00edas de los discos duros de 256 MB. Hoy en d\u00eda, a nadie parece importarle un \u00e1pice la memoria o el espacio en el disco duro. La nueva filosof\u00eda es que \u00abla memoria es barata\u00bb. Puede que sea cierto en t\u00e9rminos de d\u00f3lares, pero la lectura de tipos de datos grandes lleva m\u00e1s tiempo que la lectura de tipos m\u00e1s peque\u00f1os. Los tipos de datos grandes requieren que se lean m\u00e1s sectores de disco en la memoria.<\/p>\n
La moraleja es, ignore la tentaci\u00f3n de saltar inmediatamente al tipo de datos m\u00e1s grande cuando dise\u00f1e sus tablas. Piense en usar un int en lugar de un bigint.<\/p>\n
Adem\u00e1s, evite los campos de texto de caracteres grandes (255) cuando un car\u00e1cter varchar o m\u00e1s peque\u00f1o es suficiente.<\/p>\n
Si utiliza el tipo de datos correcto, cabr\u00e1n m\u00e1s registros en la memoria o en el bloque de claves de \u00edndice. Esto conduce a menos lecturas y un rendimiento m\u00e1s r\u00e1pido.<\/p>\n
16 Aproveche el almacenamiento en cach\u00e9 de consultas<\/strong><\/h2>\nEl almacenamiento en cach\u00e9 de consultas es uno de los m\u00e9todos m\u00e1s eficaces para mejorar el rendimiento. La mayor\u00eda de los servidores MySQL lo tienen habilitado por defecto.<\/p>\n
La cach\u00e9 de consultas almacena el texto de una declaraci\u00f3n SELECT junto con el conjunto de resultados correspondiente. Si el servidor recibe m\u00e1s tarde una declaraci\u00f3n id\u00e9ntica, recuperar\u00e1 los resultados de la cach\u00e9 de consultas en lugar de analizar y ejecutar la declaraci\u00f3n nuevamente. La cach\u00e9 de consultas se comparte entre sesiones, por lo que un conjunto de resultados generado por un cliente puede enviarse en respuesta a la misma consulta emitida por otro cliente.<\/p>\n
Sin embargo, por grandioso que sea, el almacenamiento en cach\u00e9 de consultas tiene sus limitaciones. Tome la siguiente declaraci\u00f3n:<\/p>\n
El problema aqu\u00ed es que las consultas contienen ciertas funciones no deterministas, como NOW() y RAND(). MySQL no puede calcular tales funciones por adelantado, por lo que terminan sin almacenarse en cach\u00e9.<\/p>\n
Afortunadamente, hay una soluci\u00f3n f\u00e1cil para eso: puede almacenar los resultados de la funci\u00f3n en una variable.<\/p>\n
17 No editar archivos de volcado<\/strong><\/h2>\nLos archivos de volcado son muy enga\u00f1osos y pueden causar corrupci\u00f3n. \u00bfPor qu\u00e9? Si alguna vez ha visto los archivos de volcado creados por mysqldump, estar\u00e1 de acuerdo en que parecen archivos de texto normales e inofensivos. Es por eso que la mayor\u00eda de las personas los editan en un editor de texto est\u00e1ndar, lo que hace que aparezcan corrupciones.<\/p>\n
Si alguna vez ha intentado editar archivos de volcado, r\u00e1pidamente aprendi\u00f3 que son cualquier cosa menos un archivo de texto. Por lo tanto, la \u00fanica forma garantizada de evitar problemas es dejar los archivos de volcado en paz.<\/p>\n
18 Use la configuraci\u00f3n de tama\u00f1o de bloque de MyISAM<\/strong><\/h2>\n
VARCHAR (1) toma bytes adicionales para almacenar informaci\u00f3n, por lo que si ingresa un solo car\u00e1cter, es mejor usar CHAR (1).<\/p>\n
3 Use el tipo de datos CHAR para almacenar solo datos de longitud fija<\/strong><\/h2>\nPor ejemplo: si la longitud de los datos es inferior a 1000, usar char (1000) en lugar de varchar (1000) consumir\u00e1 m\u00e1s espacio.<\/p>\n
4 Evite el uso de formatos de fecha regionales<\/strong><\/h2>\nCuando utilice el tipo de datos DATETIME o DATE, utilice siempre el formato de fecha AAAA-MM-DD o el formato de fecha ISO adecuado para su motor SQL. Los formatos regionales como DD-MM-YYYY o MM-DD-YYYY no se almacenar\u00e1n correctamente.<\/p>\n
5 columnas de clave de \u00edndice<\/strong><\/h2>\nEs deseable que la consulta devuelva el resultado r\u00e1pidamente, as\u00ed que aseg\u00farese de indexar las columnas que se usan en las cl\u00e1usulas JOIN.<\/p>\n
En caso de que use la declaraci\u00f3n UPDATE que involucre m\u00e1s de una tabla, aseg\u00farese de indexar todas las columnas que se usan para unir las tablas.<\/p>\n
6 No use funciones sobre columnas indexadas…<\/strong><\/h2>\n\u2026 porque entonces el \u00edndice pierde su prop\u00f3sito.<\/p>\n
Por ejemplo, suponga que desea obtener datos donde los dos primeros caracteres del c\u00f3digo de cliente son AK. Escribe:<\/p>\n
SELECT columns FROM table WHERE customer_code like 'AK%'<\/code><\/p>\ny no escribas<\/p>\n
SELECT columns FROM table WHERE left (customer_code,2)='AK\u2019<\/code><\/p>\n\u00bfPor qu\u00e9? El primer ejemplo har\u00e1 uso del \u00edndice, lo que resultar\u00e1 en un tiempo de respuesta m\u00e1s r\u00e1pido.<\/p>\n
7 Use SQL SELECT * solo si es necesario<\/strong><\/h2>\nSiguiendo la lista de las mejores pr\u00e1cticas de MySQL, no use ciegamente SELECT * en el c\u00f3digo. Si la tabla tiene muchas columnas, se devolver\u00e1n todas. Esto ralentizar\u00e1 el tiempo de respuesta, especialmente si env\u00eda el resultado a una aplicaci\u00f3n front-end.<\/p>\n
En su lugar, escriba expl\u00edcitamente los nombres de las columnas que realmente se necesitan.<\/p>\n
Nota: recuerde que todas las instrucciones SELECT requieren una cl\u00e1usula WHERE.<\/p>\n
8 Use la cl\u00e1usula ORDER BY solo si es necesario<\/strong><\/h2>\nSi desea mostrar el resultado en la aplicaci\u00f3n frontal, deje que ORDENE el conjunto de resultados. Si hace esto en SQL, el tiempo de respuesta puede ralentizarse en el entorno multiusuario.<\/p>\n
9 Elija un motor de base de datos adecuado<\/strong><\/h2>\nSi desarrolla una aplicaci\u00f3n que lee datos con m\u00e1s frecuencia que escribe (por ejemplo, un motor de b\u00fasqueda), elija el motor de almacenamiento MyISAM.<\/p>\n
Elegir el motor de almacenamiento incorrecto afectar\u00e1 el rendimiento.<\/p>\n
10 Utilice la cl\u00e1usula EXISTS siempre que sea necesario<\/strong><\/h2>\nPara verificar la existencia de datos, use la cl\u00e1usula EXISTS, que es m\u00e1s r\u00e1pida en el tiempo de respuesta. Por ejemplo, utilice:<\/p>\n
If EXISTS(SELECT * from Table WHERE col=\u2019some value\u2019)<\/code><\/p>\nNo utilice :<\/p>\n
If (SELECT count(*) from Table WHERE col=\u2019some value\u2019)>0<\/code><\/p>\n11 EXPLICA tus consultas SELECT<\/strong><\/h2>\nSi usa la palabra clave EXPLAIN, puede obtener informaci\u00f3n sobre lo que MySQL est\u00e1 haciendo para ejecutar su consulta. Esto puede ayudarlo a detectar problemas con sus consultas o estructuras de tablas (por ejemplo, cuellos de botella).<\/p>\n
Una consulta EXPLAIN muestra qu\u00e9 \u00edndices se est\u00e1n utilizando, c\u00f3mo se escanea, clasifica la tabla, etc.<\/p>\n
Todo lo que tiene que hacer es agregar la palabra clave EXPLICAR delante de una consulta SELECCIONAR (preferiblemente una consulta compleja con uniones). Adem\u00e1s, si usa phpmyadmin para esto, sus resultados se mostrar\u00e1n en una buena tabla.<\/p>\n
12 Use LIMIT 1 cuando obtenga una fila \u00fanica<\/strong><\/h2>\nA veces, sabe de antemano que est\u00e1 buscando solo una fila al consultar sus tablas. Por ejemplo, es posible que obtenga un registro \u00fanico o simplemente verifique la existencia de cualquier n\u00famero de registros que satisfagan su cl\u00e1usula WHERE.<\/p>\n
En tales casos, querr\u00e1 usar la funci\u00f3n de l\u00edmite de MySQL para aumentar el rendimiento. Esta es otra de las mejores pr\u00e1cticas de MySQL: simplemente agregue LIMIT 1 a su consulta. De esta forma, el motor de la base de datos no tendr\u00e1 que recorrer toda la tabla o el \u00edndice. Dejar\u00e1 de escanear cuando encuentre solo 1 registro de lo que est\u00e1 buscando.<\/p>\n
\/\/ do I have anyusersfrom Alabama?<\/code><\/p>\n\/\/ qu\u00e9 NO hacer:
\n$r = mysql_query(\u00abSELECCIONAR * DESDE usuario DONDE estado = ‘Alabama’");
\nif (mysql_num_rows($r) > 0) {
\n\/\/ \u2026
\n}<\/p>\n
\/\/ mucho mejor:
\n$r = mysql_query(\u00abSELECCIONE 1 DEL usuario DONDE estado = ‘Alabama’ L\u00cdMITE 1");
\nsi (mysql_num_rows($r) > 0) {
\n\/\/ \u2026
\n}<\/p>\n
13 Indexe y use los mismos tipos de columna para las uniones<\/strong><\/h2>\nOtro consejo vital de las mejores pr\u00e1cticas de MySQL: si su aplicaci\u00f3n tiene muchas consultas JOIN, aseg\u00farese de que las columnas por las que se une est\u00e9n indexadas en ambas tablas. Esto afecta la optimizaci\u00f3n interna de la operaci\u00f3n de combinaci\u00f3n de MySQL.<\/p>\n
Adem\u00e1s, las columnas unidas deben ser del mismo tipo. Por ejemplo, si une una columna DECIMAL a una columna INT de otra tabla, MySQL no podr\u00e1 usar ninguno de los \u00edndices. Incluso las codificaciones de caracteres deben ser del mismo tipo para las columnas de tipo cadena.<\/p>\n
\/\/ looking for companies in my state $r = mysql_query(\"SELECT company_name FROM users LEFT JOIN companies ON (users.state = companies.state) WHERE users.id = $user_id\");<\/code><\/p>\n\/\/ ambas columnas de estado deben estar indexadas
\n\/\/ y ambas deben ser del mismo tipo y codificaci\u00f3n de caracteres
\n\/\/ o MySQL podr\u00eda realizar exploraciones de tablas completas<\/p>\n
14 Ocultar MySQL de Internet<\/strong><\/h2>\nLos administradores de bases de datos experimentados y el personal de seguridad lo saben: nunca aloje la base de datos en la ra\u00edz del servidor web.<\/p>\n
Para las aplicaciones habilitadas para la Web, MySQL debe estar oculto detr\u00e1s de un firewall. La comunicaci\u00f3n debe habilitarse solo entre los servidores de aplicaciones y sus servidores web.<\/p>\n
Otra opci\u00f3n es usar MySQL skip-networking. Cuando est\u00e1 habilitado, MySQL solo escucha las conexiones de socket locales e ignora todos los puertos TCP.<\/p>\n
15 Utilice los tipos de datos m\u00e1s peque\u00f1os posibles<\/strong><\/h2>\n<\/a><\/p>\nDejame contarte una historia. Cuando asist\u00eda a la universidad, la filosof\u00eda era que \u00abla memoria es escasa\u00bb. Esos eran los d\u00edas de los discos duros de 256 MB. Hoy en d\u00eda, a nadie parece importarle un \u00e1pice la memoria o el espacio en el disco duro. La nueva filosof\u00eda es que \u00abla memoria es barata\u00bb. Puede que sea cierto en t\u00e9rminos de d\u00f3lares, pero la lectura de tipos de datos grandes lleva m\u00e1s tiempo que la lectura de tipos m\u00e1s peque\u00f1os. Los tipos de datos grandes requieren que se lean m\u00e1s sectores de disco en la memoria.<\/p>\n
La moraleja es, ignore la tentaci\u00f3n de saltar inmediatamente al tipo de datos m\u00e1s grande cuando dise\u00f1e sus tablas. Piense en usar un int en lugar de un bigint.<\/p>\n
Adem\u00e1s, evite los campos de texto de caracteres grandes (255) cuando un car\u00e1cter varchar o m\u00e1s peque\u00f1o es suficiente.<\/p>\n
Si utiliza el tipo de datos correcto, cabr\u00e1n m\u00e1s registros en la memoria o en el bloque de claves de \u00edndice. Esto conduce a menos lecturas y un rendimiento m\u00e1s r\u00e1pido.<\/p>\n
16 Aproveche el almacenamiento en cach\u00e9 de consultas<\/strong><\/h2>\nEl almacenamiento en cach\u00e9 de consultas es uno de los m\u00e9todos m\u00e1s eficaces para mejorar el rendimiento. La mayor\u00eda de los servidores MySQL lo tienen habilitado por defecto.<\/p>\n
La cach\u00e9 de consultas almacena el texto de una declaraci\u00f3n SELECT junto con el conjunto de resultados correspondiente. Si el servidor recibe m\u00e1s tarde una declaraci\u00f3n id\u00e9ntica, recuperar\u00e1 los resultados de la cach\u00e9 de consultas en lugar de analizar y ejecutar la declaraci\u00f3n nuevamente. La cach\u00e9 de consultas se comparte entre sesiones, por lo que un conjunto de resultados generado por un cliente puede enviarse en respuesta a la misma consulta emitida por otro cliente.<\/p>\n
Sin embargo, por grandioso que sea, el almacenamiento en cach\u00e9 de consultas tiene sus limitaciones. Tome la siguiente declaraci\u00f3n:<\/p>\n
El problema aqu\u00ed es que las consultas contienen ciertas funciones no deterministas, como NOW() y RAND(). MySQL no puede calcular tales funciones por adelantado, por lo que terminan sin almacenarse en cach\u00e9.<\/p>\n
Afortunadamente, hay una soluci\u00f3n f\u00e1cil para eso: puede almacenar los resultados de la funci\u00f3n en una variable.<\/p>\n
17 No editar archivos de volcado<\/strong><\/h2>\nLos archivos de volcado son muy enga\u00f1osos y pueden causar corrupci\u00f3n. \u00bfPor qu\u00e9? Si alguna vez ha visto los archivos de volcado creados por mysqldump, estar\u00e1 de acuerdo en que parecen archivos de texto normales e inofensivos. Es por eso que la mayor\u00eda de las personas los editan en un editor de texto est\u00e1ndar, lo que hace que aparezcan corrupciones.<\/p>\n
Si alguna vez ha intentado editar archivos de volcado, r\u00e1pidamente aprendi\u00f3 que son cualquier cosa menos un archivo de texto. Por lo tanto, la \u00fanica forma garantizada de evitar problemas es dejar los archivos de volcado en paz.<\/p>\n
18 Use la configuraci\u00f3n de tama\u00f1o de bloque de MyISAM<\/strong><\/h2>\n
Cuando utilice el tipo de datos DATETIME o DATE, utilice siempre el formato de fecha AAAA-MM-DD o el formato de fecha ISO adecuado para su motor SQL. Los formatos regionales como DD-MM-YYYY o MM-DD-YYYY no se almacenar\u00e1n correctamente.<\/p>\n
5 columnas de clave de \u00edndice<\/strong><\/h2>\nEs deseable que la consulta devuelva el resultado r\u00e1pidamente, as\u00ed que aseg\u00farese de indexar las columnas que se usan en las cl\u00e1usulas JOIN.<\/p>\n
En caso de que use la declaraci\u00f3n UPDATE que involucre m\u00e1s de una tabla, aseg\u00farese de indexar todas las columnas que se usan para unir las tablas.<\/p>\n
6 No use funciones sobre columnas indexadas…<\/strong><\/h2>\n\u2026 porque entonces el \u00edndice pierde su prop\u00f3sito.<\/p>\n
Por ejemplo, suponga que desea obtener datos donde los dos primeros caracteres del c\u00f3digo de cliente son AK. Escribe:<\/p>\n
SELECT columns FROM table WHERE customer_code like 'AK%'<\/code><\/p>\ny no escribas<\/p>\n
SELECT columns FROM table WHERE left (customer_code,2)='AK\u2019<\/code><\/p>\n\u00bfPor qu\u00e9? El primer ejemplo har\u00e1 uso del \u00edndice, lo que resultar\u00e1 en un tiempo de respuesta m\u00e1s r\u00e1pido.<\/p>\n
7 Use SQL SELECT * solo si es necesario<\/strong><\/h2>\nSiguiendo la lista de las mejores pr\u00e1cticas de MySQL, no use ciegamente SELECT * en el c\u00f3digo. Si la tabla tiene muchas columnas, se devolver\u00e1n todas. Esto ralentizar\u00e1 el tiempo de respuesta, especialmente si env\u00eda el resultado a una aplicaci\u00f3n front-end.<\/p>\n
En su lugar, escriba expl\u00edcitamente los nombres de las columnas que realmente se necesitan.<\/p>\n
Nota: recuerde que todas las instrucciones SELECT requieren una cl\u00e1usula WHERE.<\/p>\n
8 Use la cl\u00e1usula ORDER BY solo si es necesario<\/strong><\/h2>\nSi desea mostrar el resultado en la aplicaci\u00f3n frontal, deje que ORDENE el conjunto de resultados. Si hace esto en SQL, el tiempo de respuesta puede ralentizarse en el entorno multiusuario.<\/p>\n
9 Elija un motor de base de datos adecuado<\/strong><\/h2>\nSi desarrolla una aplicaci\u00f3n que lee datos con m\u00e1s frecuencia que escribe (por ejemplo, un motor de b\u00fasqueda), elija el motor de almacenamiento MyISAM.<\/p>\n
Elegir el motor de almacenamiento incorrecto afectar\u00e1 el rendimiento.<\/p>\n
10 Utilice la cl\u00e1usula EXISTS siempre que sea necesario<\/strong><\/h2>\nPara verificar la existencia de datos, use la cl\u00e1usula EXISTS, que es m\u00e1s r\u00e1pida en el tiempo de respuesta. Por ejemplo, utilice:<\/p>\n
If EXISTS(SELECT * from Table WHERE col=\u2019some value\u2019)<\/code><\/p>\nNo utilice :<\/p>\n
If (SELECT count(*) from Table WHERE col=\u2019some value\u2019)>0<\/code><\/p>\n11 EXPLICA tus consultas SELECT<\/strong><\/h2>\nSi usa la palabra clave EXPLAIN, puede obtener informaci\u00f3n sobre lo que MySQL est\u00e1 haciendo para ejecutar su consulta. Esto puede ayudarlo a detectar problemas con sus consultas o estructuras de tablas (por ejemplo, cuellos de botella).<\/p>\n
Una consulta EXPLAIN muestra qu\u00e9 \u00edndices se est\u00e1n utilizando, c\u00f3mo se escanea, clasifica la tabla, etc.<\/p>\n
Todo lo que tiene que hacer es agregar la palabra clave EXPLICAR delante de una consulta SELECCIONAR (preferiblemente una consulta compleja con uniones). Adem\u00e1s, si usa phpmyadmin para esto, sus resultados se mostrar\u00e1n en una buena tabla.<\/p>\n
12 Use LIMIT 1 cuando obtenga una fila \u00fanica<\/strong><\/h2>\nA veces, sabe de antemano que est\u00e1 buscando solo una fila al consultar sus tablas. Por ejemplo, es posible que obtenga un registro \u00fanico o simplemente verifique la existencia de cualquier n\u00famero de registros que satisfagan su cl\u00e1usula WHERE.<\/p>\n
En tales casos, querr\u00e1 usar la funci\u00f3n de l\u00edmite de MySQL para aumentar el rendimiento. Esta es otra de las mejores pr\u00e1cticas de MySQL: simplemente agregue LIMIT 1 a su consulta. De esta forma, el motor de la base de datos no tendr\u00e1 que recorrer toda la tabla o el \u00edndice. Dejar\u00e1 de escanear cuando encuentre solo 1 registro de lo que est\u00e1 buscando.<\/p>\n
\/\/ do I have anyusersfrom Alabama?<\/code><\/p>\n\/\/ qu\u00e9 NO hacer:
\n$r = mysql_query(\u00abSELECCIONAR * DESDE usuario DONDE estado = ‘Alabama’");
\nif (mysql_num_rows($r) > 0) {
\n\/\/ \u2026
\n}<\/p>\n
\/\/ mucho mejor:
\n$r = mysql_query(\u00abSELECCIONE 1 DEL usuario DONDE estado = ‘Alabama’ L\u00cdMITE 1");
\nsi (mysql_num_rows($r) > 0) {
\n\/\/ \u2026
\n}<\/p>\n
13 Indexe y use los mismos tipos de columna para las uniones<\/strong><\/h2>\nOtro consejo vital de las mejores pr\u00e1cticas de MySQL: si su aplicaci\u00f3n tiene muchas consultas JOIN, aseg\u00farese de que las columnas por las que se une est\u00e9n indexadas en ambas tablas. Esto afecta la optimizaci\u00f3n interna de la operaci\u00f3n de combinaci\u00f3n de MySQL.<\/p>\n
Adem\u00e1s, las columnas unidas deben ser del mismo tipo. Por ejemplo, si une una columna DECIMAL a una columna INT de otra tabla, MySQL no podr\u00e1 usar ninguno de los \u00edndices. Incluso las codificaciones de caracteres deben ser del mismo tipo para las columnas de tipo cadena.<\/p>\n
\/\/ looking for companies in my state $r = mysql_query(\"SELECT company_name FROM users LEFT JOIN companies ON (users.state = companies.state) WHERE users.id = $user_id\");<\/code><\/p>\n\/\/ ambas columnas de estado deben estar indexadas
\n\/\/ y ambas deben ser del mismo tipo y codificaci\u00f3n de caracteres
\n\/\/ o MySQL podr\u00eda realizar exploraciones de tablas completas<\/p>\n
14 Ocultar MySQL de Internet<\/strong><\/h2>\nLos administradores de bases de datos experimentados y el personal de seguridad lo saben: nunca aloje la base de datos en la ra\u00edz del servidor web.<\/p>\n
Para las aplicaciones habilitadas para la Web, MySQL debe estar oculto detr\u00e1s de un firewall. La comunicaci\u00f3n debe habilitarse solo entre los servidores de aplicaciones y sus servidores web.<\/p>\n
Otra opci\u00f3n es usar MySQL skip-networking. Cuando est\u00e1 habilitado, MySQL solo escucha las conexiones de socket locales e ignora todos los puertos TCP.<\/p>\n
15 Utilice los tipos de datos m\u00e1s peque\u00f1os posibles<\/strong><\/h2>\n<\/a><\/p>\nDejame contarte una historia. Cuando asist\u00eda a la universidad, la filosof\u00eda era que \u00abla memoria es escasa\u00bb. Esos eran los d\u00edas de los discos duros de 256 MB. Hoy en d\u00eda, a nadie parece importarle un \u00e1pice la memoria o el espacio en el disco duro. La nueva filosof\u00eda es que \u00abla memoria es barata\u00bb. Puede que sea cierto en t\u00e9rminos de d\u00f3lares, pero la lectura de tipos de datos grandes lleva m\u00e1s tiempo que la lectura de tipos m\u00e1s peque\u00f1os. Los tipos de datos grandes requieren que se lean m\u00e1s sectores de disco en la memoria.<\/p>\n
La moraleja es, ignore la tentaci\u00f3n de saltar inmediatamente al tipo de datos m\u00e1s grande cuando dise\u00f1e sus tablas. Piense en usar un int en lugar de un bigint.<\/p>\n
Adem\u00e1s, evite los campos de texto de caracteres grandes (255) cuando un car\u00e1cter varchar o m\u00e1s peque\u00f1o es suficiente.<\/p>\n
Si utiliza el tipo de datos correcto, cabr\u00e1n m\u00e1s registros en la memoria o en el bloque de claves de \u00edndice. Esto conduce a menos lecturas y un rendimiento m\u00e1s r\u00e1pido.<\/p>\n
16 Aproveche el almacenamiento en cach\u00e9 de consultas<\/strong><\/h2>\nEl almacenamiento en cach\u00e9 de consultas es uno de los m\u00e9todos m\u00e1s eficaces para mejorar el rendimiento. La mayor\u00eda de los servidores MySQL lo tienen habilitado por defecto.<\/p>\n
La cach\u00e9 de consultas almacena el texto de una declaraci\u00f3n SELECT junto con el conjunto de resultados correspondiente. Si el servidor recibe m\u00e1s tarde una declaraci\u00f3n id\u00e9ntica, recuperar\u00e1 los resultados de la cach\u00e9 de consultas en lugar de analizar y ejecutar la declaraci\u00f3n nuevamente. La cach\u00e9 de consultas se comparte entre sesiones, por lo que un conjunto de resultados generado por un cliente puede enviarse en respuesta a la misma consulta emitida por otro cliente.<\/p>\n
Sin embargo, por grandioso que sea, el almacenamiento en cach\u00e9 de consultas tiene sus limitaciones. Tome la siguiente declaraci\u00f3n:<\/p>\n
El problema aqu\u00ed es que las consultas contienen ciertas funciones no deterministas, como NOW() y RAND(). MySQL no puede calcular tales funciones por adelantado, por lo que terminan sin almacenarse en cach\u00e9.<\/p>\n
Afortunadamente, hay una soluci\u00f3n f\u00e1cil para eso: puede almacenar los resultados de la funci\u00f3n en una variable.<\/p>\n
17 No editar archivos de volcado<\/strong><\/h2>\nLos archivos de volcado son muy enga\u00f1osos y pueden causar corrupci\u00f3n. \u00bfPor qu\u00e9? Si alguna vez ha visto los archivos de volcado creados por mysqldump, estar\u00e1 de acuerdo en que parecen archivos de texto normales e inofensivos. Es por eso que la mayor\u00eda de las personas los editan en un editor de texto est\u00e1ndar, lo que hace que aparezcan corrupciones.<\/p>\n
Si alguna vez ha intentado editar archivos de volcado, r\u00e1pidamente aprendi\u00f3 que son cualquier cosa menos un archivo de texto. Por lo tanto, la \u00fanica forma garantizada de evitar problemas es dejar los archivos de volcado en paz.<\/p>\n
18 Use la configuraci\u00f3n de tama\u00f1o de bloque de MyISAM<\/strong><\/h2>\n
\u2026 porque entonces el \u00edndice pierde su prop\u00f3sito.<\/p>\n
Por ejemplo, suponga que desea obtener datos donde los dos primeros caracteres del c\u00f3digo de cliente son AK. Escribe:<\/p>\n
y no escribas<\/p>\n \u00bfPor qu\u00e9? El primer ejemplo har\u00e1 uso del \u00edndice, lo que resultar\u00e1 en un tiempo de respuesta m\u00e1s r\u00e1pido.<\/p>\n Siguiendo la lista de las mejores pr\u00e1cticas de MySQL, no use ciegamente SELECT * en el c\u00f3digo. Si la tabla tiene muchas columnas, se devolver\u00e1n todas. Esto ralentizar\u00e1 el tiempo de respuesta, especialmente si env\u00eda el resultado a una aplicaci\u00f3n front-end.<\/p>\n En su lugar, escriba expl\u00edcitamente los nombres de las columnas que realmente se necesitan.<\/p>\n Nota: recuerde que todas las instrucciones SELECT requieren una cl\u00e1usula WHERE.<\/p>\n Si desea mostrar el resultado en la aplicaci\u00f3n frontal, deje que ORDENE el conjunto de resultados. Si hace esto en SQL, el tiempo de respuesta puede ralentizarse en el entorno multiusuario.<\/p>\n Si desarrolla una aplicaci\u00f3n que lee datos con m\u00e1s frecuencia que escribe (por ejemplo, un motor de b\u00fasqueda), elija el motor de almacenamiento MyISAM.<\/p>\n Elegir el motor de almacenamiento incorrecto afectar\u00e1 el rendimiento.<\/p>\n Para verificar la existencia de datos, use la cl\u00e1usula EXISTS, que es m\u00e1s r\u00e1pida en el tiempo de respuesta. Por ejemplo, utilice:<\/p>\n No utilice :<\/p>\n Si usa la palabra clave EXPLAIN, puede obtener informaci\u00f3n sobre lo que MySQL est\u00e1 haciendo para ejecutar su consulta. Esto puede ayudarlo a detectar problemas con sus consultas o estructuras de tablas (por ejemplo, cuellos de botella).<\/p>\n Una consulta EXPLAIN muestra qu\u00e9 \u00edndices se est\u00e1n utilizando, c\u00f3mo se escanea, clasifica la tabla, etc.<\/p>\n Todo lo que tiene que hacer es agregar la palabra clave EXPLICAR delante de una consulta SELECCIONAR (preferiblemente una consulta compleja con uniones). Adem\u00e1s, si usa phpmyadmin para esto, sus resultados se mostrar\u00e1n en una buena tabla.<\/p>\n A veces, sabe de antemano que est\u00e1 buscando solo una fila al consultar sus tablas. Por ejemplo, es posible que obtenga un registro \u00fanico o simplemente verifique la existencia de cualquier n\u00famero de registros que satisfagan su cl\u00e1usula WHERE.<\/p>\n En tales casos, querr\u00e1 usar la funci\u00f3n de l\u00edmite de MySQL para aumentar el rendimiento. Esta es otra de las mejores pr\u00e1cticas de MySQL: simplemente agregue LIMIT 1 a su consulta. De esta forma, el motor de la base de datos no tendr\u00e1 que recorrer toda la tabla o el \u00edndice. Dejar\u00e1 de escanear cuando encuentre solo 1 registro de lo que est\u00e1 buscando.<\/p>\n \/\/ qu\u00e9 NO hacer: \/\/ mucho mejor: Otro consejo vital de las mejores pr\u00e1cticas de MySQL: si su aplicaci\u00f3n tiene muchas consultas JOIN, aseg\u00farese de que las columnas por las que se une est\u00e9n indexadas en ambas tablas. Esto afecta la optimizaci\u00f3n interna de la operaci\u00f3n de combinaci\u00f3n de MySQL.<\/p>\n Adem\u00e1s, las columnas unidas deben ser del mismo tipo. Por ejemplo, si une una columna DECIMAL a una columna INT de otra tabla, MySQL no podr\u00e1 usar ninguno de los \u00edndices. Incluso las codificaciones de caracteres deben ser del mismo tipo para las columnas de tipo cadena.<\/p>\n \/\/ ambas columnas de estado deben estar indexadas Los administradores de bases de datos experimentados y el personal de seguridad lo saben: nunca aloje la base de datos en la ra\u00edz del servidor web.<\/p>\n Para las aplicaciones habilitadas para la Web, MySQL debe estar oculto detr\u00e1s de un firewall. La comunicaci\u00f3n debe habilitarse solo entre los servidores de aplicaciones y sus servidores web.<\/p>\n Otra opci\u00f3n es usar MySQL skip-networking. Cuando est\u00e1 habilitado, MySQL solo escucha las conexiones de socket locales e ignora todos los puertos TCP.<\/p>\n Dejame contarte una historia. Cuando asist\u00eda a la universidad, la filosof\u00eda era que \u00abla memoria es escasa\u00bb. Esos eran los d\u00edas de los discos duros de 256 MB. Hoy en d\u00eda, a nadie parece importarle un \u00e1pice la memoria o el espacio en el disco duro. La nueva filosof\u00eda es que \u00abla memoria es barata\u00bb. Puede que sea cierto en t\u00e9rminos de d\u00f3lares, pero la lectura de tipos de datos grandes lleva m\u00e1s tiempo que la lectura de tipos m\u00e1s peque\u00f1os. Los tipos de datos grandes requieren que se lean m\u00e1s sectores de disco en la memoria.<\/p>\n La moraleja es, ignore la tentaci\u00f3n de saltar inmediatamente al tipo de datos m\u00e1s grande cuando dise\u00f1e sus tablas. Piense en usar un int en lugar de un bigint.<\/p>\n Adem\u00e1s, evite los campos de texto de caracteres grandes (255) cuando un car\u00e1cter varchar o m\u00e1s peque\u00f1o es suficiente.<\/p>\n Si utiliza el tipo de datos correcto, cabr\u00e1n m\u00e1s registros en la memoria o en el bloque de claves de \u00edndice. Esto conduce a menos lecturas y un rendimiento m\u00e1s r\u00e1pido.<\/p>\n El almacenamiento en cach\u00e9 de consultas es uno de los m\u00e9todos m\u00e1s eficaces para mejorar el rendimiento. La mayor\u00eda de los servidores MySQL lo tienen habilitado por defecto.<\/p>\n La cach\u00e9 de consultas almacena el texto de una declaraci\u00f3n SELECT junto con el conjunto de resultados correspondiente. Si el servidor recibe m\u00e1s tarde una declaraci\u00f3n id\u00e9ntica, recuperar\u00e1 los resultados de la cach\u00e9 de consultas en lugar de analizar y ejecutar la declaraci\u00f3n nuevamente. La cach\u00e9 de consultas se comparte entre sesiones, por lo que un conjunto de resultados generado por un cliente puede enviarse en respuesta a la misma consulta emitida por otro cliente.<\/p>\n Sin embargo, por grandioso que sea, el almacenamiento en cach\u00e9 de consultas tiene sus limitaciones. Tome la siguiente declaraci\u00f3n:<\/p>\n El problema aqu\u00ed es que las consultas contienen ciertas funciones no deterministas, como NOW() y RAND(). MySQL no puede calcular tales funciones por adelantado, por lo que terminan sin almacenarse en cach\u00e9.<\/p>\n Afortunadamente, hay una soluci\u00f3n f\u00e1cil para eso: puede almacenar los resultados de la funci\u00f3n en una variable.<\/p>\n Los archivos de volcado son muy enga\u00f1osos y pueden causar corrupci\u00f3n. \u00bfPor qu\u00e9? Si alguna vez ha visto los archivos de volcado creados por mysqldump, estar\u00e1 de acuerdo en que parecen archivos de texto normales e inofensivos. Es por eso que la mayor\u00eda de las personas los editan en un editor de texto est\u00e1ndar, lo que hace que aparezcan corrupciones.<\/p>\n Si alguna vez ha intentado editar archivos de volcado, r\u00e1pidamente aprendi\u00f3 que son cualquier cosa menos un archivo de texto. Por lo tanto, la \u00fanica forma garantizada de evitar problemas es dejar los archivos de volcado en paz.<\/p>\nSELECT columns FROM table WHERE customer_code like 'AK%'<\/code><\/p>\nSELECT columns FROM table WHERE left (customer_code,2)='AK\u2019<\/code><\/p>\n7 Use SQL SELECT * solo si es necesario<\/strong><\/h2>\n
8 Use la cl\u00e1usula ORDER BY solo si es necesario<\/strong><\/h2>\n
9 Elija un motor de base de datos adecuado<\/strong><\/h2>\n
10 Utilice la cl\u00e1usula EXISTS siempre que sea necesario<\/strong><\/h2>\n
If EXISTS(SELECT * from Table WHERE col=\u2019some value\u2019)<\/code><\/p>\nIf (SELECT count(*) from Table WHERE col=\u2019some value\u2019)>0<\/code><\/p>\n11 EXPLICA tus consultas SELECT<\/strong><\/h2>\n
12 Use LIMIT 1 cuando obtenga una fila \u00fanica<\/strong><\/h2>\n
\/\/ do I have anyusersfrom Alabama?<\/code><\/p>\n
\n$r = mysql_query(\u00abSELECCIONAR * DESDE usuario DONDE estado = ‘Alabama’");
\nif (mysql_num_rows($r) > 0) {
\n\/\/ \u2026
\n}<\/p>\n
\n$r = mysql_query(\u00abSELECCIONE 1 DEL usuario DONDE estado = ‘Alabama’ L\u00cdMITE 1");
\nsi (mysql_num_rows($r) > 0) {
\n\/\/ \u2026
\n}<\/p>\n13 Indexe y use los mismos tipos de columna para las uniones<\/strong><\/h2>\n
\/\/ looking for companies in my state $r = mysql_query(\"SELECT company_name FROM users LEFT JOIN companies ON (users.state = companies.state) WHERE users.id = $user_id\");<\/code><\/p>\n
\n\/\/ y ambas deben ser del mismo tipo y codificaci\u00f3n de caracteres
\n\/\/ o MySQL podr\u00eda realizar exploraciones de tablas completas<\/p>\n14 Ocultar MySQL de Internet<\/strong><\/h2>\n
15 Utilice los tipos de datos m\u00e1s peque\u00f1os posibles<\/strong><\/h2>\n
<\/a><\/p>\n16 Aproveche el almacenamiento en cach\u00e9 de consultas<\/strong><\/h2>\n
17 No editar archivos de volcado<\/strong><\/h2>\n
18 Use la configuraci\u00f3n de tama\u00f1o de bloque de MyISAM<\/strong><\/h2>\n
![\"22](\"https:\/\/wordpress.mediadoma.com\/wp-content\/uploads\/2022\/01\/post-206970-61e8d4b8518b8.jpg\")
<\/a><\/p>\n![\"22](\"https:\/\/wordpress.mediadoma.com\/wp-content\/uploads\/2022\/01\/post-206970-61e8d4b96bb8a.jpg\")
<\/a><\/p>\n