En god databasespesifikasjon bidrar til å redusere kompleksiteten ved programvareimplementering og redusere kommunikasjonskostnader.
1. Jernloven for å bygge et lager
- | Jernlov | Nivå | bemerkning | Tegnsett | Bruk UTF-8. Hvis emojien er lagret, bruk utf8mb4 for lagring. | Tvunget |
| | Sorteringsregler | Bruk utf8_general_ci | Tvunget | |
2. Jernloven for bordkonstruksjon
- | Jernlov | Nivå | bemerkning | Eksegese | Sørg for å ha feltannotasjoner. | Tvunget |
| | Kode | Bruk UTF-8. Hvis emojien er lagret, bruk utf8mb4 for lagring. | Tvunget |
| | om feltet er konseptuelt | Den må navngis med is_xx, og datatypen er usignert tinyint(1 ja, 0 nei), f.eks. is_deleted(1 delete, 0 not deleted). | Tvunget | Ethvert felt må være usignert hvis det ikke er negativt | Tabellnavn, feltnavn | Kun små bokstaver, understreker eller tall kan brukes; Det er forbudt å starte med en understreking eller et tall; Kun tall er forbudt mellom to understreker; Deaktiver reserverte ord; Bruk av flertallssubstantiv er forbudt i tabellnavn. | Tvunget |
| | Navngivning av databasenavnet og tabellnavnet | Databasenavnet bør være konsistent med applikasjonsnavnet, og tabellnavnet skal navngis med Business Name_Role av tabellen. | Tvunget |
| | Indeksnavngivning | Primærnøkkelindeksen bruker pk_ feltnavn; Unik indeks med uk_ feltnavn; Normale indekser bruker idx_ feltnavn. | Tvunget | pk_ er primærnøkkelen; uk_ er unik nøkkel; idx_ er indeks | Desimaltype | Datatypen er desimal, og bruk av float og double er forbudt, float og double har presisjonstap, og hvis det lagrede dataområdet overstiger desimalområdet, anbefales det å dele dataene i heltall og desimaler og lagre dem separat. | Tvunget |
| | Varchar-type | Varchar er en variabel lang streng, ingen lagringsplass er tildelt på forhånd, lengden skal ikke overstige 5000 tegn, hvis lengden er større enn 5000, bruk tekst (lag en separat tabell, bruk primærnøkkelen for å korrespondere, for å unngå å påvirke indekseringseffektiviteten til andre felt). | Tvunget |
| | Det må være tre felt i tabellnavnet | ID (datatype er usignert bigint, enkelt tabellinkrement, stegstørrelse er 1), gmt_create, gmt_modified (aktiv opprettelsestid, passiv oppdateringstid, datatype er datotid). | Tvunget |
| | Feltredundans | Felt tillater passende redundans, men datakonsistens må vurderes, og redundante felt bør ha 1) sjeldne endringer; 2) Ikke et varchar superlangt felt, langt mindre et tekstfelt. | anbefale |
| | Del databasen og tabellene | Partisjonering anbefales kun når antall rader i en enkelt tabell overstiger 5 millioner rader, eller kapasiteten til en enkelt tabell overstiger 2 GB. | anbefale | |
Å sette riktig lengde på tegnlagring sparer ikke bare plass i databasetabeller og indekser, men viktigst av alt, forbedrer også hentingshastigheten.
3. Etabler en indeksjernlov
- | Jernlov | Nivå | bemerkning | Unik indeks | Felt med unike egenskaper i virksomheten, selv om de er en kombinasjon av felt, må indekseres entydig. Selv om den unike indeksen påvirker innsettingshastigheten, er dette tapet ubetydelig, men det forbedrer spørringshastigheten betydelig. I tillegg, selv om applikasjonslaget har svært fullstendig kontrollkontroll, så lenge det ikke finnes en unik indeks, vil det ifølge Murphys lov uunngåelig genereres skitne data. | Tvunget |
| | Bli med | Mer enn tre tabeller forbyr joining, felt som krever join, og datatypene må være konsistente; Når flere tabeller er knyttet til spørringer, sørg for at de tilknyttede feltene må ha en indeks. Selv om du har dobbel tabellkobling, vær oppmerksom på tabellindeksering og SQL-ytelse. | Tvunget |
| | Varcharfield | Indekslengden må spesifiseres, og det er ikke nødvendig å indeksere alle felt, bare bestemme indekslengden i henhold til den faktiske tekstdistinksjonen. Indekslengde og distinksjon er et par motsetninger; vanligvis for strengtypedata vil indekser med en lengde på 20 ha en distinksjonsgrad på mer enn 90 %, som kan bestemmes av distinksjonsgraden av telling (distinkt venstre (kolonnenavn, indeks lengde))/tell(*). | Tvunget |
| | Uskarphet er forbudt i sidesøk | Sidesøk forbyr uskarphet eller full uskarphet, om nødvendig, vennligst gå til søkemotoren for å løse det. Forbudsgrunn: Indeksfilen har den venstre prefiksmatch-egenskapen til B-treet, og hvis verdien til venstre ikke er bestemt, kan ikke denne indeksen brukes. | Tvunget |
| | Orden etter | Hvis det finnes en rekkefølge etter scenario, vær oppmerksom på ordenen i indeksen. Det siste feltet med orden etter er en del av den kombinerte indeksen og plasseres på slutten av indekskombinasjonsrekkefølgen for å unngå file_sort og påvirke spørringsytelsen. Eksempel: hvor a=? og b=? orden etter c; Indeksen bør bygges som a_b_c; Moteksempel: Hvis det finnes et intervalloppslag i indeksen, kan ikke indeksordenen benyttes, for eksempel der a>10 ordnes med b; Indeks a_b kan ikke sorteres. | anbefale | |
4. Skriv SQL-jernregler
- | Jernlov | Nivå | bemerkning | tell(*) | Ikke bruk count(kolonnenavn) eller count(constant) i stedet for count(*), som er syntaksen for standard antall rader definert av SQL92, uavhengig av databasen, og uavhengig av NULL og ikke-NULL. count(*) teller rader med en NULL-verdi, mens count(kolonnenavn) ikke teller rader med denne kolonnen NULL. | Tvunget |
| | Greve (distinkt kol) | Teller antall unike rader i kolonnen bortsett fra NULL. Merk at antall (distinkt kol1, kol2), hvis en av kolonnene er helt NULL, returnerer den 0 selv om den andre kolonnen har en annen verdi. | Tvunget |
| | sum(kol) | Når verdiene til en kolonne alle er NULL, returnerer count(col) 0, men sum(col) returnerer NULL, så du må være oppmerksom på NPE-problemer når du bruker sum(). NPE-problemer kan unngås på følgende måter: velg hvis(isnull(sum(g)), 0, sum(g)) fra tabellen; | Tvunget |
| | isnull | Bruk isnull() for å avgjøre om det er en NULL-verdi. NULL er NULL sammenlignet med enhver verdi. | Tvunget |
| | Pagineringsspørringslogikk | Hvis tellingen er 0, bør den returneres direkte for å unngå å kjøre den påfølgende pagineringssetningen. | Tvunget |
| | Ytre tangenter og kaskader | Bruk av fremmednøkler og kaskadering er forbudt, og alle fremmednøkkelkonsepter må løses på applikasjonslaget. Årsak: Fremmednøkler og kaskader egner seg ikke for distribuerte, høysamtidige klynger, kaskaderende oppdateringer er sterk blokkering, det er risiko for databaseoppdateringsstormer, og fremmednøkler påvirker innsettingshastigheten til databasen. | Tvunget |
| | Lagrede prosedyrer | Lagrede prosedyrer er forbudt, og lagrede prosedyrer er vanskelige å feilsøke og skalere, og er ikke portable. | Tvunget |
| | Datakorrigering | Når du korrigerer data (spesielt sletter eller endrer poster), velg først for å unngå utilsiktet sletting, og kjør kun oppdateringssetningen etter å ha bekreftet at den er korrekt. | Tvunget |
| | i | Hvis det ikke kan unngås, bør antallet settelementer etter i kontrolleres innenfor 1000. | anbefale |
| | Afkortet tabell | Det er forbudt å bruke truncate-tabell, som er raskere enn delete og bruker færre system- og loggressurser, men truncate er transaksjonsfritt og utløser ikke triggere, noe som kan forårsake ulykker, så ikke bruk denne setningen i utviklingskode. | referanse |
|
5. ORM kartlegger jernlover
| - | Jernlov | Nivå | bemerkning | Tabellspørring | Listen over felt som er forbudt å bruke * for spørringer må være tydelig på hvilke felt som kreves. | Tvunget |
| | POJO | Det boolske attributtet til POJO-klassen kan ikke legges til is, mens databasefeltet må legges til is, noe som krever mapping mellom felt og attributter i resultMap. | Tvunget |
| | Returparametere | Det er forbudt å bruke resultClass som returparameter, selv om alle klasseattributtnavn tilsvarer databasefeltene ett etter ett, må de defineres; Hver tabell må igjen ha en attributt som tilsvarer den. Årsak: Konfigurer mapping-relasjonen til å koble feltet til DO-klassen for enkel vedlikehold. | Tvunget |
| | Returparametere | Det er forbudt å bruke HashMap og HashTable direkte som utgang for spørringsresultatsettet. Årsak: Typen attributtverdi er ukontrollerbar. | Tvunget |
| | sql.xml Konfigurer parametere | sql.xml Bruk #{}, #param# for konfigurasjonsparametere, og ikke bruk ${}, da ${} er utsatt for SQL-injeksjon. | Tvunget |
| | queryForList | Bruken av queryForList (String statementName, int start, int size) som følger med Mybatis er forbudt. Reason: Det implementeres ved å hente alle poster i SQL-setningen som tilsvarer statementName i databasen, og deretter bruke subList for å hente en delmengde av start, størrelse. | Tvunget |
| | Oppdateringstid | Når du oppdaterer en databasetabellpost, må du oppdatere endringstiden for posten samtidig. | Tvunget |
| | Oppdater databasetabellposter | Ikke skriv et stort og fullstendig dataoppdateringsgrensesnitt (som ble sendt inn som en POJO-klasse). Når du kjører SQL, ikke oppdater uendrede felt på grunn av feilutsatte, ineffektive og økt binlog-lagring. | anbefale |
| | @Transactional | @Transactional Ikke misbruk transaksjoner. Transaksjoner påvirker QPS i databasen. I tillegg, der du bruker transaksjoner, må du vurdere ulike aspekter ved tilbakerullingsordninger, inkludert cache-tilbakeføring, søkemotor-tilbakerulling, meldingskompensasjon, statistisk korreksjon osv. | referanse |
| | Mybatis dynamiske SQL-tagger | < compareValue i isEqual> er en konstant sammenlignet med attributtverdien, vanligvis et tall, som indikerer at den tilsvarende SQL-setningen utføres når lik; < isNotEmpty> indikerer at den utføres når den ikke er tom og ikke null; < isNotNull> indikerer at den utføres når den ikke er null. | referanse | |
|
Publisert på 10.10.2019 14:00:44
|
|
|
