Ya que ofreciste una recompensa, compartiré mis secretos ganados con tanto esfuerzo...
En general, todos los SQL que ajusté hoy requerían el uso de subconsultas. Habiendo venido del mundo de la base de datos de Oracle, las cosas que daba por sentado no funcionaban igual con MySQL. Y mi lectura sobre el ajuste de MySQL me hace concluir que MySQL está detrás de Oracle en términos de optimización de consultas.
Si bien las consultas simples requeridas para la mayoría de las aplicaciones B2C pueden funcionar bien para MySQL, la mayoría de los tipos de consultas de informes agregados necesarios para los informes de inteligencia parecen requerir un poco de planificación y reorganización de las consultas SQL para guiar a MySQL a ejecutarlas más rápido.
Administración:
max_connections es el número de conexiones simultáneas. El valor predeterminado es 100 conexiones (151 desde 5.0), muy pequeño.
Nota:
las conexiones toman memoria y es posible que su sistema operativo no pueda manejar muchas conexiones.
Los binarios de MySQL para Linux/x86 le permiten tener hasta 4096 conexiones simultáneas, pero los binarios autocompilados a menudo tienen menos límite.
Configure table_cache para que coincida con el número de sus tablas abiertas y conexiones simultáneas. Observe el valor de open_tables y, si está creciendo rápidamente, deberá aumentar su tamaño.
Nota:
Los 2 parámetros anteriores pueden requerir muchos archivos abiertos. 20+max_connections+table_cache*2 es una buena estimación de lo que necesita. MySQL en Linux tiene una opción open_file_limit, establezca este límite.
Si tiene consultas complejas, es probable que sort_buffer_size y tmp_table_size sean muy importantes. Los valores dependerán de la complejidad de la consulta y los recursos disponibles, pero se recomiendan 4 Mb y 32 Mb, respectivamente, como puntos de partida.
Nota:estos son valores "por conexión", entre read_buffer_size, read_rnd_buffer_size y algunos otros, lo que significa que este valor podría ser necesario para cada conexión. Por lo tanto, tenga en cuenta su carga y los recursos disponibles al configurar estos parámetros. Por ejemplo, sort_buffer_size se asigna solo si MySQL necesita ordenar. Nota:tenga cuidado de no quedarse sin memoria.
Si tiene muchas conexiones establecidas (es decir, un sitio web sin conexiones persistentes), puede mejorar el rendimiento configurando thread_cache_size en un valor distinto de cero. 16 es un buen valor para empezar. Aumente el valor hasta que sus threads_created no crezcan muy rápidamente.
CLAVE PRINCIPAL:
Solo puede haber una columna AUTO_INCREMENT por tabla, debe estar indexada y no puede tener un valor DEFAULT
CLAVE es normalmente un sinónimo de ÍNDICE. El atributo clave PRIMARY KEY también se puede especificar como solo KEY cuando se proporciona en una definición de columna. Esto se implementó para la compatibilidad con otros sistemas de bases de datos.
UNA CLAVE PRINCIPAL es un índice único en el que todas las columnas clave deben definirse como NO NULAS
Si un índice PRIMARY KEY o UNIQUE consta de una sola columna que tiene un tipo de número entero, también puede hacer referencia a la columna como "_rowid" en las instrucciones SELECT.
En MySQL, el nombre de PRIMARY KEY es PRIMARY
Actualmente, solo las tablas InnoDB (¿v5.1?) admiten claves foráneas.
Por lo general, crea todos los índices que necesita cuando crea tablas. Se indexará cualquier columna declarada como PRIMARY KEY, KEY, UNIQUE o INDEX.
NULL significa "no tener un valor". Para probar NULL, no puede utilice los operadores de comparación aritméticos como =,
NO_AUTO_VALUE_ON_ZERO suprime el incremento automático de 0 para que solo NULL genere el siguiente número de secuencia. Este modo puede ser útil si se ha almacenado 0 en la columna AUTO_INCREMENT de una tabla. (Almacenar 0 no es una práctica recomendada, por cierto).
Para cambiar el valor del contador AUTO_INCREMENT que se usará para nuevas filas:
ALTER TABLE mytable AUTO_INCREMENT = value;
oSET INSERT_ID =valor;
A menos que se especifique lo contrario, el valor comenzará con:1000000 o especifíquelo así:
...) MOTOR=MiISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=1
MARCAS DE TIEMPO:
Los valores de las columnas TIMESTAMP se convierten de la zona horaria actual a UTC para el almacenamiento y de UTC a la zona horaria actual para la recuperación.
http://dev.mysql.com/doc/refman/5.1 /es/timestamp.html Para una columna TIMESTAMP en una tabla, puede asignar la marca de tiempo actual como el valor predeterminado y el valor de actualización automática.
una cosa a tener en cuenta al usar uno de estos tipos en una cláusula WHERE, es mejor hacer WHERE datecolumn =FROM_UNIXTIME (1057941242) y notWHERE UNIX_TIMESTAMP (datecolumn) =1057941242. hacer lo último no aprovechará un índice en eso columna.
http://dev.mysql.com /doc/refman/5.1/es/funciones-de-fecha-y-hora.html
UNIX_TIMESTAMP()
FROM_UNIXTIME()
UTC_DATE()
UTC_TIME()
UTC_TIMESTAMP()
si convierte una fecha y hora en una marca de tiempo de Unix en MySQL:
Y luego le agrega 24 horas:
Y luego la vuelve a convertir a una fecha y hora, ¡por arte de magia pierde una hora!
Esto es lo que está pasando. Cuando se vuelve a convertir la marca de tiempo de Unix en una fecha y hora, se tiene en cuenta la zona horaria y sucede que entre el 28 y el 29 de octubre de 2006 salimos del horario de verano y perdimos una hora.
A partir de MySQL 4.1.3, las funciones CURRENT_TIMESTAMP(), CURRENT_TIME(), CURRENT_DATE() y FROM_UNIXTIME() devuelven valores en la zona horaria actual de la conexión. , que está disponible como el valor de la variable de sistema time_zone. Además, UNIX_TIMESTAMP() asume que su argumento es un valor de fecha y hora en la zona horaria actual.
La configuración de la zona horaria actual no afecta los valores mostrados por funciones como UTC_TIMESTAMP() o los valores en las columnas DATE, TIME o DATETIME.
NOTA:EN LA ACTUALIZACIÓN SOLO actualiza el DateTime si se cambia un campo. Si una ACTUALIZACIÓN da como resultado que no se cambie ningún campo, ¡entonces el DateTime NO se actualiza!
Además, el primer TIMESTAMP siempre es AUTOUPDATE de forma predeterminada, incluso si no se especifica
Cuando trabajo con fechas, casi siempre uso la fecha juliana porque la matemática de datos es entonces una simple cuestión de sumar o restar números enteros, y los segundos desde la medianoche por la misma razón. Es raro que necesite una resolución de tiempo de granularidad más fina que segundos.
Ambos pueden almacenarse como un número entero de 4 bytes, y si el espacio es realmente reducido, se pueden combinar en tiempo UNIX (segundos desde la época del 1/1/1970) como un número entero sin signo que será bueno hasta alrededor de 2106 como:
' segundos en 24 horas =86400
' Entero con signo max val =2,147,483,647 - puede contener 68 años de segundos
' Unsigned Integer max val =4,294,967,295 - puede contener 136 años de segundos
Protocolo binario:
MySQL 4.1 introdujo un protocolo binario que permite enviar y devolver valores de datos que no son cadenas en formato nativo sin conversión hacia y desde formato de cadena. (Muy útil)
Aparte, mysql_real_query() es más rápido que mysql_query() porque no llama a strlen() para operar en la cadena de sentencia.
http://dev.mysql.com/tech-resources /articles/4.1/prepared-statements.html El protocolo binario admite declaraciones preparadas del lado del servidor y permite la transmisión de valores de datos en formato nativo. El protocolo binario se revisó bastante durante las versiones anteriores de MySQL 4.1.
Puede usar la macro IS_NUM() para probar si un campo tiene un tipo numérico. Pase el valor de tipo a IS_NUM() y se evalúa como VERDADERO si el campo es numérico:
Una cosa a tener en cuenta es que los datos binarios PUEDEN se enviará dentro de una consulta regular si la escapa y recuerda que MySQL requiere solo que la barra invertida y el carácter de comillas se escapen. Así que esa es una manera muy fácil de INSERTAR cadenas binarias más cortas como contraseñas cifradas/saladas, por ejemplo.
Servidor maestro:
http://www.experts-exchange.com/Database/MySQL/Q_22967482 .html
http://www.databasejournal.com/features/mysql/article.php /10897_3355201_2
CONCEDER ESCLAVO DE REPLICACIÓN EN . a slave_user IDENTIFICADO POR 'slave_password'
#Master Binary Logging Config STATEMENT causes replication
to be statement-based - default
log-bin=Mike
binlog-format=STATEMENT
server-id=1
max_binlog_size = 10M
expire_logs_days = 120
#Slave Config
master-host=master-hostname
master-user=slave-user
master-password=slave-password
server-id=2
El archivo de registro binario debe leer:
http://dev.mysql.com/doc/refman /5.0/es/binary-log.html
http://www.mydigitallife.info/2007/10/06/how-to-read-mysql-binary-log-files-binlog-with-mysqlbinlog/
http://dev.mysql.com/doc/refman/5.1 /es/mysqlbinlog.html
http://dev.mysql.com/doc/refman /5.0/es/binary-log.html
http://dev.mysql.com/doc /refman/5.1/en/binary-log-setting.html
Puede eliminar todos los archivos de registro binarios con la instrucción RESET MASTER o un subconjunto de ellos con PURGE MASTER
--result-file=binlog.txt TrustedFriend-bin.000030
Normalización:
http://dev.mysql.com/tech-resources /articulos/introduccion-a-la-normalizacion.html
Funciones UDF
http://www.koders.com/cpp/fid10666379322B54AD41AEB0E4100D87C8CDDF1D8>C.aspx
http://souptonuts.sourceforge.net/readme_mysql.htm
Tipos de datos:
http://dev.mysql.com/doc/refman /5.1/es/requisitos-de-almacenamiento.html
http://www.informit.com/articles/article.aspx ?p=1238838&seqNum=2
http://bitfilm. net/2008/03/24/ahorro-bytes-eficiente-almacenamiento-de-datos-mysql-parte-1/
Una cosa a tener en cuenta es que en una tabla mixta con CHAR y VARCHAR, mySQL cambiará los CHAR a VARCHAR
RecNum integer_type SIN FIRMAR NO NULO AUTO_INCREMENTO, CLAVE PRINCIPAL (RecNum)
MySQL siempre representa las fechas con el año primero, de acuerdo con las especificaciones estándar de SQL e ISO 8601
Varios:
Desactivar algunas funciones de MySQl dará como resultado archivos de datos más pequeños y un acceso más rápido. Por ejemplo:
--datadir especificará el directorio de datos y
--skip-innodb desactivará la opción inno y le ahorrará entre 10 y 20 millones
Más aquíhttp://dev.mysql.com/tech -resources/articles/mysql-c-api.html
Descargar Capítulo 7 - Gratis
InnoDB es transaccional, pero conlleva una sobrecarga de rendimiento. He descubierto que las tablas MyISAM son suficientes para el 90 % de mis proyectos. Las tablas que no son seguras para transacciones (MyISAM) tienen varias ventajas propias, todas las cuales ocurren porque:
no hay gastos generales de transacción:
Mucho más rápido
Menores requisitos de espacio en disco
Se requiere menos memoria para realizar actualizaciones
Cada tabla MyISAM se almacena en el disco en tres archivos. Los archivos tienen nombres que comienzan con el nombre de la tabla y tienen una extensión para indicar el tipo de archivo. Un archivo .frm almacena el formato de la tabla. El archivo de datos tiene una extensión .MYD (MYData). El archivo de índice tiene una extensión .MYI (MYIndex).
Estos archivos pueden copiarse en una ubicación de almacenamiento intacta sin utilizar la función de copia de seguridad de administradores de MySQL, que consume mucho tiempo (al igual que la restauración)
El truco es hacer una copia de estos archivos y luego DROP la tabla. Cuando devuelva los archivos, MySQl los reconocerá y actualizará el seguimiento de la tabla.
Si debe hacer una copia de seguridad/restaurar,
Restaurar una copia de seguridad o importar desde un archivo de volcado existente puede llevar mucho tiempo dependiendo de la cantidad de índices y claves principales que tenga en cada tabla. Puede acelerar este proceso drásticamente modificando su archivo de volcado original rodeándolo con lo siguiente:
SET AUTOCOMMIT = 0;
SET FOREIGN_KEY_CHECKS=0;
.. your dump file ..
SET FOREIGN_KEY_CHECKS = 1;
COMMIT;
SET AUTOCOMMIT = 1;
Para aumentar considerablemente la velocidad de la recarga, agregue el comando SQL SET AUTOCOMMIT =0; al principio del archivo de volcado y agregue COMMIT; mando hasta el final.
De forma predeterminada, la confirmación automática está activada, lo que significa que todos y cada uno de los comandos de inserción en el archivo de volcado se tratarán como una transacción separada y se escribirán en el disco antes de que se inicie el siguiente. Si no agrega estos comandos, recargar una base de datos grande en InnoDB puede llevar muchas horas...
El tamaño máximo de una fila en una tabla MySQL es de 65 535 bytes
La longitud máxima efectiva de un VARCHAR en MySQL 5.0.3 y en adelante =tamaño máximo de fila (65 535 bytes)
Los valores VARCHAR no se rellenan cuando se almacenan. Los espacios finales se conservan cuando los valores se almacenan y recuperan, de conformidad con SQL estándar.
Los valores CHAR y VARCHAR en MySQL se comparan sin tener en cuenta los espacios finales.
El uso de CHAR solo acelerará su acceso si todo el registro tiene un tamaño fijo. Es decir, si usa cualquier objeto de tamaño variable, también podría hacerlos todos de tamaño variable. No gana velocidad usando un CHAR en una tabla que también contiene un VARCHAR.
El límite VARCHAR de 255 caracteres se elevó a 65535 caracteres a partir de MySQL 5.0.3
Las búsquedas de texto completo solo se admiten para tablas MyISAM.
http://dev.mysql.com/doc/refman /5.0/en/fulltext-search.html
Las columnas BLOB no tienen juego de caracteres, y la clasificación y la comparación se basan en los valores numéricos de los bytes en los valores de la columna
Si el modo SQL estricto no está habilitado y asigna un valor a una columna BLOB o TEXT que excede la longitud máxima de la columna, el valor se trunca para que quepa y se genera una advertencia.
Comandos útiles:
verifique el modo estricto:SELECCIONE @@global.sql_mode;
desactivar el modo estricto:
SET @@global.sql_mode='';
ESTABLECER @@global.sql_mode='MYSQL40'
o eliminar:sql-mode="STRICT_TRANS_TABLES,...
MOSTRAR COLUMNAS DE mytable
SELECCIONE max(namecount) COMO virtualcolumn DESDE mytable ORDEN POR virtualcolumn
http://dev.mysql.com /doc/refman/5.0/es/agrupar-por-campos-ocultos.html
http://dev.mysql .com/doc/refman/5.1/en/information-functions.html#function_last-insert-id último_insertar_id()
obtiene el PK de la última fila insertada en el subproceso actual max(pkcolname) obtiene el último PK en general.
Nota:si la tabla está vacía, max(pkcolname) devuelve 1 mysql_insert_id() convierte el tipo de retorno de la función mysql_insert_id() nativa de la API C de MySQL en un tipo de long (llamado int en PHP).
Si su columna AUTO_INCREMENT tiene un tipo de columna BIGINT, el valor devuelto por mysql_insert_id() será incorrecto. En su lugar, utilice la función MySQL SQL interna LAST_INSERT_ID() en una consulta SQL.
http://dev.mysql .com/doc/refman/5.0/en/information-functions.html#function_last-insert-id
Solo tenga en cuenta que cuando intenta insertar datos en una tabla y obtiene el error:
Unknown column ‘the first bit of data what you want to put into the table‘ in ‘field list’
usando algo como
INSERT INTO table (this, that) VALUES ($this, $that)
es porque no tiene apóstrofes alrededor de los valores que está tratando de colocar en la tabla. Entonces deberías cambiar tu código a:
INSERT INTO table (this, that) VALUES ('$this', '$that')
recordatorio de que `` se utilizan para definir campos, bases de datos o tablas de MySQL, no valores;)
Se perdió la conexión con el servidor durante la consulta:
http://dev.mysql.com/doc/refman /5.1/es/desaparecido.html
http://dev.mysql.com/doc /refman/5.1/en/paquete-demasiado-grande.html
http://dev.mysql.com/doc/refman /5.0/es/parámetros-del-servidor.html
http://dev.mysql.com/doc/refman /5.1/es/mostrar-variables.html
http://dev.mysql.com/doc/refman /5.1/es/option-files.html
http://dev.mysql.com/doc/refman /5.1/es/error-log.html
Consultas de ajuste
http://www.artfulsoftware.com/infotree/queries.php?&bw =1313
Bueno, creo que eso debería ser suficiente para ganar el bono... Los frutos de muchas horas y muchos proyectos con un gran gratis base de datos. Desarrollo servidores de datos de aplicaciones en plataformas Windows principalmente con MySQL. El peor lío que tuve que arreglar fue
La última pesadilla de la base de datos heredada de MySQL
Esto requirió una serie de aplicaciones para procesar las tablas en algo útil usando muchos de los trucos mencionados aquí.
Si encuentra esto increíblemente útil, exprese su agradecimiento votando a favor.
Consulte también mis otros artículos y libros blancos en:www.coastrd.com
