Mysql-exempel på komplexa frågor med parametrar. Indexera och använda samma typer för bundna kolumner


För närvarande kan alla observera den snabba tillväxten i volymen av digital information. Och eftersom det mesta av denna information är viktig, blir det nödvändigt att spara den på digitala medier för senare användning. I denna situation kan modern teknik som databaser användas. De ger tillförlitlig lagring av all digital information och datatillgång kan utföras var som helst i världen. En av teknologierna som beaktas är MySQL-databashanteringssystemet.

Vad är MySQL DBMS?

MySQL är en av de mest efterfrågade och ofta använda datalagringsteknologierna. Dess funktionalitet är överlägsen den befintliga DBMS i många avseenden. I synnerhet är en av huvudfunktionerna möjligheten att använda kapslade MySQL-frågor.

Därför utvecklas många projekt där prestationstiden är viktig och det är nödvändigt att lagra information såväl som att utföra komplex datahämtning på grundval av MySQL DBMS. De flesta av dessa utvecklingar är webbplatser. Samtidigt implementeras MySQL aktivt i implementeringen av både små (bloggar, visitkortsidor etc.) och ganska stora uppgifter (onlinebutiker etc.). I båda fallen används en MySQL-fråga för att visa information på webbplatsens sida. I begäran försöker utvecklarna utnyttja de tillgängliga funktioner som databashanteringssystemet tillhandahåller.

Hur datalagring ska organiseras

För enkel lagring och efterföljande behandling beställs data nödvändigtvis. Datastrukturen låter dig definiera hur tabellerna som ska lagras information ser ut. Databastabeller är en samling fält (kolumner) som ansvarar för varje specifik egenskap hos ett dataobjekt.

Till exempel, om en tabell med anställda i ett visst företag sammanställs, kommer dess enklaste struktur att vara följande. Varje anställd tilldelas ett unikt nummer, som vanligtvis används som den primära nyckeln till tabellen. Sedan matas personens uppgifter in i tabellen. Det kan vara vad som helst: fullt namn, namn på den avdelning som den har tilldelats, telefonnummer, adress etc. Enligt normaliseringskraven (6 normala databasformer), såväl som för att MySQL-frågor ska byggas på ett strukturerat sätt, måste tabellfälten vara atomiska, det vill säga de får inte ha uppräkning eller listor. Därför finns det som regel separata fält i tabellen för efternamn, förnamn etc.

Ivanovich

Administratör

Direktör

Petrovich

Administratör

Vice direktör

Gregory

Grigorievich

Chef

Sergeevich

Expedit.

Ovan är ett triviellt exempel på strukturen för en databastabell. Men det uppfyller fortfarande inte helt de grundläggande kraven för normalisering. I verkliga system skapas en ytterligare avdelningstabell. Därför bör tabellen nedan innehålla avdelningsnummer istället för orden i kolumnen "Avdelning".

Hur data hämtas

För att hämta data från tabeller i DBMS används ett specialkommando MySQL - begär Välj. För att servern ska svara korrekt på begäran måste begäran vara korrekt utformad. Begäran strukturen är utformad enligt följande. Alla samtal till databaseservern börjar med nyckelordet välj... Alla frågor i MySQL är inte byggda med. Exemplen kan variera i komplexitet, men konstruktionsprincipen är mycket lik.

Sedan måste du ange från vilka fält du vill välja information av intresse. Listan över fält separeras med komma efter meningen välj... Efter att alla obligatoriska fält har listats, anger frågan det tabellobjekt som valet kommer att ske från och med meningen från och ange namnet på tabellen.

För att begränsa valet läggs specialoperatörer som tillhandahålls av DBMS till MySQL-frågor. För att välja icke upprepande (unik) data används ett förslag distinkt, och för att ställa villkor - operatör var... Som ett exempel på tabellen ovan kan vi överväga en begäran som kräver information om namn och efternamn. anställda som arbetar i "Sales" -avdelningen. Strukturen för begäran kommer att se ut i tabellen nedan.

Förstå en kapslad fråga

Men huvudfunktionen i DBMS, som nämnts ovan, är möjligheten att bearbeta kapslade MySQL-frågor. Hur ska det se ut? Från namnet är det logiskt tydligt att, som bildas i en viss hierarki från två eller flera frågor. Teorin för att studera särdragen i DBMS säger att MySQL inte sätter begränsningar för antalet MySQL-frågor som kan häckas i huvudfrågan. Du kan dock experimentera i praktiken och se till att responstiden efter de andra tio kapslade frågorna kommer att öka avsevärt. Hur som helst, i praktiken finns det inga uppgifter som kräver en extremt komplex MySQL-fråga. En fråga kan kräva högst 3-5 kapslade hierarkier.

Bygga kapslade frågor

Vid analys av den lästa informationen uppstår ett antal frågor om var kapslade frågor kan användas och om det är möjligt att lösa problemet genom att dela upp dem i enkla utan att komplicera strukturen. I praktiken används kapslade frågor för att lösa komplexa problem. Denna typ av problem inkluderar situationer där tillståndet inte är känt i förväg, enligt vilket det ytterligare valet av värden kommer att begränsas. Det är omöjligt att lösa sådana problem om du bara använder en vanlig MySQL-fråga. En fråga som består av hierarkier söker efter begränsningar som kan förändras över tid eller kanske inte är kända i förväg.

Om vi \u200b\u200bbetraktar tabellen ovan kan följande exempel nämnas som en svår uppgift. Anta att vi måste ta reda på grundläggande information om de anställda som är underordnade Grishin Grigory Grigorievich, som är. När vi formulerar en begäran, vet vi inte hans identifikationsnummer. Därför måste vi inledningsvis känna honom. För detta används en enkel fråga för att hitta en lösning på huvudvillkoren och komplettera den huvudsakliga MySQL-frågan. Frågan visar tydligt att underfrågan får ett anställds identifikationsnummer, vilket ytterligare bestämmer begränsningen för huvudfrågan:

I detta fall förslaget några används för att utesluta förekomst av fel om det finns flera anställda med sådana initialer.

Resultat

Sammanfattningsvis bör det noteras att det finns många andra ytterligare funktioner som i hög grad underlättar konstruktionen av frågor, eftersom MySQL DBMS är ett kraftfullt verktyg med ett rikt arsenal av verktyg för lagring och bearbetning av data.


Artikelens innehåll
1. De mest grundläggande MySQL-frågorna
2. Enkla SELECT-frågor
3. Enkla INSERT-frågor (ny post)
4. Enkla UPDATE-frågor (skriv om, bifoga) frågor
5. Enkla DELETE (ta bort post) frågor
6. Enkla DROP-frågor (ta bort tabell)
7. Komplexa MySQL-frågor
8. MySQL-frågor och PHP-variabler

1. De enklaste SQL-frågorna

1. Visar en lista över ALLA databaser.

VISA databaser;
2. Listar ALLA tabeller i databasen base_name.

VISA tabeller i basnamn;

2. Enkla SELECT-frågor mot MySQL-databas

VÄLJ - en fråga som väljer redan befintlig data från databasen. För val kan du ange vissa valparametrar. Till exempel är kärnan i frågan på ryska: VÄLJ sådana och sådana kolumner FRÅN en sådan och sådan tabell VAR parametern för sådan och sådan kolumn är lika med värdet.

1. Väljer ALLA data i tabellen tbl_name.

VÄLJ * FRÅN tbl_name;
2. Visar antalet poster i tabellen tbl_name.

VÄLJ antal (*) FRÅN tbl_name;
3. Väljer (VÄLJ) från (FRA) tabell tbl_name limit (LIMIT) 3 poster, från 2.

VÄLJ * FRÅN tbl_name LIMIT 2,3;
4. Väljer (VÄLJ) ALLA (*) poster från (FRÅN) tabellen tbl_name och sorterar dem (ORDER BY) efter ID i ordning.

VÄLJ * FRÅN tbl_name ORDER BY id;
5. Väljer (VÄLJ) ALLA poster från (FRÅN) tabellen tbl_name och sorterar dem (ORDER BY) efter ID-fält i omvänd ordning.

VÄLJ * FRÅN tbl_name ORDER BY ID DESC;
6. Välj ( VÄLJ) ALLA (*) poster från ( FRÅN) tabeller användare och sorterar dem ( SORTERA EFTER) på fältet id i stigande ordning, begränsa ( BEGRÄNSA) de första 5 skivorna.

VÄLJ * FRÅN användare BESTÄLL AV ID-BEGRÄNSNING 5;
7. Väljer alla poster från tabellen användarevar är fältet fname matchar värdet Gena.

VÄLJ * FRÅN användare WHERE fname \u003d "Gena";
8. Väljer alla poster från tabellen användaredär fältvärdet fname börja med Ge.

VÄLJ * FRÅN användare DÄR fname LIKE "Ge%";
9. Väljer alla poster från tabellen användarevar fname slutar med naoch beställer poster i stigande ordningsföljd id.

VÄLJ * FRÅN användare DÄR fname Gillar "% na" ORDER BY id;
10. Väljer all data från kolumner fname, lname från bordet användare.

VÄLJ fname, lname FRA användare;

11. Låt oss säga att du har ett land i användardatatabellen. Så om du bara vill visa en lista med förekommande värden (så att till exempel Ryssland inte visas 20 gånger, utan bara en), använd DISTINCT. Härleda från massan av upprepade värden Ryssland, Ukraina, Vitryssland. Så från bordet användare kolonner land Alla unika värden visas

VÄLJ DISTINCT-land FRÅN användare;
12. Väljer ALLA raddata från en tabell användare Var ålder har värdena 18,19 och 21.

VÄLJ * FRÅN användare där VAR ålder IN (18,19,21);
13. Väljer MAX-värdet ålder i bordet användare... Det vill säga om du har det högsta värdet i tabellen ålder(från engelska ålder) är 55, då blir frågeställningen 55.

VÄLJ max (ålder) FRÅN användare;
14. Välj data från tabellen användare av fält namn och ålder VAR ålder tar det minsta värdet.

VÄLJ namn, min (ålder) FRÅN användare;
15. Hämta data från tabellen användare på fältet namn VAR id INTE LIKVIKT 2.

VÄLJ namn från användare WHERE id! \u003d "2";

3. Enkla INSERT-frågor (ny post)

FÖRA IN - en fråga som låter dig INITIELLT infoga en post i databasen. Det vill säga det skapar en NY post (rad) i databasen.

1. Gör en ny post i tabellen användare, i fält namn sätter in Sergey och i fältet ålder infogar 25. Således läggs en ny rad med de givna värdena till tabellen. Om det finns fler kolumner förblir de antingen tomma eller med standardvärdena.

INSERT INTO användare (namn, ålder) VÄRDER ("Sergey", "25");

4. Enkla UPDATE-frågor till MySQL-databasen

UPPDATERING - en fråga som låter dig skriva om fältvärden eller lägga till något i en befintlig rad i databasen. Till exempel finns det en färdiggjord sträng, men du måste skriva över åldersparametern i den, eftersom den har ändrats över tid.

1. I tabellen användare ålder blir 18.

UPDATE-användare ställer in ålder \u003d "18" WHERE id \u003d "3";
2. Allt är detsamma som i den första frågan, bara syntaxen för frågan visas, där två eller flera fält skrivs över.
I bordet användare VAR ID är 3 fältvärde ålder blir 18, och land Ryssland.

UPDATE användare SET ålder \u003d "18", land \u003d "Ryssland" WHERE id \u003d "3";

5. Enkla DELETE (ta bort post) frågor till MySQL-databasen

RADERA - en fråga som tar bort en rad från bordet.

1. Tar bort en rad från bordet användare VAR id är lika med 10.

RADERA FRÅN användare WHERE id \u003d "10";

6. Enkla DROP-frågor (ta bort tabell) till MySQL-databasen

SLÄPPA - en fråga som tappar ett bord.

1. Släpper hela tabellen tbl_name.

DROP TABELL tbl_name

7. Komplexa frågor till MySQL-databasen

Nyfiken frågor som kan komma till nytta även för erfarna användare

VÄLJ ID, namn, land FRÅN användare, administratörer VAR TO_DAYS (NU ()) - TO_DAYS (registreringsdatum)<= 14 AND activation != "0" ORDER BY registration_date DESC;
Denna komplexa fråga VÄLJ kolumner id, namn, land I tabeller användare, administratörer VAR registrerings datum (datum) inte äldre 14 dagar Och aktivering INTE JÄMNLIKT 0 , Sortera efter registrerings datum i omvänd ordning (ny i början).

UPDATE användare SET age \u003d "18+" WHERE age \u003d (VÄLJ ålder FRA användare WHERE male \u003d "man");
Ovanstående är ett exempel på den så kallade begäran på begäran i SQL. Uppdatera användarens ålder till 18+ där könet är manligt. Jag rekommenderar inte sådana frågeställningsalternativ. Av personlig erfarenhet kommer jag att säga att det är bättre att skapa flera separata - de kommer att arbeta snabbare.

8. Frågor till MySQL och PHP-databaser

I MySQL-frågor på en PHP-sida kan du infoga variabler som jämförelser och andra värden. Ett par exempel

1. Väljer alla poster från tabellen användarevar är fältet fname matchar värdet på variabeln $ namn.

VÄLJ * FRÅN användare WHERE fname \u003d "$ name";
2. I tabellen användare VAR ID är 3 fältvärde ålder ändrar värdet på $ åldersvariabeln.

UPDATE användare SET age \u003d "$ age" WHERE id \u003d "3";

Uppmärksamhet! Om du är intresserad av något annat exempel, skriv en fråga i kommentarerna!

Hur optimerar jag MySQL-frågor?


För en vanlig, inte särskilt besökt webbplats är det inte mycket skillnad om MySQL-databasfrågor är optimerade eller inte. Men för produktionsservrar under tung belastning är skillnaden mellan korrekt och felaktig SQL enorm, och vid körningstid kan de påverka tjänsternas beteende och tillförlitlighet betydligt. I den här artikeln kommer jag att täcka hur man skriver snabba frågor och faktorer som gör dem långsamma.

Varför MySQL?

Det talas idag mycket om Dig Data och annan ny teknik. NoSQL och molnlösningar är bra, men mycket populär mjukvara (som WordPress, phpBB, Drupal) körs fortfarande på MySQL. Migrering till de senaste lösningarna kan resultera i mer än bara konfigurationsändringar på servrar. Dessutom är MySQL-prestanda fortfarande på nivå, särskilt Percona-versionen.

Gör inte det vanliga misstaget att dumpa mer och mer hårdvara för att lösa problemet med långsamma begäranden och hög serverbelastning - det är bättre att gå till roten till problemet. Att öka kraften hos processorer och hårddiskar och lägga till RAM är också en viss typ av optimering, men det är inte det vi kommer att prata om i den här artikeln. Genom att optimera webbplatsen och lösa problemet med hårdvara kommer belastningen bara att växa exponentiellt. Därför är detta bara en kortsiktig lösning.

En god förståelse av SQL är ett viktigt verktyg för en webbutvecklare för att effektivt optimera och använda relationella databaser. I den här artikeln kommer vi att fokusera på en populär öppen källkodsdatabas, som ofta används i samband med PHP, och det är MySQL.

Vem är den här artikeln för?

För webbutvecklare, databasarkitekter och utvecklare och systemadministratörer som är bekanta med MySQL. Om du inte har använt MySQL förut kanske den här artikeln inte hjälper dig, men jag ska fortfarande försöka vara så informativ och hjälpsam som möjligt, även för de som är nya i MySQL.

Säkerhetskopia först

Jag rekommenderar att du gör följande steg på MySQL-basen du arbetar med, men kom ihåg att göra en säkerhetskopia. Om du inte har en databas som du kan arbeta med kommer jag att ge exempel på hur du skapar en egen databas där det är lämpligt.

Att göra MySQL-säkerhetskopior är enkelt att använda mysqldump-verktyget:

$ mysqldump myTab\u003e myTab-backup.sql Du kan läsa mer om mysqldump.

Vad gör begäran långsam?

Här är en allmän lista över faktorer som påverkar fråga hastighet och serverbelastning:

  • index för tabeller;
  • vAR-klausul (och med användning av interna MySQL-funktioner som IF eller DATE);
  • sortering efter ORDER BY;
  • frekvent upprepning av samma förfrågningar;
  • lagringsmotortyp (InnoDB, MyISAM, Memory, Blackhole);
  • använder inte Percona-versionen;
  • serverkonfiguration (my.cnf / my.ini);
  • stora datautgångar (mer än 1000 rader);
  • instabil anslutning;
  • distribuerad eller klusterad konfiguration;
  • dålig utformning av bord.
Vi behandlar alla dessa problem nedan. Installera också Percona om du inte redan använder den inbyggda ersättningen för standard MySQL - det kommer att ge en enorm ökning av databaskraften.

Vad är index?

Index används i MySQL för att söka efter rader med specificerade kolumnvärden, till exempel med WHERE-kommandot. Utan index måste MySQL, från första raden, läsa hela tabellen för att leta efter relevanta värden. Ju större bordet, desto fler kostnader.

Om tabellen har index på kolumnerna som kommer att användas i frågan kommer MySQL snabbt att hitta informationen den behöver utan att titta på hela tabellen. Detta är mycket snabbare än att söka efter varje rad i följd.

En instabil anslutning?

När din applikation ansluter till databasen och en ihållande anslutning är konfigurerad, kommer den att användas varje gång utan att behöva öppna en ny anslutning varje gång. Det är den optimala lösningen för din arbetsmiljö.

Minska frekvensen för duplikatförfrågningar

Det snabbaste och mest effektiva sättet jag hittat är att skapa en butik med frågor och deras resultat med hjälp av Memcached eller Redis. Med Memcache kan du enkelt cache resultatet av din fråga, så här:

anslut ("localhost", 11211); $ cacheResult \u003d $ cache-\u003e get ("nyckelnamn"); if ($ cacheResult) (// behöver inte frågan $ result \u003d $ cacheResult;) annars (// kör din fråga $ mysqli \u003d mysqli ("p: localhost", "användarnamn", "lösenord", "tabell"); // lägg till p: för kontraktslagring $ sql \u003d "VÄLJ * FRÅN inlägg LEFT JOIN userInfo använder (UID) WHERE posts.post_type \u003d" post "|| posts.post_type \u003d" artikel "ORDER BY column GRÄNS 50"; $ result \u003d $ mysqli-\u003e fråga ($ sql); $ memc-\u003e set ("nyckelnamn", $ resultat-\u003e fetch_array (), MEMCACHE_COMPRESSED, 86400);) // Lösenord $ cacheResultat till mallen $ mall-\u003e tilldela (" inlägg ", $ cacheResult); ?\u003e Nu kommer en tung fråga med LEFT JOIN att köras endast en gång på 86 400 sekund (det vill säga en gång om dagen), vilket avsevärt minskar belastningen på MySQL-servern och lämnar resurser för andra anslutningar.

Obs: Lägg till p: i början av MySQLi-värdargumentet för att skapa en ihållande anslutning.

Distribuerad eller klusterad konfiguration

När uppgifterna växer och hastigheten på din tjänst går neråt kan panik ta över. Skärmning kan vara en snabb lösning. Jag rekommenderar dock inte att göra detta om du inte har mycket erfarenhet, eftersom distribution i sig gör datastrukturer mer komplexa.

Svag borddesign

Att designa databasscheman är inte hårt arbete om du följer de gyllene reglerna för att hantera begränsningar och veta vad som kommer att fungera. Att till exempel lagra bilder i BLOB-celler är väldigt förvirrande - bättre att hålla filvägen i en VARCHAR-cell, detta är en mycket bättre lösning.

Att säkerställa rätt design för rätt användning är avgörande för att bygga din applikation. Lagra olika data i olika tabeller (som kategorier och artiklar) och se till att många till en och en till många relationer enkelt kan kopplas till ID. Att använda FOREIGN KEY i MySQL är idealiskt för att lagra kaskaddata i tabeller.

Kom ihåg följande när du skapar ditt bord:

  • Skapa effektiva tabeller för att lösa dina problem istället för att fylla tabeller med onödiga data och anslutningar.
  • Förvänta dig inte att MySQL ska göra din affärslogik eller programmatik - uppgifterna ska vara redo för stränginsättning i ditt skriptspråk. Om du till exempel behöver sortera en lista i slumpmässig ordning gör du den i en PHP-array utan att använda ORDER BY från MySQL-arsenal.
  • Använd UNIQUE indextyper för unika datasätt och använd ON DUPLICATE KEY UPDATE för att hålla datumet uppdaterat, till exempel för att veta när en rad senast ändrades.
  • Använd INT-datatypen för att lagra heltal. Om du inte anger storleken på datatypen kommer MySQL att göra det åt dig.
Grunderna i optimering

För att kunna optimera effektivt måste vi ta tre metoder för din ansökan:

  1. Analys (logga in långsamma frågor, lära sig systemet, analysera frågor och designa databasen)
  2. Exekveringskrav (hur många användare)
  3. Teknologiska begränsningar (hårdvaruhastighet, MySQL-missbruk)
Analysen kan göras på flera sätt. Först ska vi titta på de mest uppenbara sätten att titta under huven på din MySQL där frågor utförs. Det allra första optimeringsverktyget i ditt arsenal är EXPLAIN. Om du lägger till detta uttalande före din SELECT-fråga är resultatet av frågan:

Som du ser lagrar kolumnerna viktig information om begäran. De kolumner som du bör beakta mest är möjliga_nycklar och Extra.

Kolumnen möjliga nycklar visar de index som MySQL hade tillgång till för att utföra frågan. Ibland måste du tilldela index för att göra din fråga snabbare. Kolumnen Extra visar om ytterligare WHERE eller ORDER BY har använts. Det viktigaste att lägga märke till är om att använda Filesort är i utgången.

Vad du använder Filesort gör anges i MySQL-hjälp:

MySQL måste ta ett extra pass för att ta reda på hur de raderade sorteras tillbaka. Denna sortering görs genom att iterera över alla rader beroende på typen av förening och bevara sorteringsknappen och radpekaren för alla rader som matchar WHERE-klausulen. Nycklarna sorteras och raderna returneras i rätt ordning.
Det extra passet bromsar din ansökan och bör undvikas till varje pris. Ett annat kritiskt resultat av Extra som vi bör undvika är att använda tillfälligt. Han säger att MySQL var tvungen att skapa en tillfällig tabell för att köra frågan. Uppenbarligen är detta en fruktansvärd användning av MySQL. I det här fallet bör resultatet av frågan lagras i Redis eller Memcache och inte köras av användare igen.

För att undvika att använda Filesort-problemet måste vi se till att MySQL använder INDEX. Det finns för närvarande flera nycklar som är specificerade i möjliga nycklar att välja mellan, men MySQL kan bara välja ett index för den sista frågan. Index kan också bestå av flera kolumner, och du kan också ange tips (tips) för MySQL-optimeringsprogrammet, pekande på de index som du har skapat.

Tips om index

MySQL-optimeraren kommer att använda statistik baserad på tabellfrågor för att välja det bästa indexet för att köra frågan. Det fungerar helt enkelt, baserat på inbyggd statistisk logik, så med flera alternativ gör det inte alltid rätt val utan att antyda. För att verifiera att rätt (eller felaktig) nyckel användes använder du FORCE INDEX, ANVÄND INDEX och IGNORE INDEX i din fråga. Du kan läsa mer om antydningsindex i MySQL-hjälp.

Använd kommandot SHOW INDEX för att lista tangenterna för en tabell. Du kan definiera flera tips som ska användas av optimeringsprogrammet.

Förutom att förklara finns det sökordet BESKRIV. Tillsammans med DESCRIBE kan du se information från tabellen på följande sätt:

Lägg till index

För att lägga till index till MySQL använder du CREATE INDEX-syntaxen. Det finns flera typer av index. FULLTEXT Används för fulltextsökning, och UNIK för att lagra unika data.

För att lägga till ett index i tabellen använder du följande syntax:

Mysql\u003e SKAPA INDEX idx_boknamn PÅ "böcker" (boknamn (10)); Detta skapar ett index på böktabellen som använder de första 10 bokstäverna från varchkolumnen som lagrar boktitlarna. I detta fall kommer varje WHERE-sökning på boktiteln med en matchning på upp till 10 tecken att ge samma resultat som att titta på hela tabellen från början till slut.

Sammansatta index

Index har stor inverkan på fråghastigheten. Att tilldela en helt unik nyckel ensam räcker inte - sammansatta nycklar är ett verkligt användningsfall i MySQL-konfiguration, som ibland kräver vissa A / B-kontroller med EXPLAIN.

Om vi \u200b\u200btill exempel behöver hänvisa till två kolumner i en WHERE-klausul, skulle en sammansatt nyckel vara idealisk.

Mysql\u003e CREATE INDEX idx_composite ON-användare (användarnamn, aktiv); När vi har skapat en nyckel baserad på användarnamnskolumnen, som lagrar användarnamn och den aktiva ENUM-kolumnen, som avgör om hans konto är aktivt. Allt är nu optimerat för en fråga som använder WHERE för att hitta ett giltigt användarnamn med ett aktivt konto (aktiv \u003d 1).

Hur snabb är din MySQL?

Låt oss slå på profilering för att titta närmare på MySQL-frågor. Detta kan göras genom att utfärda kommandon set profiling \u003d 1, varefter du måste utföra showprofiler för att se resultatet.

Om du använder PDO, kör följande kod:

$ db-\u003e fråga ("set profiling \u003d 1"); $ db-\u003e fråga ("välj rubrik, kropp, taggar från inlägg"); $ rs \u003d $ db-\u003e fråga ("visa profiler"); $ db-\u003e fråga ("set profiling \u003d 0"); // inaktivera profilering efter att frågan $ records \u003d $ rs-\u003e fetchAll (PDO :: FETCH_ASSOC) har utförts; // få profileringsresultat $ errmsg \u003d $ rs-\u003e errorInfo (); // Fånga några fel här. Samma kan göras med mysqli:

$ db \u003d nytt mysqli ($ värd, $ användarnamn, $ lösenord, $ dbnamn); $ db-\u003e fråga ("set profiling \u003d 1"); $ db-\u003e fråga ("välj rubrik, kropp, taggar från inlägg"); if ($ resultat \u003d $ db-\u003e fråga ("VISA profiler", MYSQLI_USE_RESULT)) (medan ($ rad \u003d $ resultat-\u003e fetch_row ()) (var_dump ($ rad);) $ resultat-\u003e stäng ();) if ($ resultat \u003d $ db-\u003e fråga ("visa profil för fråga 1", MYSQLI_USE_RESULT)) (medan ($ rad \u003d $ resultat-\u003e fetch_row ()) (var_dump ($ rad);) $ resultat-\u003e stäng ( );) $ db-\u003e fråga ("set profiling \u003d 0"); Detta ger dig profilerade data som innehåller körningstiden för frågan i det andra elementet i den associerande matrisen.

Array (3) (\u003d\u003e string (1) "1" \u003d\u003e string (10) "0.00024300" \u003d\u003e string (17) "välj rubrik, karaktär, taggar från inlägg") Denna fråga tog 0.00024300 sekunder. Det är ganska snabbt, så låt oss inte oroa oss. Men när siffrorna blir stora måste vi titta djupare. Gå till din ansökan för att öva med ett fungerande exempel. Kontrollera DEBUG-konstanten i din databaskonfiguration och börja sedan utforska systemet genom att aktivera profileringsutgången med var_dump eller print_r. Detta låter dig navigera från sida till sida i din applikation och få en bekväm systemprofilering.

Fullständig granskning av din webbplatsdatabas

Aktivera loggning för att göra en fullständig granskning av dina förfrågningar. Vissa webbplatsbyggare oroar sig för att loggning har en stor inverkan på prestandan och saktar ytterligare ned förfrågningarna. Men praxis visar att skillnaden är obetydlig.

För att aktivera loggning i MySQL 5.1.6, använd den globala variabeln log_slow_queries, du kan också markera en fil för loggning med variabeln slow_query_log_file. Detta kan göras genom att köra följande fråga:

Ställ in global log_slow_queries \u003d 1; ställa global slow_query_log_file \u003d /dev/slow_query.log; Detta kan också anges i /etc/my.cnf- eller my.ini-konfigurationsfilerna för din server.

När du har gjort ändringarna, glöm inte att starta om MySQL-servern med det nödvändiga kommandot, till exempel service mysql omstart om du använder Linux.

I MySQL-versioner efter 5.6.1 avskrivs variabeln log_slow_queries och istället används slow_query_log. För enklare felsökning kan du också aktivera utmatningen i tabellen genom att ställa in variabeln log_output till TABELL, men den här funktionen är endast tillgänglig med MySQL 5.6.1.

Log_output \u003d TABELL; log_queries_not_using_indexes \u003d 1; long_query_time \u003d 1; Variabeln long_query_time definierar antalet sekunder varefter frågan anses vara långsam. Värdet är 10 och minimum är 0. Du kan också ange millisekunder med en bråkdel; nu har jag angett en sekund. Och nu loggas varje fråga som tar längre än 1 sekund i tabellen.

Loggning kommer att göras i tabellerna mysql.slow_log och mysql.general_log i din MySQL-databas. För att stänga av loggning, ändra log_output till INGEN.

Loggar in på en produktionsserver

På en produktionsserver som betjänar klienter är det bättre att använda loggning endast under en kort period och att övervaka lasten för att inte skapa onödig belastning. Om din tjänst är överbelastad och omedelbar åtgärd behövs kan du försöka lyfta fram problemet med SHOW PROCESSLIST eller se informationen_schema.PROCESSLIST-tabellen med VÄLJ * FRA information_schema.PROCESSLIST;

Att logga alla förfrågningar på en produktionsserver kan ge dig mycket information och vara ett bra verktyg för forskningsändamål när du kontrollerar ett projekt, men loggar under långa perioder kommer inte att ge dig mycket användbar information jämfört med loggar under en period av upp till 48 timmar (försök spåra toppbelastningar för att ha chans att bättre undersöka utförandet av frågan).

Obs: Om du har en webbplats som upplever trafikvågor och ibland nästan utan den, till exempel en idrottsplats under lågsäsongen, använd den här informationen för att bygga och studera loggning.

Loggar flera förfrågningar

Det är viktigt att vara medveten om inte bara frågor som tar längre tid än en sekund att slutföra, du måste också komma ihåg frågor som körs hundratals gånger. Även om förfrågningar genomförs snabbt, i ett laddat system, kan de dra alla resurser till sig själva.

Det är därför du alltid ska vara på jakt efter att du har gjort ändringar i ett live-projekt - detta är den mest kritiska tiden för vilken databas som ska fungera.

Varm och kall cache

Antalet förfrågningar och belastningen på servern påverkar exekveringen starkt och kan också påverka körningstiden för förfrågningar. När du utvecklar bör du göra det till en regel att genomförandet av varje begäran inte får vara mer än en bråkdel av ett millisekund (0,0xx eller snabbare) på en gratis server.

Användningen av Memcache har en stark inverkan på belastningen på servrar och frigör resurserna som kör förfrågningar. Se till att du använder Memcached effektivt och testa din applikation med het cache (laddad data) och kall cache.

För att undvika att köra på en produktionsserver med en tom cache är det en bra idé att ha ett skript som samlar in all nödvändig cache innan servern startas så att ett stort flöde av klienter inte minskar systemstarttiden.

Fixa långsamma frågor

Nu när loggningen är konfigurerad kan du hitta några långsamma förfrågningar på din webbplats. Låt oss fixa dem! Som exempel visar jag flera vanliga problem; du kan också komma över logiken för att fixa dem.

Om du inte hittat en långsam fråga ännu, kontrollera inställningarna för long_query_time om du använder den här loggmetoden. Annars, efter att ha kontrollerat alla dina profilförfrågningar (ställ in profilering \u003d 1), gör du en lista med förfrågningar som tar mer tid än en bråkdel av millisekunder (0,000x sekunder) och börja där.

Vanliga problem

Här är de sex vanligaste problemen jag har hittat när jag optimerade MySQL-frågor:

BESTÄLLNING AV och filsortera

Ibland är det inte möjligt att förhindra filsortering på grund av ORDER BY-klausulen. Spara resultatet i Memcache för optimering, eller gör sorteringen i din applikationslogik.

Använda ORDER BY med WHERE och Vänster GÅ MED

ORDER BY gör frågor mycket långsamma. Försök att inte använda ORDER BY om möjligt. Om du behöver sortera, använd indexsortering.

Använd ORDER BY på tillfälliga kolumner

Gör det bara inte. Om du behöver kombinera resultaten, gör det i din applikationslogik; använd inte filtrering eller sortering i en temporär tabell från MySQL-frågan. Det kräver mycket resurser.

Ignorera FULLTEXT-index

Att använda LIKE är det bästa sättet att göra fulltextsökningar långsamma.

Att välja ett stort antal rader utan anledning

Att glömma LIMIT i din fråga kan avsevärt öka hämtningstiden för databasen beroende på tabellens storlek.

Överanvändning av JOINs istället för att skapa sammansatta tabeller eller vyer

När du använder mer än tre eller fyra VÄNSTER-JOIN-uttalanden i en fråga, fråga dig själv: är allt rätt här? Fortsätt om du har en övertygande anledning, till exempel att frågan inte ofta används för utdata i adminpanelen, eller så kan utdata cachelagras. Om du behöver utföra en fråga med ett stort antal tabellkopplingsoperationer är det bättre att tänka på att skapa sammansatta tabeller från de önskade kolumnerna eller använda vyer.

så

Vi har diskuterat grunderna i optimering och de verktyg som behövs för att få jobbet gjort. Vi undersökte systemet med hjälp av profilering och EXPLAIN-uttalandet för att se vad som hände med databasen och hur vi kunde förbättra strukturen.

Vi tittade också på några exempel och klassiska fallgropar som du kan falla i med MySQL. Genom att använda indextips kan vi se till att MySQL väljer de index vi behöver, särskilt när flera val görs i samma tabell. För att fortsätta utforska ämnet, rekommenderar jag att du ser mot Percona-projektet.

Databasverksamhet blir ofta en flaskhals när man implementerar ett webbprojekt. Optimeringsproblem i sådana fall är inte begränsade till databasadministratören. Programmerare måste strukturera tabeller ordentligt, skriva bättre frågor och skriva mer effektiv kod. Den här artikeln innehåller en kort lista med MySQL-optimeringstekniker för programmerare.

1. Optimera dina frågor för frågecachen.

De flesta MySQL-servrar använder cache-fråga. Det är en av de mest effektiva prestandaförbättrande teknikerna som databasmotorn kör i bakgrunden. Om frågan körs många gånger börjar cachen att användas för att få resultatet och operationen är mycket snabbare.

Problemet är att det är så enkelt och samtidigt dolt för utvecklaren, och de flesta programmerare ignorerar denna fantastiska möjlighet att förbättra projektets prestanda. Vissa aktiviteter kan faktiskt skapa hinder för användningen av frågecachen vid körning.

// Fråga-cachen fungerar inte $ r \u003d mysql_query ("VÄLJ användarnamn FRÅN användaren VAR signup_date\u003e \u003d CURDATE ()"); // Begär cache ARBETE! $ idag \u003d datum ("Y-m-d"); $ r \u003d mysql_query ("VÄLJ användarnamn FRÅN användaren VAR signup_date\u003e \u003d" $ idag "");

Anledningen till att frågecachen inte fungerar i första fallet är att använda funktionen KURDAT ()... Detta tillvägagångssätt används för alla icke-deterministiska funktioner som NU (), RAND () etc. Eftersom funktionens returresultat kan ändras beslutar MySQL att inte cache-fråga denna fråga. Allt som krävs för att fixa situationen är att lägga till en extra rad med PHP-kod före begäran.

2. Använd EXPLAIN för dina VÄLJ-frågor

Med hjälp av EXPLAIN-nyckelordet kan du få en bild av vad MySQL gör för att uppfylla din fråga. Den här bilden gör det enkelt att identifiera flaskhalsar och andra problem i frågor eller tabellstruktur.

Resultatet av en EXPLAIN-fråga visar vilka index som används, hur tabellen skannas och sorteras och så vidare.

Ta en VÄLJ-fråga (helst komplex, med en JOIN), lägg till EXPLAIN-sökordet framför den. Du kan använda PhpMyAdmin för detta. En sådan fråga skickar resultatet till ett vackert bord. Låt oss säga att vi glömde att lägga till ett index i kolumnen som används för JOIN:

Efter att ha lagt till index för fältet group_id:

Istället för att skanna 7883 rader, skannas endast 9 och 16 rader från två tabeller. En bra metod för att utvärdera prestanda är att multiplicera alla siffror i kolumnen "rader". Resultatet är ungefär proportionellt mot mängden data som bearbetas.

3. Använd LIMIT 1 om du behöver få en unik sträng

Ibland, när du använder en fråga, vet du redan att du bara letar efter en rad. Du kan få en unik post, eller så kan du helt enkelt kontrollera att det finns ett antal poster som uppfyller WHERE-klausulen.

Om du lägger till LIMIT 1 till din fråga kan det i så fall förbättra prestandan. Under detta villkor slutar databasmotorn att skanna poster så fort den hittar en och inte korsar hela tabellen eller indexet.

// Finns det någon användare från Alabama? // Gör inte detta: $ r \u003d mysql_query ("VÄLJ * FRÅN användaren VAR tillstånd \u003d" Alabama ""); if (mysql_num_rows ($ r)\u003e 0) (// ...) // Detta är mycket bättre: $ r \u003d mysql_query ("VÄLJ 1 FRÅN användare VAR tillstånd \u003d" Alabama "GRÄNS 1"); if (mysql_num_rows ($ r)\u003e 0) (// ...)

4. Indexera sökfält

Indexera mer än primära och unika nycklar. Om några kolumner i din tabell används för sökningar, måste de indexeras.

Som du kan se gäller denna regel också för sökningar inom en del av en sträng, till exempel "efternamn LIKE" a% ". När början av en sträng används för sökningar kan MySQL använda indexet för kolumnen som söks.

Du bör också ta reda på vilka typer av sökningar du inte kan använda regelbunden indexering för. Om du till exempel söker efter ordet ("VAR post_content LIKE '% apple%'") kommer fördelarna med indexering inte att vara tillgängliga. I sådana fall är det bättre att använda mysql fulltextsökning eller bygga egna indexeringsbaserade lösningar.

5. Indexera och använda samma typer för länkade kolumner

Om din ansökan innehåller många JOIN-frågor måste du indexera kolumnerna som är länkade i båda tabellerna. Detta påverkar interna optimeringar för MySQL-bindningar.

Dessutom måste kolumnerna som ska bindas vara av samma typ. Om du till exempel länkar en DECIMAL-kolumn till en INT-kolumn från en annan tabell kan MySQL inte använda indexet i minst en av de två tabellerna. Även teckenkodningen måste vara densamma för samma strängtypskolumner.

// Sök efter ett företag från ett specifikt tillstånd $ r \u003d mysql_query ("VÄLJ företagsnamn FRÅN användare VÄNSTER GÅ MED företag PÅ (användare.stat \u003d företag.stat) VAR användare.id \u003d $ användare_id"); // båda tillståndskolumnerna måste vara indexerade // och båda måste vara av samma typ och teckenkodning // eller MySQL gör en fullständig tabellscanning

6. Använd inte ORDER BY RAND ()

Detta är ett av de coola knepen och många nybörjare som programmerar faller i sin fälla. De kan inte ens föreställa sig vilket fruktansvärt problem de skapar för sig själva genom att använda detta uttryck i sina frågor.

Om du verkligen behöver randomisera rader till följd av din fråga finns det många bättre sätt att göra detta. Naturligtvis kommer detta att göras med ytterligare kod, men du kommer att räddas från ett problem som växer exponentiellt med tillväxten av data. Detta beror på att MySQL utför en RAND () -operation (som tar CPU-tid) för varje enskild rad i tabellen innan du sorterar den och ger dig bara en rad.

// Detta är INTE NÖDVÄNDIGT: $ r \u003d mysql_query ("VÄLJ användarnamn FRA användare ORDER BY RAND () BEGRÄNSNING 1"); // Detta fungerar bättre: $ r \u003d mysql_query ("SELECT count (*) FRA user"); $ d \u003d mysql_fetch_row ($ r); $ rand \u003d mt_rand (0, $ d - 1); $ r \u003d mysql_query ("VÄLJ användarnamn FRÅN användaren LIMIT $ rand, 1");

Detta ger dig ett slumpmässigt antal som är mindre än antalet rader i frågan och använder det som en kompensation i LIMIT-klausulen.

7. Försök att inte använda SELECT *

Ju mer data läses från tabellen, desto långsammare kommer frågan att köras. Sådana operationer tar också tid att slutföra diskoperationer. Och om databaseservern är separat från webbservern, kommer latens också att orsakas av överföring av data över nätverket mellan servrarna.

Det är en god vana att ange en kolumn när du gör SELECT.

// Dåligt: \u200b\u200b$ r \u003d mysql_query ("VÄLJ * FRÅN användaren VAR user_id \u003d 1"); $ d \u003d mysql_fetch_assoc ($ r); echo "Välkommen ($ d [" användarnamn "])"; // Detta är bättre: $ r \u003d mysql_query ("VÄLJ användarnamn FRÅN användaren VAR user_id \u003d 1"); $ d \u003d mysql_fetch_assoc ($ r); echo "Välkommen ($ d [" användarnamn "])"; // Skillnaden blir betydande för stora datamängder

8. Försök att använda ID-fältet överallt

Det är bra att använda ett id-fält i varje tabell som är inställd på PRIMARY KEY, AUTO_INCREMENT och är av typen INT. Helst UNISIGNED, eftersom värdet i detta fall inte kan vara negativt.

Även om ditt bord har ett fält med ett unikt användarnamn, gör det inte till den primära nyckeln. VARCHAR-fälten är långsamma att fungera som primära nycklar. Strukturen för din databas blir också bättre om du använder referenser till poster baserade på id inuti den.

Dessutom använder MySQL-motorn primära nycklar för sina interna uppgifter, och användningen av id-fältet skapar optimala förutsättningar för deras lösning.

Ett möjligt undantag från denna regel är "associativa tabeller", som används för förhållanden mellan många till två mellan två andra tabeller. Till exempel innehåller tabellen "posts_tags" två kolumner: post_id, tag_id. De används för att beskriva förhållandet mellan två tabeller "post" och "tags". Den beskrivna tabellen kan ha en primär nyckel som innehåller båda ID-fälten.

9. Använd ENUM istället för VARCHAR

// Skapa ett förberett uttalande om ($ stmt \u003d $ mysqli-\u003e förbereda ("VÄLJ användarnamn FRÅN användaren VAR tillstånd \u003d?")) (// Bind parametrar $ stmt-\u003e bind_param ("s", $ state); // Utför $ stmt-\u003e execute (); // Bind resultatvariablerna $ stmt-\u003e bind_result ($ username); // Hämta värden $ stmt-\u003e fetch (); printf ("% s är från% s \\ n", $ username , $ state); $ stmt-\u003e close ();)

13. Obuffrade förfrågningar

Vanligtvis när du kör en begäran från ett skript avbryts skriptet tills begäran är klar. Denna beställning kan ändras med obuffrade förfrågningar.

Bra förklaring av funktionen mysql_unbuffered_query () från PHP-dokumentation:

“Mysql_unbuffered_query () skickar en SQL-fråga till MySQL-servern utan att automatiskt hämta och buffra resultatrader, som funktionen mysql_query () gör. Detta sparar en viss mängd minne med SQL-frågor som ger en stor uppsättning resultat, och du kan börja arbeta med resultatuppsättningen så snart den första raden tas emot, utan att vänta på att SQL-frågan ska slutföras. ”

Det finns dock flera begränsningar. Du måste antingen läsa alla rader eller ringa mysql_free_result () innan du kör nästa fråga. Du kan inte heller använda mysql_num_rows () eller mysql_data_seek () på en resultatset.

14. Lagra IP-adressen som UNSIGNED INT

Många programmerare skapar ett VARCHAR (15) -fält för att lagra en IP-adress utan att ens tänka på vad de kommer att lagra ett heltal i detta fält. Om du använder INT kommer fältet att reduceras till 4 byte och har en fast längd.

Du måste använda typen UNSIGNED INT, eftersom IP-adressen använder alla 32 bitar av ett osignerat heltal.

$ r \u003d "UPDATE användare SET ip \u003d INET_ATON (" ($ _ SERVER ["REMOTE_ADDR"]) ") WHERE user_id \u003d $ user_id";

15. Tabeller med fast inspelningslängd (statisk) är snabbare

När varje enskild kolumn i en tabell har en fast längd, behandlas hela tabellen som "statisk" eller "fast längd". Exempel på kolumntyper som inte är fast längd: VARCHAR, TEXT, BLOB. Om du inkluderar minst en kolumn av denna typ anses tabellen inte längre vara "statisk" och kommer att hanteras annorlunda av MySQL-motorn.

"Statiska" tabeller behandlas snabbare av MySQL-motorn när man letar upp poster. När du behöver läsa en specifik post i tabellen beräknas dess position snabbt. Om strängstorleken inte är fixerad tar det tid att hitta postens position och matcha mot det primära nyckelindexet.

Sådana tabeller är också lättare att cache och lättare att återställa efter fel. Men de kan ta mer plats. Om du till exempel konverterar ett VARCHAR (20) -fält till ett CHAR (20) -fält kommer 20 byte alltid att ockuperas, oavsett om de används eller inte.

Med hjälp av Vertical Split-tekniken kan du dela kolumner med variabel längd i en separat tabell.

16. Vertikal separering

Vertikal delning är handlingen att dela upp en tabellstruktur vertikalt för optimeringsändamål.

Exempel 1: Du har en tabell som innehåller hemadresser som sällan används i applikationen. Du kan dela upp ditt bord och lagra adresserna i en separat tabell. Detta minskar den stora användartabellen i storlek. Som du vet behandlas ett mindre bord snabbare.

Exempel 2: Du har ett "last_login" -fält i tabellen. Det uppdateras varje gång en användare registrerar sig på sajten. Men varje uppdatering av tabellen gör att frågan cachas, vilket kan skapa en systemöverbelastning. Du kan markera det här fältet till en annan tabell för att göra uppdateringar av användartabellen mindre frekvent.

Men du måste se till att du inte alltid behöver länka de två tabellerna du just delar upp, eftersom det kan leda till prestandaförstöring.

17. Separera stora DELETE- eller INSERT-uttalanden

Om du behöver utföra ett stort DELETE- eller INSERT-uttalande på en live-webbplats måste du vara försiktig så att du inte stör trafiken. När en stor fråga körs kan den låsa dina tabeller och få applikationen att stanna.

Apache kör många samtidiga processer / trådar. av detta skäl fungerar det mer effektivt när skriptet slutför körningen så snabbt som möjligt, så servern använder inte för många öppna anslutningar och processer som konsumerar resurser, särskilt minne.

Om du låser tabeller under en längre tid (till exempel 30 sekunder eller mer) på en mycket laddad webbserver kan du orsaka en ansamling av processer och förfrågningar, vilket tar en betydande tid att rensa eller till och med stoppa din webbserver.

Om du har ett skript som raderar ett stort antal poster använder du bara LIMIT-klausulen för att dela upp den i små partier för att undvika denna situation.

Medan (1) (mysql_query ("DELETE FROM logs WHERE log_date)<= "2009-10-01" LIMIT 10000"); if (mysql_affected_rows() == 0) { // выполняем удаление break; } // вы можете сделать небольшую паузу usleep(50000); }

18. Små kolumner behandlas snabbare

För databasmotorn är disken den viktigaste flaskhalsen. Att sträva efter att göra saker mindre och mindre fungerar vanligtvis bra för prestanda genom att minska mängden data som flyttas.

MySQL-dokumentationen innehåller en lista med lagringsstandarder för alla typer.

Om tabellen bara innehåller några få rader, finns det ingen anledning att göra den primära nyckeln av typen INT och inte MEDIUMINT, SMALLINT eller till och med TINYINT. Om du bara vill ha datum, använd DATE istället för DATETIME.

Du behöver bara komma ihåg tillväxtmöjligheterna.

19. Välj rätt lagringsmotor

Det finns två huvudlagringsmotorer för MySQL: MyISAM och InnoDB. Var och en har sina egna meriter och nedskärningar.

MyISAM är utmärkt för lästunga applikationer, men det skalar inte bra med många poster. Även om du uppdaterar ett fält i en rad kommer hela tabellen att låsas och ingen process kan läsa något förrän frågan är klar. MyISAM utför snabba beräkningar för frågor som SELECT COUNT (*).

InnoDB är en mer komplex lagringsmotor och kan vara långsammare än MyISAM för de flesta små applikationer. Men det stöder radlåsning, vilket är bättre för tabellskalning. Det stöder också några ytterligare funktioner som transaktioner.

20. Använd objekt-relationskartläggning

Det finns flera fördelar med att använda Object Relational Mapper (ORM). Allt som kan göras i en ORM kan göras manuellt, men med mer ansträngning och högre krav på utvecklarnivå.

ORM är utmärkt för lat laddning. Det betyder att du kan få värden när du behöver dem. Men du måste vara försiktig eftersom du kan skapa många små frågor som försämrar prestandan.

ORM kan också paketera dina frågor i transaktioner som är betydligt snabbare än enskilda databasfrågor.

För PHP kan du använda ORM Doctrine.

21. Var försiktig med ihållande anslutningar

Persistenta anslutningar är utformade för att minska förlusten av återställning av anslutningar till MySQL. När en ihållande anslutning skapas förblir den öppen även efter att skriptet är slut. Eftersom Apache återanvänder barnprocesser körs processen för det nya skriptet och använder samma MySQL-anslutning.

Det låter bra i teorin. Men i verkligheten är den här funktionen inte värd ett kopparöre på grund av problemen. Det kan orsaka allvarliga problem med anslutningsgränser, överflöden av minne osv.

Apache arbetar med principen om samtidighet och skapar många barnprocesser. Detta är anledningen till att ihållande anslutningar inte fungerar som förväntat på detta system. Innan du använder funktionen mysql_pconnect () ska du kontakta din systemadministratör.


2020 gtavrl.ru.