Dato che hai messo una taglia, condividerò i miei segreti conquistati duramente...
In generale, tutti gli SQL che ho ottimizzato oggi richiedevano l'utilizzo di sottoquery. Venendo dal mondo dei database Oracle, le cose che davo per scontate non funzionavano allo stesso modo con MySQL. E la mia lettura sull'ottimizzazione di MySQL mi fa concludere che MySQL è alla base di Oracle in termini di ottimizzazione delle query.
Sebbene le query semplici richieste per la maggior parte delle applicazioni B2C possano funzionare bene per MySQL, la maggior parte del tipo di query di reporting aggregato necessarie per Intelligence Reporting sembra richiedere un bel po' di pianificazione e riorganizzazione delle query SQL per guidare MySQL a eseguirle più velocemente.
Amministrazione:
max_connections è il numero di connessioni simultanee. Il valore predefinito è 100 connessioni (151 dalla 5.0) - molto piccolo.
Nota:
le connessioni richiedono memoria e il tuo sistema operativo potrebbe non essere in grado di gestire molte connessioni.
I binari MySQL per Linux/x86 ti consentono di avere fino a 4096 connessioni simultanee, ma i binari autocompilati spesso hanno un limite inferiore.
Imposta table_cache in modo che corrisponda al numero delle tue tabelle aperte e delle connessioni simultanee. Osserva il valore di open_tables e se sta crescendo rapidamente dovrai aumentarne le dimensioni.
Nota:
I 2 parametri precedenti potrebbero richiedere molti file aperti. 20+max_connections+table_cache*2 è una buona stima per ciò di cui hai bisogno. MySQL su Linux ha un'opzione open_file_limit, imposta questo limite.
Se hai query complesse sort_buffer_size e tmp_table_size sono probabilmente molto importanti. I valori dipenderanno dalla complessità della query e dalle risorse disponibili, ma rispettivamente 4 Mb e 32 Mb sono punti di partenza consigliati.
Nota:questi sono valori "per connessione", tra read_buffer_size, read_rnd_buffer_size e alcuni altri, il che significa che questo valore potrebbe essere necessario per ogni connessione. Quindi, considera il tuo carico e la tua risorsa disponibile quando imposti questi parametri. Ad esempio, sort_buffer_size viene allocato solo se MySQL deve eseguire un ordinamento. Nota:fai attenzione a non esaurire la memoria.
Se hai stabilito molte connessioni (cioè un sito web senza connessioni persistenti) potresti migliorare le prestazioni impostando thread_cache_size su un valore diverso da zero. 16 è un buon valore per cominciare. Aumenta il valore fino a quando i tuoi threads_created non crescono molto rapidamente.
CHIAVE PRIMARIA:
Può esserci una sola colonna AUTO_INCREMENT per tabella, deve essere indicizzata e non può avere un valore DEFAULT
KEY è normalmente un sinonimo di INDEX. L'attributo chiave PRIMARY KEY può anche essere specificato solo come KEY quando fornito in una definizione di colonna. Questo è stato implementato per la compatibilità con altri sistemi di database.
Una CHIAVE PRIMARIA è un indice univoco in cui tutte le colonne chiave devono essere definite come NOT NULL
Se una CHIAVE PRIMARIA o un indice UNIQUE è costituito da una sola colonna che ha un tipo intero, puoi anche fare riferimento alla colonna come "_rowid" nelle istruzioni SELECT.
In MySQL, il nome di una CHIAVE PRIMARIA è PRIMARY
Attualmente, solo le tabelle InnoDB (v5.1?) supportano le chiavi esterne.
Di solito, crei tutti gli indici di cui hai bisogno quando crei le tabelle. Qualsiasi colonna dichiarata come PRIMARY KEY, KEY, UNIQUE o INDEX verrà indicizzata.
NULL significa "non avere un valore". Per testare NULL, non puoi utilizzare gli operatori di confronto aritmetico come =,
NO_AUTO_VALUE_ON_ZERO sopprime l'incremento automatico per 0 in modo che solo NULL generi il numero di sequenza successivo. Questa modalità può essere utile se 0 è stato memorizzato nella colonna AUTO_INCREMENT di una tabella. (Memorizzare 0 non è una pratica consigliata, tra l'altro.)
Per modificare il valore del contatore AUTO_INCREMENT da utilizzare per le nuove righe:
ALTER TABLE mytable AUTO_INCREMENT = value;
oSET INSERT_ID =valore;
Se non diversamente specificato, il valore inizierà con:1000000 o specificarlo così:
...) MOTORE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=1
TIMESTAMP:
I valori per le colonne TIMESTAMP vengono convertiti dal fuso orario corrente in UTC per l'archiviazione e da UTC al fuso orario corrente per il recupero.
http://dev.mysql.com/doc/refman/5.1 /it/timestamp.html Per una colonna TIMESTAMP in una tabella, puoi assegnare il timestamp corrente come valore predefinito e il valore di aggiornamento automatico.
una cosa a cui prestare attenzione quando si utilizza uno di questi tipi in una clausola WHERE, è meglio doWHERE datecolumn =FROM_UNIXTIME(1057941242) e notWHERE UNIX_TIMESTAMP(datecolumn) =1057941242. quest'ultimo non trarrà vantaggio da un indice su quello colonna.
http://dev.mysql.com /doc/refman/5.1/en/funzioni-di-data-e-ora.html
UNIX_TIMESTAMP()
FROM_UNIXTIME()
UTC_DATE()
UTC_TIME()
UTC_TIMESTAMP()
se converti un datetime in unix timestamp in MySQL:
E poi aggiungi 24 ore:
E poi riconvertilo in datetime, perde magicamente un'ora!
Ecco cosa sta succedendo. Quando si converte il timestamp unix in un datetime, viene preso in considerazione il fuso orario e succede che tra il 28 e il 29 ottobre 2006 siamo passati all'ora legale e abbiamo perso un'ora.
A partire da MySQL 4.1.3, le funzioni CURRENT_TIMESTAMP(), CURRENT_TIME(), CURRENT_DATE() e FROM_UNIXTIME() restituiscono valori nel fuso orario corrente della connessione , disponibile come valore della variabile di sistema time_zone. Inoltre, UNIX_TIMESTAMP() presuppone che il suo argomento sia un valore datetime nel fuso orario corrente.
L'impostazione del fuso orario corrente non influisce sui valori visualizzati da funzioni come UTC_TIMESTAMP() o sui valori nelle colonne DATE, TIME o DATETIME.
NOTA:IN AGGIORNAMENTO SOLO aggiorna DateTime se un campo viene modificato Se un UPDATE non comporta la modifica dei campi, DateTime NON viene aggiornato!
Inoltre, il primo TIMESTAMP è sempre AUTOUPDATE per impostazione predefinita anche se non specificato
Quando lavoro con Date, mi rivolgo quasi sempre a Julian Date perché la matematica dei dati è quindi una semplice questione di aggiungere o sottrarre numeri interi e Secondi da mezzanotte per lo stesso motivo. È raro che io abbia bisogno di una risoluzione temporale di una granularità più fine dei secondi.
Entrambi possono essere archiviati come un intero di 4 byte e, se lo spazio è davvero stretto, possono essere combinati nel tempo UNIX (secondi dall'epoca 1/1/1970) come un intero senza segno che sarà valido fino al 2106 circa come:
' secondi in 24 ore =86400
' Intero con segno max val =2.147.483.647 - può contenere 68 anni di secondi
' Intero senza segno max val =4.294.967.295 - può contenere 136 anni di secondi
Protocollo binario:
MySQL 4.1 ha introdotto un protocollo binario che consente di inviare e restituire valori di dati non stringa in formato nativo senza conversione da e verso il formato stringa. (Molto utile)
A parte, mysql_real_query() è più veloce di mysql_query() perché non chiama strlen() per operare sulla stringa dell'istruzione.
http://dev.mysql.com/tech-resources /articles/4.1/preparate-statements.html Il protocollo binario supporta istruzioni preparate lato server e consente la trasmissione di valori di dati in formato nativo. Il protocollo binario ha subito parecchie revisioni durante le versioni precedenti di MySQL 4.1.
Puoi utilizzare la macro IS_NUM() per verificare se un campo ha un tipo numerico. Passa il valore del tipo a IS_NUM() e restituisce TRUE se il campo è numerico:
Una cosa da notare è che i dati binari CAN essere inviato all'interno di una normale query se esci e ricordi che MySQL richiede solo quella barra rovesciata e il carattere di virgolette devono essere preceduti da escape. Quindi questo è un modo davvero semplice per INSERIRE stringhe binarie più brevi come password crittografate/saltate, ad esempio.
Server principale:
http://www.experts-exchange.com/Database/MySQL/Q_22967482 .html
http://www.databasejournal.com/features/mysql/article.php /10897_3355201_2
CONCEDERE REPLICA SLAVE SU . a slave_user IDENTIFICATO DA '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
Il file di registro binario deve leggere:
http://dev.mysql.com/doc/refman /5.0/en/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 /it/mysqlbinlog.html
http://dev.mysql.com/doc/refman /5.0/en/binary-log.html
http://dev.mysql.com/doc /refman/5.1/en/impostazione-log-binario.html
È possibile eliminare tutti i file di registro binari con l'istruzione RESET MASTER o un sottoinsieme di essi con PURGE MASTER
--result-file=binlog.txt TrustedFriend-bin.000030
Normalizzazione:
http://dev.mysql.com/tech-resources /articoli/introduzione-alla-normalizzazione.html
Funzioni UDF
http://www.koders.com/cpp/fid10666379322B54AD41AEB0E4100D87C8CDDF1D8>
http://souptonuts.sourceforge.net/readme_mysql.htm
Tipi di dati:
http://dev.mysql.com/doc/refman /5.1/en/requisiti-di-archiviazione.html
http://www.informit.com/articles/article.aspx ?p=1238838&seqNum=2
http://bitfilm. net/2008/03/24/saving-bytes-efficient-data-storage-mysql-part-1/
Una cosa da notare è che su una tabella mista con CHAR e VARCHAR, mySQL cambierà i CHAR in VARCHAR
RecNum intero_type UNSIGNED NOT NULL AUTO_INCREMENT, PRIMARY KEY (RecNum)
MySQL rappresenta sempre le date con l'anno prima, in conformità con le specifiche standard SQL e ISO 8601
Varie:
La disattivazione di alcune funzionalità MySQl comporterà file di dati più piccoli e un accesso più rapido. Ad esempio:
--datadir specificherà la directory dei dati e
--skip-innodb disattiverà l'opzione inno e ti farà risparmiare 10-20 milioni
Maggiori informazioni quihttp://dev.mysql.com/tech -resources/articles/mysql-c-api.html
Scarica Capitolo 7 - Gratuito
InnoDB è transazionale ma ne deriva un sovraccarico di prestazioni. Ho riscontrato che le tabelle MyISAM sono sufficienti per il 90% dei miei progetti. Le tabelle non sicure per le transazioni (MyISAM) presentano diversi vantaggi, che si verificano tutti perché:
non ci sono spese generali di transazione:
Molto più veloce
Requisiti di spazio su disco inferiori
Meno memoria richiesta per eseguire gli aggiornamenti
Ogni tabella MyISAM è memorizzata su disco in tre file. I file hanno nomi che iniziano con il nome della tabella e hanno un'estensione per indicare il tipo di file. Un file .frm memorizza il formato della tabella. Il file di dati ha un'estensione .MYD (MYData). Il file di indice ha un'estensione .MYI (MYIndex).
Questi file possono essere copiato in una posizione di archiviazione intatta senza utilizzare la funzione MySQL Administrators Backup che richiede molto tempo (così come il ripristino)
Il trucco è fare una copia di questi file e poi DROP il tavolo. Quando rimetti i file MySQl li riconoscerà e aggiornerà il tracciamento della tabella.
Se devi eseguire il backup/ripristino,
Il ripristino di un backup o l'importazione da un file di dump esistente può richiedere molto tempo a seconda del numero di indici e chiavi primarie presenti in ciascuna tabella. Puoi accelerare notevolmente questo processo modificando il file di dump originale circondandolo con quanto segue:
SET AUTOCOMMIT = 0;
SET FOREIGN_KEY_CHECKS=0;
.. your dump file ..
SET FOREIGN_KEY_CHECKS = 1;
COMMIT;
SET AUTOCOMMIT = 1;
Per aumentare notevolmente la velocità di ricarica, aggiungi il comando SQL SET AUTOCOMMIT =0; all'inizio del file di dump e aggiungere il COMMIT; comando fino alla fine.
Per impostazione predefinita, l'autocommit è attivo, il che significa che ogni singolo comando di inserimento nel file dump verrà trattato come una transazione separata e scritto su disco prima dell'avvio del successivo. Se non aggiungi questi comandi, ricaricare un database di grandi dimensioni in InnoDB può richiedere molte ore...
La dimensione massima di una riga in una tabella MySQL è 65.535 byte
La lunghezza massima effettiva di un VARCHAR in MySQL 5.0.3 e su =dimensione massima della riga (65.535 byte)
I valori VARCHAR non vengono riempiti quando vengono archiviati. Gli spazi finali vengono mantenuti quando i valori vengono archiviati e recuperati, in conformità con lo standard SQL.
I valori CHAR e VARCHAR in MySQL vengono confrontati indipendentemente dagli spazi finali.
L'utilizzo di CHAR accelererà il tuo accesso solo se l'intero record è di dimensioni fisse. Cioè, se usi qualsiasi oggetto di dimensioni variabili, potresti anche renderli tutti di dimensioni variabili. Non guadagni velocità usando un CHAR in una tabella che contiene anche un VARCHAR.
Il limite VARCHAR di 255 caratteri è stato portato a 65535 caratteri a partire da MySQL 5.0.3
Le ricerche full-text sono supportate solo per le tabelle MyISAM.
http://dev.mysql.com/doc/refman /5.0/en/ricerca-testo-intero.html
Le colonne BLOB non hanno set di caratteri e l'ordinamento e il confronto si basano sui valori numerici dei byte nei valori delle colonne
Se la modalità SQL rigoroso non è abilitata e si assegna un valore a una colonna BLOB o TEXT che supera la lunghezza massima della colonna, il valore viene troncato per adattarsi e viene generato un avviso.
Comandi utili:
controlla la modalità rigorosa:SELECT @@global.sql_mode;
disattivare la modalità rigorosa:
SET @@global.sql_mode='';
SET @@global.sql_mode='MYSQL40'
o rimuovi:sql-mode="STRICT_TRANS_TABLES,...
MOSTRA COLONNE DA mytable
SELEZIONA max(numero nomi) COME virtualcolumn DA mytable ORDINE PER virtualcolumn
http://dev.mysql.com /doc/refman/5.0/en/group-by-hidden-fields.html
http://dev.mysql .com/doc/refman/5.1/en/information-functions.html#function_last-insert-id last_insert_id()
ti ottiene il PK dell'ultima riga inserita nel thread corrente max(pkcolname) ti ottiene l'ultimo PK in generale.
Nota:se la tabella è vuota max(pkcolname) restituisce 1 mysql_insert_id() converte il tipo restituito della funzione nativa dell'API C MySQL mysql_insert_id() in un tipo oflong (denominato int in PHP).
Se la colonna AUTO_INCREMENT ha un tipo di colonna BIGINT, il valore restituito damysql_insert_id() non sarà corretto. Utilizzare invece la funzione SQL interna di MySQL LAST_INSERT_ID() in una query SQL.
http://dev.mysql .com/doc/refman/5.0/en/information-functions.html#function_last-insert-id
Solo una nota che quando stai tentando di inserire dati in una tabella e ricevi l'errore:
Unknown column ‘the first bit of data what you want to put into the table‘ in ‘field list’
usando qualcosa come
INSERT INTO table (this, that) VALUES ($this, $that)
è perché non hai apostrofi attorno ai valori che stai cercando di attaccare al tavolo. Quindi dovresti cambiare il tuo codice in:
INSERT INTO table (this, that) VALUES ('$this', '$that')
ricorda che `` sono usati per definire campi, database o tabelle MySQL, non valori;)
Connessione al server persa durante la query:
http://dev.mysql.com/doc/refman /5.1/it/andato via.html
http://dev.mysql.com/doc /refman/5.1/en/pacchetto-troppo-grande.html
http://dev.mysql.com/doc/refman /5.0/en/parametri-server.html
http://dev.mysql.com/doc/refman /5.1/en/show-variables.html
http://dev.mysql.com/doc/refman /5.1/en/file-opzioni.html
http://dev.mysql.com/doc/refman /5.1/en/log-errori.html
Ricerca di ottimizzazione
http://www.artfulsoftware.com/infotree/queries.php?&bw =1313
Ebbene dovrebbe bastare per guadagnare il bonus direi... I frutti di tante ore e tanti progetti con un ottimo gratuito Banca dati. Sviluppo server di dati applicativi su piattaforme Windows principalmente con MySQL. Il peggior pasticcio che ho dovuto sistemare è stato
L'ultimo incubo del database legacy MySQL
Ciò ha richiesto una serie di applicazioni per elaborare le tabelle in qualcosa di utile utilizzando molti dei trucchi menzionati qui.
Se l'hai trovato straordinariamente utile, esprimi i tuoi ringraziamenti votandolo.
Dai un'occhiata anche ai miei altri articoli e white paper su:www.coastrd.com
