En god databasespecifikation hjælper med at reducere kompleksiteten ved softwareimplementering og reducere kommunikationsomkostningerne.
1. Den jernhårde lov om at bygge et lager
- | Jernloven | Niveau | bemærkning | Tegnsæt | Brug UTF-8. Hvis emojien er gemt, brug utf8mb4 til opbevaring. | Tvunget |
| | Sorteringsregler | Brug utf8_general_ci | Tvunget | |
2. Jernloven om bordkonstruktion
- | Jernloven | Niveau | bemærkning | Eksegese | Sørg for at have feltannoteringer. | Tvunget |
| | Indkode | Brug UTF-8. Hvis emojien er gemt, brug utf8mb4 til opbevaring. | Tvunget |
| | om feltet er konceptuelt | Den skal navngives med is_xx, og datatypen er usigneret tinyint(1 ja, 0 nej), f.eks. is_deleted(1 delete, 0 not deleted). | Tvunget | Ethvert felt skal være usigneret, hvis det ikke er negativt | Tabelnavn, feltnavn | Kun små bogstaver, understrøg eller tal kan bruges; Det er forbudt at starte med en understregning eller et tal; Kun tal er forbudt mellem to understreger; Deaktiver reserverede ord; Brugen af flertalsnavne er forbudt i tabelnavne. | Tvunget |
| | Navngivningen af databasenavnet og tabelnavnet | Databasenavnet skal være konsistent med applikationsnavnet, og tabelnavnet skal navngives med Forretnings Name_Role af tabellen. | Tvunget |
| | Indeksnavngivning | Primærnøgleindekset bruger pk_ feltnavn; Unikt indeks med uk_ feltnavn; Normale indekser bruger idx_ feltnavne. | Tvunget | pk_ er primærnøglen; uk_ er unik nøgle; idx_ er indeks | Decimaltype | Datatypen er decimal, og brugen af float og double er forbudt, float og double har præcisionstab, og hvis det lagrede dataområde overstiger decimalområdet, anbefales det at opdele dataene i heltal og decimaler og gemme dem separat. | Tvunget |
| | Varchar-typen | Varchar er en variabel lang streng, der er ikke tildelt lagerplads på forhånd, længden må ikke overstige 5000 tegn, hvis længden er større end 5000, anvendes tekst (opret en separat tabel, brug primærnøglen til at korrespondere, for at undgå at påvirke indekseringseffektiviteten af andre felter). | Tvunget |
| | Der skal være tre felter i tabelnavnet | ID (datatypen er usigneret bigint, enkelt tabelinkrement, skridtlængde er 1), gmt_create, gmt_modified (aktiv oprettelsestid, passiv opdateringstid, datatype er datotid). | Tvunget |
| | Feltredundans | Felter tillader passende redundans, men datakonsistens skal overvejes, og redundante felter bør have 1) sjældne ændringer; 2) Ikke et varchar super langt felt, slet ikke et tekstfelt. | anbefale |
| | Del databasen og tabellerne op | Partitionering anbefales kun, når antallet af rækker i en enkelt tabel overstiger 5 millioner rækker, eller kapaciteten i en enkelt tabel overstiger 2 GB. | anbefale | |
At indstille den passende længde på tegnlagring sparer ikke kun plads i databasen og indekset, men vigtigst af alt forbedrer genfindingshastigheden.
3. Etabler en indeksjernslov
- | Jernloven | Niveau | bemærkning | Unikt indeks | Felter med unikke karakteristika i virksomheden, selv hvis de er en kombination af felter, skal indekseres entyd. Selvom det unikke indeks påvirker indsættelseshastigheden, er dette tab ubetydeligt, men det forbedrer forespørgselshastigheden betydeligt. Derudover, selv hvis applikationslaget har meget fuldstændig kontrolkontrol, vil der ifølge Murphys lov uundgåeligt genereres beskidte data, så længe der ikke findes et unikt indeks. | Tvunget |
| | Bliv medlem | Mere end tre tabeller forbyder joining, felter der kræver join, og datatyperne skal være konsistente; Når flere tabeller er tilknyttet forespørgsler, skal du sikre, at de tilknyttede felter skal have et indeks. Selv hvis du har dobbelt table join, så vær opmærksom på tabelindeksering og SQL-ydeevne. | Tvunget |
| | Varcharfield | Indekslængden skal angives, og der er ikke behov for at indeksere alle felter, blot bestemme indekslængden i henhold til den faktiske tekstforskel. Indekslængde og distinktion er et par modsigelser; generelt for strengtypedata vil indekser med en længde på 20 have en distinktionsgrad på mere end 90 %, hvilket kan bestemmes af distinktionsgraden af count (distinkt venstre (kolonnenavn, indekslængde))/count(*). | Tvunget |
| | Sløring er forbudt ved sidesøgning | Sidesøgning forbyder sløring eller fuld sløring, hvis nødvendigt, gå venligst til søgemaskinen for at løse det. Forbudsgrund: Indeksfilen har den venstre præfiksmatch-egenskab for B-træet, og hvis værdien til venstre ikke er bestemt, kan dette indeks ikke bruges. | Tvunget |
| | Orden efter | Hvis der er en rækkefølge efter scenarie, så vær opmærksom på indeksets orden. Det sidste felt med orden efter er en del af det kombinerede indeks og placeres i slutningen af indekskombinationsrækkefølgen for at undgå file_sort og påvirke forespørgselsydelsen. Eksempel: hvor a=? og b=? orden efter c; Indekset bør bygges som a_b_c; Modeksempel: Hvis der er et intervalopslag i indekset, kan indeksordenen ikke udnyttes, for eksempel hvor a>10 ordnes med b; Indeks a_b kan ikke sorteres. | anbefale | |
4. Skriv SQL jernregler
- | Jernloven | Niveau | bemærkning | Tælling(*) | Brug ikke count(kolonnenavn) eller count(constant) i stedet for count(*), som er syntaksen for standardantallet af rækker defineret af SQL92, uafhængigt af databasen og uafhængigt af NULL og ikke-NULL. count(*) tæller rækker med en NULL-værdi, mens count(kolonnenavn) ikke tæller rækker med denne kolonne NULL. | Tvunget |
| | Greve (særskilt col) | Tæller antallet af unikke rækker i kolonnen undtagen NULL. Bemærk, at count (forskellig col1, col2), hvis en af kolonnerne er helt NULL, så returnerer den 0, selvom den anden kolonne har en anden værdi. | Tvunget |
| | sum(kol) | Når værdierne af en kolonne alle er NULL, returnerer count(col) 0, men sum(col) returnerer NULL, så du skal være opmærksom på NPE-problemer, når du bruger sum(). NPE-problemer kan undgås på følgende måder: vælg if(isnull(sum(g)), 0, sum(g)) fra tabel; | Tvunget |
| | isnull | Brug isnull() til at afgøre, om det er en NULL-værdi. NULL er NULL sammenlignet med enhver værdi. | Tvunget |
| | Pagineringsforespørgselslogik | Hvis antallet er 0, bør det returneres direkte for at undgå at udføre den efterfølgende pagineringssætning. | Tvunget |
| | Ydre nøgler og kaskader | Brug af fremmednøgler og kaskadering er forbudt, og alle fremmednøglebegreber skal løses på applikationslaget. Årsag: Fremmednøgler og kaskader egner sig ikke til distribuerede, højsamtidighedsklynge, kaskaderende opdateringer er stærk blokering, der er risiko for databaseopdateringsstorme, og fremmednøgler påvirker indsættelseshastigheden af databasen. | Tvunget |
| | Lagrede procedurer | Lagrede procedurer er forbudte, og lagrede procedurer er svære at fejlfinde og skalere, og de er ikke portable. | Tvunget |
| | Datakorrektion | Når du retter data (især ved sletning eller ændring af poster), vælg først for at undgå utilsigtet sletning, og udfør kun opdateringssætningen efter at have bekræftet, at den er korrekt. | Tvunget |
| | i | Hvis det ikke kan undgås, bør antallet af fastsatte elementer efter i kontrolleres inden for 1000. | anbefale |
| | Afkortet tabel | Det er forbudt at bruge truncate-tabellen, som er hurtigere end delete og bruger færre system- og logressourcer, men truncate er transaktionsfri og udløser ikke triggere, som kan forårsage uheld, så brug ikke denne sætning i udviklingskode. | henvisning |
|
5. ORM kortlægger jernlove
| - | Jernloven | Niveau | bemærkning | Tabelforespørgsel | Listen over felter, der ikke må bruges * til forespørgsler, skal være klar, hvilke felter der kræves. | Tvunget |
| | POJO | Den booleske attribut for POJO-klassen kan ikke tilføjes til is, mens databasefeltet skal tilføjes til is, hvilket kræver mapping mellem felter og attributter i resultMap. | Tvunget |
| | Returparametre | Det er forbudt at bruge resultClass som returnparameter, selvom alle klasseattributnavne svarer til databasefelter én ad gangen, skal de defineres; Til gengæld skal hver tabel have en attribut, der svarer til den. Årsag: Konfigurer mapping-relationen til at koble feltet til DO-klassen for nem vedligeholdelse. | Tvunget |
| | Returparametre | Det er forbudt direkte at bruge HashMap og HashTable som output af forespørgselsresultatsættet. Årsag: Typen af attributværdi er ukontrollerbar. | Tvunget |
| | sql.xml Konfigurer parametre | sql.xml Brug #{}, #param# til konfigurationsparametre, og brug ikke ${}, da ${} er tilbøjelig til SQL-injektion. | Tvunget |
| | queryForList | Brugen af queryForList (String statementName, int start, int size), som følger med Mybatis, er forbudt. Reason: Det implementeres ved at hente alle poster af SQL-sætningen, der svarer til statementName, i databasen og derefter bruge subList til at få en delmængde af startstørrelse. | Tvunget |
| | Opdateringstid | Når du opdaterer en databasetabelpost, skal du samtidig opdatere ændringstiden for posten. | Tvunget |
| | Opdater databasetabelposter | Skriv ikke et stort og fuldt dataopdateringsinterface (indgivet som en POJO-klasse). Når du udfører SQL, må du ikke opdatere uændrede felter på grund af fejlbehæftede, ineffektive og øget binlog-lagring. | anbefale |
| | @Transactional | @Transactional Misbrug ikke transaktioner. Transaktioner påvirker databasens QPS. Derudover skal du, når du bruger transaktioner, overveje forskellige aspekter af rollback-ordninger, herunder cache-rollback, søgemaskine-rollback, beskedkompensation, statistisk korrektion osv. | henvisning |
| | Mybatis dynamiske SQL-tags | < compareValue i isEqual> er en konstant sammenlignet med attributværdien, normalt et tal, der angiver, at den tilsvarende SQL-sætning udføres når den er lige; < isNotEmpty> indikerer, at den udføres, når den ikke er tom og ikke null; < isNotNull> indikerer, at den udføres, når den ikke er null. | henvisning | |
|
Opslået på 10/10/2019 14.00.44
|
|
|
