En bra databasspecifikation hjälper till att minska komplexiteten i mjukvaruimplementeringen och minska kommunikationskostnaderna.
1. Den järnhårda lagen för att bygga ett lager
- | Järnlagen | Nivå | anmärkning | Teckenuppsättning | Använd UTF-8. Om emojin är lagrad, använd utf8mb4 för lagring. | Tvingad |
| | Sorteringsregler | Använd utf8_general_ci | Tvingad | |
2. Järnlagen för bordskonstruktion
- | Järnlagen | Nivå | anmärkning | exeges | Se till att ha fältanteckningar. | Tvingad |
| | koda | Använd UTF-8. Om emojin är lagrad, använd utf8mb4 för lagring. | Tvingad |
| | Om fältet är konceptuellt | Den måste namnges med is_xx, och datatypen är osignerad tinyint(1 ja, 0 nej), t.ex. is_deleted(1 delete, 0 not deleted). | Tvingad | Varje fält måste vara osignerat om det inte är negativt | Tabellnamn, fältnamn | Endast små bokstäver, understreck eller siffror får användas; Det är förbjudet att börja med en understrykning eller siffra; Endast siffror är förbjudna mellan två understreck; Inaktivera reserverade ord; Användning av pluralsubstantiv är förbjuden i tabellnamn. | Tvingad |
| | Namngivningen av databasens namn och tabellnamn | Databasnamnet bör vara förenligt med applikationsnamnet, och tabellnamnet bör namnges med Business Name_Role av tabellen. | Tvingad |
| | Indexnamngivning | Primärnyckelindexet använder pk_ fältnamn; Unikt index med uk_ fältnamn; Normala index använder idx_ fältnamn. | Tvingad | pk_ är primärnyckeln; uk_ är unik nyckel; idx_ är index | Decimaltyp | Datatypen är decimal, och användning av flyttal och dubbel är förbjuden, flyttal och dubbel har precisionsförlust, och om det lagrade dataintervallet överskrider decimalintervallet rekommenderas att dela upp datan i heltal och decimal och lagra dem separat. | Tvingad |
| | Varchar-typ | Varchar är en variabel lång sträng, inget lagringsutrymme är avsatt i förväg, längden får inte överstiga 5000 tecken, om längden är större än 5000, applicera text (skapa en separat tabell, använd primärnyckeln för att korrespondera, för att undvika att påverka indexeringseffektiviteten hos andra fält). | Tvingad |
| | Det måste finnas tre fält i tabellnamnet | ID (datatypen är osignerad bigint, enkel tabellinkrement, steglängd är 1), gmt_create, gmt_modified (aktiv skapandetid, passiv uppdateringstid, datatyp är datetime). | Tvingad |
| | Fältredundans | Fält tillåter lämplig redundans, men datakonsistens måste beaktas, och redundanta fält bör ha 1) sällsynta ändringar; 2) Inte ett varchar superlångt fält, än mindre ett textfält. | rekommendera |
| | Dela upp databasen och tabellerna | Partitionering rekommenderas endast när antalet rader i en enskild tabell överstiger 5 miljoner rader eller kapaciteten i en enskild tabell överstiger 2 GB. | rekommendera | |
Att ställa in rätt teckenlagringslängd sparar inte bara plats i databastabeller och index, utan framför allt förbättrar den återvinningshastigheten.
3. Fastställ en indexjärnlag
- | Järnlagen | Nivå | anmärkning | Unikt index | Områden med unika egenskaper i verksamheten, även om de är en kombination av fält, måste indexeras unikt. Även om det unika indexet påverkar insättningshastigheten är denna förlust försumbar, men den förbättrar frågehastigheten avsevärt. Dessutom, även om applikationslagret har mycket fullständig kontrollkontroll, så länge det inte finns något unikt index, kommer enligt Murphys lag oundvikligen att genereras smutsiga data. | Tvingad |
| | Gå med | Fler än tre tabeller förbjuder sammanfogning, fält som kräver sammanfogning, och datatyperna måste vara konsekventa; När flera tabeller är kopplade till frågor, se till att de tillhörande fälten måste ha ett index. Även om du har en dubbel tabellanslutning, var uppmärksam på tabellindexering och SQL-prestanda. | Tvingad |
| | Varcharfield | Indexlängden måste specificeras, och det finns inget behov av att indexera alla fält, bara bestämma indexlängden enligt den faktiska textskillnaden. Indexlängd och distinktion är ett par motsägelser, generellt för strängtypdata har index med längd 20 en distinktionsgrad på mer än 90 %, vilket kan bestämmas av skillnadsgraden för räkning (distinkt vänster (kolumnnamn, indexlängd))/räkning(*). | Tvingad |
| | Suddighet är förbjudet vid sidsökning | Sidsökning förbjuder suddighet eller fullständig suddmjukning, om det behövs, gå till sökmotorn för att lösa det. Förbudsorsak: Indexfilen har den vänstra prefixmatchningsegenskapen för B-trädet, och om värdet till vänster inte bestäms kan detta index inte användas. | Tvingad |
| | Ordning efter | Om det finns en ordning per scenario, var uppmärksam på ordningen i indexet. Det sista fältet i ordning efter är en del av det kombinerade indexet och placeras i slutet av indexkombinationsordningen för att undvika file_sort och påverka frågeprestandan. Exempel: där a=? och b=? ordning efter c; Indexet bör byggas som a_b_c; Motexempel: Om det finns en intervalluppslagning i indexet kan indexordningen inte användas, till exempel där a>10 ordnas med b; Index a_b kan inte sorteras. | rekommendera | |
4. Skriv SQL-järnregler
- | Järnlagen | Nivå | anmärkning | Räkning(*) | Använd inte count (kolumnnamn) eller count(constant) istället för count(*), vilket är syntaxen för standardräkningen av rader definierade av SQL92, oberoende av databasen och oberoende av NULL och icke-NULL. count(*) räknar rader med ett NULL-värde, medan count(kolumnnamn) inte räknar rader med denna kolumn NULL. | Tvingad |
| | Greve (distinkt kol) | Räknar antalet unika rader i kolumnen förutom NULL. Observera att antal (distinkt kol1, kol2), om en av kolumnerna är helt NULL, så returnerar den 0 även om den andra kolumnen har ett annat värde. | Tvingad |
| | sum(kol) | När värdena i en kolumn alla är NULL, returnerar count(col) 0, men sum(col) returnerar NULL, så du måste vara medveten om NPE-problem när du använder sum(). NPE-problem kan undvikas på följande sätt: välj if(isnull(sum(g)), 0, sum(g)) från tabellen; | Tvingad |
| | isnull | Använd isnull() för att avgöra om det är ett NULL-värde. NULL är NULL jämfört med vilket värde som helst. | Tvingad |
| | Pagineringsfrågelogik | Om räkningen är 0 bör den returneras direkt för att undvika att den efterföljande pagineringssatsen exekveras. | Tvingad |
| | Yttre nycklar och kaskader | Användning av främmande nycklar och kaskadhantering är förbjudet, och alla främmande nyckelkoncept måste lösas på applikationslagret. Anledning: Främmande nycklar och kaskader är inte lämpliga för distribuerade, högsamtidiga kluster, kaskaduppdateringar blockerar starkt, det finns risk för uppdateringsstormar i databasen och främmande nycklar påverkar databasens insättningshastighet. | Tvingad |
| | Lagrade procedurer | Lagrade procedurer är förbjudna, och lagrade procedurer är svåra att felsöka och skala, och är inte portable. | Tvingad |
| | Datakorrigering | När du korrigerar data (särskilt när du tar bort eller ändrar poster), välj först för att undvika oavsiktlig borttagning och kör bara uppdateringssatsen efter att ha bekräftat att den är korrekt. | Tvingad |
| | i | Om det inte går att undvika bör antalet fasta element efter i kontrolleras inom 1000. | rekommendera |
| | Trunkeringstabell | Det är förbjudet att använda truncate-tabell, som är snabbare än delete och använder färre system- och loggresurser, men truncate är transaktionsfritt och triggar inga triggers, vilket kan orsaka olyckor, så använd inte detta uttalande i utvecklingskod. | hänvisning |
|
5. ORM kartlägger järnlagar
| - | Järnlagen | Nivå | anmärkning | Tabellfråga | Listan över fält som är förbjudna att använda * för frågor måste vara tydlig med vilka fält som krävs. | Tvingad |
| | POJO | Det booleska attributet för POJO-klassen kan inte läggas till is, medan databasfältet måste läggas till is, vilket kräver mappning mellan fält och attribut i resultMap. | Tvingad |
| | Returparametrar | Det är förbjudet att använda resultClass som returparameter, även om alla klassattributnamn motsvarar databasfält ett efter ett, måste de definieras; I sin tur måste varje tabell ha ett attribut som motsvarar den. Anledning: Konfigurera mappningsrelationen för att koppla fältet till DO-klassen för enkel underhåll. | Tvingad |
| | Returparametrar | Det är förbjudet att direkt använda HashMap och HashTable som utdata för frågeresultatuppsättningen. Anledning: Typen av attributvärde är okontrollerbar. | Tvingad |
| | sql.xml Konfigurera parametrar | sql.xml Använd #{}, #param# för konfigurationsparametrar, och använd inte ${}, eftersom ${} är benäget för SQL-injektion. | Tvingad |
| | queryForList | Användningen av queryForList (String statementName, int start, int size) som följer med Mybatis är förbjuden. Anledning: Det implementeras genom att hämta alla poster i SQL-satsen som motsvarar statementName i databasen, och sedan använda subList för att få en delmängd av startstorlek. | Tvingad |
| | Uppdateringstid | När du uppdaterar en databastabellpost måste du samtidigt uppdatera versionstiden för posten. | Tvingad |
| | Uppdatera databastabellposter | Skriv inte ett stort och komplett datauppdateringsgränssnitt (som gick in som en POJO-klass). När du kör SQL, uppdatera inte oförändrade fält på grund av felbenägen, ineffektiv och ökad binloglagring. | rekommendera |
| | @Transactional | @Transactional Missbruka inte transaktioner. Transaktioner påverkar databasens QPS. Dessutom, där du använder transaktioner, behöver du ta hänsyn till olika aspekter av rollback-scheman, inklusive cache-rollback, sökmotorrollback, meddelandekompensation, statistisk korrigering med mera. | hänvisning |
| | Mybatis dynamiska SQL-taggar | < compareValue i isEqual> är en konstant jämfört med attributvärdet, vanligtvis ett tal, vilket indikerar att motsvarande SQL-sats utförs när lika mycket; < isNotEmpty> indikerar att den utförs när den inte är tom och inte null; < isNotNull> indikerar att den utförs när den inte är null. | hänvisning | |
|
Publicerad på 2019-10-10 14:00:44
|
|
|
