Una buona specifica del database aiuta a ridurre la complessità dell'implementazione del software e a ridurre i costi di comunicazione.
1. La legge di ferro della costruzione di un magazzino
- | Legge di ferro | Livello | osservazione | Set di caratteri | Usa UTF-8. Se l'emoji è memorizzata, usa utf8mb4 per lo storage. | forzato |
| | Regole di smistamento | Usa utf8_general_ci | forzato | |
2. La legge ferrea della costruzione dei tavoli
- | Legge di ferro | Livello | osservazione | esegesi | Assicurati di avere annotazioni sul campo. | forzato |
| | codificare | Usa UTF-8. Se l'emoji è memorizzata, usa utf8mb4 per lo storage. | forzato |
| | se il campo è concettuale | Deve essere chiamato con is_xx, e il tipo di dato è unsigned tinyint (1 sì, 0 no), ad esempio is_deleted(1 elimina, 0 non eliminato). | forzato | Qualsiasi campo deve essere senza segno se non è negativo | Nome della tabella, nome del campo | Si possono usare solo lettere minuscole, sottolinee o numeri; È vietato iniziare con una sottolinea o un numero; Solo i numeri sono vietati tra due sottolinee; Disabilita le parole riservate; L'uso dei sostantivi plurali è vietato nei nomi delle tabelle. | forzato |
| | La denominazione del nome del database e del nome della tabella | Il nome del database dovrebbe essere coerente con il nome dell'applicazione, e il nome della tabella dovrebbe essere indicato con Name_Role Business della tabella. | forzato |
| | Denominazione degli indici | L'indice chiave primaria utilizza pk_ nome del campo; Indice unico con uk_ nome del campo; Gli indici normali utilizzano idx_ nomi di campi. | forzato | pk_ è la chiave primaria; uk_ è una tonalità unica; idx_ è indice | Tipo decimale | Il tipo di dato è decimale, e l'uso di float e double è vietato; float e double hanno perdita di precisione, e se l'intervallo di dati memorizzati supera quello decimale, si raccomanda di dividere i dati in interi e decimali e memorizzarli separatamente. | forzato |
| | Tipo Varchar | varchar è una stringa variabile lunga, non viene allocato spazio di archiviazione in anticipo, la lunghezza non dovrebbe superare i 5000 caratteri; se la lunghezza è superiore a 5000, applica il testo (crea una tabella separata, usa la chiave primaria per corrispondere, per evitare di influenzare l'efficienza di indicizzazione di altri campi). | forzato |
| | Devono esserci tre campi nel nome della tabella | ID (il tipo di dato è bigint senza segno, incremento di tabella singola, dimensione del passo è 1), gmt_create, gmt_modified (tempo di creazione attiva, tempo di aggiornamento passivo, tipo di dato è datatime). | forzato |
| | Ridondanza del campo | I campi permettono una ridondanza appropriata, ma bisogna considerare la coerenza dei dati, e i campi ridondanti dovrebbero avere 1) modifiche poco frequenti; 2) Non un campo varchar super lungo, figuriamoci un campo di testo. | Consigliato |
| | Dividere il database e le tabelle | La partizionazione è raccomandata solo quando il numero di righe in una singola tabella supera i 5 milioni di righe o la capacità di una singola tabella supera i 2 GB. | Consigliato | |
Impostare la lunghezza di archiviazione dei caratteri appropriata non solo fa risparmiare spazio nelle tabelle del database e nell'indice, ma, cosa più importante, migliora la velocità di recupero.
3. Stabilire una legge di ferro indice
- | Legge di ferro | Livello | osservazione | Indice unico | I campi con caratteristiche uniche nell'azienda, anche se sono una combinazione di campi, devono essere indicizzati in modo univoco. Sebbene l'indice unico influenzi la velocità dell'inserimento, questa perdita è trascurabile, ma migliora significativamente la velocità di interrogazione. Inoltre, anche se il livello applicativo ha un controllo di controllo molto completo, finché non esiste un indice univoco, secondo la Legge di Murphy, inevitabilmente verranno generati dati compromettiti. | forzato |
| | Unisciti | Più di tre tabelle vietano il joining, campi che richiedono join e i tipi di dati devono essere coerenti; Quando più tabelle sono associate alle query, assicurati che i campi associati debbano avere un indice. Anche se hai una doppia unione di tabelle, presta attenzione all'indicizzazione delle tabelle e alle prestazioni SQL. | forzato |
| | Varcharfield | La lunghezza dell'indice deve essere specificata, e non è necessario indicizzare tutti i campi, basta determinare la lunghezza dell'indice in base alla distinzione effettiva del testo. La lunghezza dell'indice e la distinzione sono una coppia di contraddizioni; generalmente per i dati di tipo di stringa, gli indici con una lunghezza di 20 avranno un grado di distinzione superiore al 90%, che può essere determinato dal grado di distinzione di count(distinct left(nome colonna, lunghezza dell'indice)))/count(*). | forzato |
| | La sfocatura è vietata nella ricerca delle pagine | La ricerca sulla pagina vieta la sfocatura completa o sfocatura; se necessario, si prega di rivolgersi al motore di ricerca per risolverla. Motivo di divieto: Il file indice ha la proprietà di corrispondenza del prefisso più a sinistra dell'albero B, e se il valore a sinistra non viene determinato, allora questo indice non può essere usato. | forzato |
| | Ordine per | Se esiste un ordine per scenario, presta attenzione all'ordine dell'indice. L'ultimo campo di ordine per fa parte dell'indice combinato ed è posizionato alla fine dell'ordine di combinazione dell'indice per evitare file_sort e influenzare le prestazioni delle query. Esempio: dove a=? e b=? ordine da c; L'indice dovrebbe essere costruito come a_b_c; Controesempio: Se c'è una ricerca di intervallo nell'indice, allora l'ordine dell'indice non può essere utilizzato, ad esempio dove a>10 ordina per b; L'indice a_b non può essere ordinato. | Consigliato | |
4. Scrivere regole concrete SQL
- | Legge di ferro | Livello | osservazione | conteggio(*) | Non usare count(nome colonna) o count(costante) al posto di count(*), che è la sintassi per il conteggio standard delle righe definito da SQL92, indipendente dal database, e indipendente da NULL e non-NULL. count(*) conta le righe con valore NULL, mentre count(nome colonna) non conta le righe con questa colonna NULL. | forzato |
| | conte (colle distinto) | Conta il numero di righe uniche nella colonna tranne NULL. Si noti che count(distinto col1, col2), se una delle colonne è tutta NULL, allora restituisce 0 anche se l'altra colonna ha un valore diverso. | forzato |
| | Sum(col) | Quando i valori di una colonna sono tutti NULL, count(col) restituisce 0, ma sum(col) restituisce NULL, quindi devi essere consapevole di problemi NPE quando usi sum(). I problemi NPE possono essere evitati nei seguenti modi: selezionare if(isnull(sum(g)), 0, sum(g)) dalla tabella; | forzato |
| | isnull | Usa isnull() per determinare se è un valore NULL. NULL è NULL rispetto a qualsiasi valore. | forzato |
| | Logica di query per paginazione | Se il conteggio è 0, dovrebbe essere restituito direttamente per evitare di eseguire la successiva istruzione di paginazione. | forzato |
| | Tonalità esterne e cascate | L'uso di chiavi esterne e cascata è vietato, e tutti i concetti di chiave esterna devono essere risolti a livello applicativo. Motivo: Le chiavi esterne e le cascate non sono adatte a cluster distribuiti ad alta concorrenza, gli aggiornamenti a cascata sono forti blocchi, c'è il rischio di tempeste di aggiornamento del database e le chiavi esterne influenzano la velocità di inserimento del database. | forzato |
| | Procedure memorizzate | Le stored procedure sono vietate, e le stored procedure sono difficili da debug e scalabili, e non portatili. | forzato |
| | Correzione dei dati | Quando si correggono dati (soprattutto nella cancellazione o modifica dei record), seleziona prima per evitare cancellazioni accidentali ed esegui l'istruzione update solo dopo aver confermato che sia corretta. | forzato |
| | in | Se non può essere evitato, il numero di elementi di set dopo l'inizio dovrebbe essere controllato entro 1000. | Consigliato |
| | Tabella tronca | È vietato usare la tabella tronca, che è più veloce della cancellazione e utilizza meno risorse di sistema e log, ma il tronco è privo di transazioni e non attiva trigger, il che potrebbe causare incidenti, quindi non utilizzare questa istruzione nel codice di sviluppo. | riferimento |
|
5. ORM mappa le leggi del ferro
| - | Legge di ferro | Livello | osservazione | Query della tabella | L'elenco dei campi che sono vietati dall'uso di * per le query deve essere chiaro su quali campi sono richiesti. | forzato |
| | POJO | L'attributo booleano della classe POJO non può essere aggiunto a is, mentre il campo del database deve essere aggiunto a is, richiedendo la mappatura tra campi e attributi nel resultMap. | forzato |
| | Parametri di ritorno | È vietato usare resultClass come parametro di ritorno, anche se tutti i nomi degli attributi delle classi corrispondono uno alla volta ai campi del database, devono essere definiti; A sua volta, ogni tabella deve avere un attributo corrispondente. Motivo: Configura la relazione di mappatura per accoppiare il campo con la classe DO per facilitare la manutenzione. | forzato |
| | Parametri di ritorno | È vietato usare direttamente HashMap e HashTable come output del set di risultati della query. Motivo: Il tipo di valore dell'attributo è incontrollabile. | forzato |
| | sql.xml Configurare i parametri | sql.xml Usa #{}, #param# per i parametri di configurazione e non usare ${}, poiché ${} è soggetto a SQL injection. | forzato |
| | queryForList | L'uso di queryForList (String statementName, int start, int size) che viene fornito con Mybatis è vietato. Motivo: Viene implementato recuperando tutti i record dell'istruzione SQL corrispondente all'istruzione Nome della dichiarazione nel database, e poi usando il sottoList per ottenere un sottoinsieme di inizio, dimensione. | forzato |
| | Tempo di aggiornamento | Quando si aggiorna un record di tabella di database, è necessario aggiornare contemporaneamente il tempo di modifica del record. | forzato |
| | Aggiorna i record della tabella del database | Non scrivere un'interfaccia di aggiornamento dati grande e completa (passata come classe POJO). Quando esegui SQL, non aggiornare i campi inalterati a causa di uno spazio di archiviazione binlog soggetto a errori, inefficiente e aumentato. | Consigliato |
| | @Transactional | @Transactional Non abusare delle transazioni. Le transazioni influenzano il QPS del database. Inoltre, quando usi le transazioni, devi considerare vari aspetti degli schemi di rollback, tra cui il rollback della cache, il rollback dei motori di ricerca, la compensazione dei messaggi, la correzione statistica, ecc. | riferimento |
| | Tag SQL dinamici Mybatis | < compareValue in isEqual> è una costante rispetto al valore dell'attributo, solitamente un numero, che indica che l'istruzione SQL corrispondente viene eseguita quando uguale; < isNotEmpty> indica che viene eseguito quando non è vuoto e non è nullo; < isNotNull> indica che viene eseguito quando non è nullo. | riferimento | |
|
Pubblicato su 10/10/2019 14:00:44
|
|
|
