1 Anv\u00e4nd alltid r\u00e4tt datatyp<\/strong><\/h2>\nEn av de viktigaste MySQL b\u00e4sta metoderna \u00e4r att anv\u00e4nda datatyper baserade p\u00e5 datas natur. Att anv\u00e4nda irrelevanta datatyper kan ta mer utrymme eller leda till fel.<\/p>\n
Till exempel: Att anv\u00e4nda varchar (20) ist\u00e4llet f\u00f6r DATETIME-datatypen f\u00f6r att lagra datum- och tidsv\u00e4rden kommer att leda till fel i datum- och tidsrelaterade ber\u00e4kningar. Det \u00e4r ocks\u00e5 m\u00f6jligt att ogiltiga data kommer att lagras.<\/p>\n
2 Anv\u00e4nd CHAR (1) \u00f6ver VARCHAR (1)<\/strong><\/h2>\nVARCHAR (1) tar extra byte f\u00f6r att lagra information, s\u00e5 om du str\u00e4nger ett enda tecken, \u00e4r det b\u00e4ttre att anv\u00e4nda CHAR (1).<\/p>\n
3 Anv\u00e4nd CHAR-datatypen f\u00f6r att endast lagra data med fast l\u00e4ngd<\/strong><\/h2>\nTill exempel: Om l\u00e4ngden p\u00e5 data \u00e4r mindre \u00e4n 1000, kommer anv\u00e4ndning av char (1000) ist\u00e4llet f\u00f6r varchar (1000) att f\u00f6rbruka mer utrymme.<\/p>\n
4 Undvik att anv\u00e4nda regionala datumformat<\/strong><\/h2>\nN\u00e4r du anv\u00e4nder datatypen DATETIME eller DATE ska du alltid anv\u00e4nda datumformatet \u00c5\u00c5\u00c5\u00c5-MM-DD eller ISO-datumformatet som passar din SQL Engine. Regionala format som DD-MM-\u00c5\u00c5\u00c5\u00c5 eller MM-DD-\u00c5\u00c5\u00c5\u00c5 kommer inte att lagras korrekt.<\/p>\n
5 Index nyckelkolumner<\/strong><\/h2>\nDet \u00e4r \u00f6nskv\u00e4rt att fr\u00e5gan returnerar resultatet snabbt, s\u00e5 se till att indexera kolumnerna som anv\u00e4nds i JOIN-satser.<\/p>\n
Om du anv\u00e4nder UPDATE-satsen som involverar mer \u00e4n en tabell, se till att indexera alla kolumner som anv\u00e4nds f\u00f6r att sammanfoga tabellerna.<\/p>\n
6 Anv\u00e4nd inte funktioner \u00f6ver indexerade kolumner…<\/strong><\/h2>\n\u2026 f\u00f6r d\u00e5 tappar indexet sitt syfte.<\/p>\n
Anta till exempel att du vill f\u00e5 data d\u00e4r de tv\u00e5 f\u00f6rsta tecknen i kundkoden \u00e4r AK. Skriva:<\/p>\n
SELECT columns FROM table WHERE customer_code like 'AK%'<\/code><\/p>\noch skriv inte<\/p>\n
SELECT columns FROM table WHERE left (customer_code,2)='AK\u2019<\/code><\/p>\nVarf\u00f6r? Det f\u00f6rsta exemplet kommer att anv\u00e4nda indexet, vilket kommer att resultera i en snabbare svarstid.<\/p>\n
7 Anv\u00e4nd SQL SELECT * endast om det beh\u00f6vs<\/strong><\/h2>\nF\u00f6lj listan \u00f6ver MySQL b\u00e4sta praxis, anv\u00e4nd inte bara blint SELECT * i koden. Om tabellen har m\u00e5nga kolumner kommer alla att returneras. Detta kommer att sakta ner svarstiden, s\u00e4rskilt om du skickar resultatet till en front-end-applikation.<\/p>\n
Skriv i st\u00e4llet uttryckligen de kolumnnamn som faktiskt beh\u00f6vs.<\/p>\n
Notera: kom ih\u00e5g att alla SELECT-satser kr\u00e4ver en WHERE-sats.<\/p>\n
8 Anv\u00e4nd endast ORDER BY-klausul om det beh\u00f6vs<\/strong><\/h2>\nOm du vill visa resultatet i front-end-applikationen, l\u00e5t den BEST\u00c4LLA resultatupps\u00e4ttningen. Om du g\u00f6r detta i SQL kan svarstiden bli l\u00e5ngsammare i fleranv\u00e4ndarmilj\u00f6n.<\/p>\n
9 V\u00e4lj en l\u00e4mplig databasmotor<\/strong><\/h2>\nOm du utvecklar en applikation som l\u00e4ser data oftare \u00e4n att skriva (t.ex. en s\u00f6kmotor), v\u00e4lj MyISAM-lagringsmotor.<\/p>\n
Att v\u00e4lja fel lagringsmotor kommer att p\u00e5verka prestandan.<\/p>\n
10 Anv\u00e4nd EXISTS-klausulen d\u00e4r det beh\u00f6vs<\/strong><\/h2>\nF\u00f6r att kontrollera f\u00f6rekomsten av data, anv\u00e4nd EXISTS-satsen som \u00e4r snabbare i svarstid. Anv\u00e4nd till exempel:<\/p>\n
If EXISTS(SELECT * from Table WHERE col=\u2019some value\u2019)<\/code><\/p>\nAnv\u00e4nd inte :<\/p>\n
If (SELECT count(*) from Table WHERE col=\u2019some value\u2019)>0<\/code><\/p>\n11 F\u00d6RKLARA dina SELECT-fr\u00e5gor<\/strong><\/h2>\nOm du anv\u00e4nder nyckelordet EXPLAIN kan du f\u00e5 insikt om vad MySQL g\u00f6r f\u00f6r att utf\u00f6ra din fr\u00e5ga. Detta kan hj\u00e4lpa dig att uppt\u00e4cka problem med din fr\u00e5ga eller tabellstrukturer (t.ex. flaskhalsar).<\/p>\n
En EXPLAIN-fr\u00e5ga resulterar i att visa dig vilka index som anv\u00e4nds, hur tabellen skannas, sorteras, etc.<\/p>\n
Allt du beh\u00f6ver g\u00f6ra \u00e4r att l\u00e4gga till nyckelordet EXPLAIN framf\u00f6r en SELECT-fr\u00e5ga (helst en komplex med joins). Dessutom, om du anv\u00e4nder phpmyadmin f\u00f6r detta, kommer dina resultat att visas i en trevlig tabell.<\/p>\n
12 Anv\u00e4nd LIMIT 1 n\u00e4r du f\u00e5r en unik rad<\/strong><\/h2>\nIbland vet du i f\u00f6rv\u00e4g att du bara letar efter en rad n\u00e4r du fr\u00e5gar efter dina tabeller. Du kanske till exempel h\u00e4mtar en unik post, eller s\u00e5 kanske du bara kontrollerar att det finns ett antal poster som uppfyller din WHERE-sats.<\/p>\n
I s\u00e5dana fall vill du anv\u00e4nda MySQL limit-funktionen f\u00f6r att \u00f6ka prestandan. H\u00e4r \u00e4r en annan av MySQL b\u00e4sta praxis: l\u00e4gg bara till LIMIT 1 i din fr\u00e5ga. P\u00e5 s\u00e5 s\u00e4tt beh\u00f6ver inte databasmotorn g\u00e5 igenom hela tabellen eller indexet. Den kommer att sluta skanna n\u00e4r den bara hittar en post av det du letar efter.<\/p>\n
\/\/ do I have anyusersfrom Alabama?<\/code><\/p>\n\/\/ vad man INTE ska g\u00f6ra:
\n$r = mysql_query(”SELECT * FROM user WHERE state = ’Alabama’");
\nif (mysql_num_rows($r) > 0) {
\n\/\/ \u2026
\n}<\/p>\n
\/\/ mycket b\u00e4ttre:
\n$r = mysql_query(”SELECT 1 FROM user WHERE state = ’Alabama’ LIMIT 1");
\nif (mysql_num_rows($r) > 0) {
\n\/\/ \u2026
\n}<\/p>\n
13 Indexera och anv\u00e4nd samma kolumntyper f\u00f6r kopplingar<\/strong><\/h2>\nEtt annat viktigt tips om MySQL b\u00e4sta praxis \u2013 om din applikation har m\u00e5nga JOIN-fr\u00e5gor, se till att kolumnerna du g\u00e5r med i \u00e4r indexerade i b\u00e5da tabellerna. Detta p\u00e5verkar den interna optimeringen av join-operationen av MySQL.<\/p>\n
Dessutom m\u00e5ste de sammanfogade kolumnerna vara av samma typ. Om du till exempel kopplar en DECIMAL-kolumn till en INT-kolumn fr\u00e5n en annan tabell, kommer MySQL inte att kunna anv\u00e4nda n\u00e5got av indexen. \u00c4ven teckenkodningarna m\u00e5ste vara av samma typ f\u00f6r kolumner av str\u00e4ngtyp.<\/p>\n
\/\/ looking for companies in my state $r = mysql_query(\"SELECT company_name FROM users LEFT JOIN companies ON (users.state = companies.state) WHERE users.id = $user_id\");<\/code><\/p>\n\/\/ b\u00e5da tillst\u00e5ndskolumnerna b\u00f6r indexeras
\n\/\/ och de b\u00e5da ska vara av samma typ och teckenkodning
\n\/\/ eller s\u00e5 kan MySQL g\u00f6ra genoms\u00f6kningar av hela tabeller<\/p>\n
14 D\u00f6lj MySQL fr\u00e5n Internet<\/strong><\/h2>\nErfarna databasadministrat\u00f6rer och s\u00e4kerhetspersonal vet det \u2013 v\u00e4rd aldrig databasen under webbserverns rot.<\/p>\n
F\u00f6r webbaktiverade applikationer b\u00f6r MySQL d\u00f6ljas bakom en brandv\u00e4gg. Kommunikation b\u00f6r endast aktiveras mellan applikationsservrar och dina webbservrar.<\/p>\n
Ett annat alternativ \u00e4r att anv\u00e4nda MySQL skip-n\u00e4tverk. N\u00e4r det \u00e4r aktiverat, lyssnar MySQL endast efter lokala socket-anslutningar och ignorerar alla TCP-portar.<\/p>\n
15 Anv\u00e4nd de minsta m\u00f6jliga datatyperna<\/strong><\/h2>\n![\"22](\"https:\/\/wordpress.mediadoma.com\/wp-content\/uploads\/2022\/01\/post-206970-61e8d4b73d55e.jpg\")
<\/a><\/p>\nL\u00e5t mig ber\u00e4tta en historia. N\u00e4r jag gick p\u00e5 college var filosofin att "minnet \u00e4r knappt". Det var de dagar med 256 MB h\u00e5rddiskar. Nuf\u00f6rtiden verkar ingen bry sig ett dugg om minne eller h\u00e5rddiskutrymme. Den nya filosofin \u00e4r att "minnet \u00e4r billigt". Det kan vara sant i dollartermer, men att l\u00e4sa stora datatyper tar fortfarande l\u00e4ngre tid \u00e4n att l\u00e4sa mindre. Stora datatyper kr\u00e4ver att fler skivsektorer kan l\u00e4sas in i minnet.<\/p>\n
Moralen \u00e4r att ignorera frestelsen att omedelbart hoppa till den st\u00f6rsta datatypen n\u00e4r du designar dina tabeller. T\u00e4nk p\u00e5 att anv\u00e4nda en int ist\u00e4llet f\u00f6r en bigint.<\/p>\n
Undvik ocks\u00e5 largechar (255) textf\u00e4lt n\u00e4r en varchar eller mindre char r\u00e4cker.<\/p>\n
Om du anv\u00e4nder r\u00e4tt datatyp kommer fler poster att f\u00e5 plats i minnet eller indexnyckelblocket. Detta leder till f\u00e4rre l\u00e4sningar och snabbare prestanda.<\/p>\n
16 Utnyttja query caching<\/strong><\/h2>\nCachning av fr\u00e5gor \u00e4r en av de mest effektiva metoderna f\u00f6r att f\u00f6rb\u00e4ttra prestandan. De flesta MySQL-servrar har det aktiverat som standard.<\/p>\n
Fr\u00e5gecachen lagrar texten i en SELECT-sats tillsammans med motsvarande resultatupps\u00e4ttning. Om servern senare f\u00e5r en identisk sats kommer den att h\u00e4mta resultaten fr\u00e5n fr\u00e5gecachen ist\u00e4llet f\u00f6r att analysera och k\u00f6ra satsen igen. Fr\u00e5gecachen delas mellan sessioner, s\u00e5 en resultatupps\u00e4ttning som genereras av en klient kan skickas som svar p\u00e5 samma fr\u00e5ga fr\u00e5n en annan klient.<\/p>\n
Men hur bra det \u00e4n \u00e4r har query caching sina begr\u00e4nsningar. Ta f\u00f6ljande uttalande:<\/p>\n
Problemet h\u00e4r \u00e4r att fr\u00e5gor inneh\u00e5ller vissa icke-deterministiska funktioner, som NOW() och RAND(). MySQL kan inte ber\u00e4kna s\u00e5dana funktioner i f\u00f6rv\u00e4g, s\u00e5 det slutar med att de inte cachelagras.<\/p>\n
Lyckligtvis finns det en enkel l\u00f6sning p\u00e5 det: du kan lagra funktionsresultaten i en variabel.<\/p>\n
17 Redigera inte dumpfiler<\/strong><\/h2>\nDumpfiler \u00e4r mycket vilseledande och kan orsaka korruption. Varf\u00f6r? Om du n\u00e5gonsin har sett dumpfilerna skapade av mysqldump, kommer du att h\u00e5lla med om att de ser ut som vanliga, ofarliga textfiler. Det \u00e4r d\u00e4rf\u00f6r de flesta redigerar dem i en vanlig textredigerare, vilket g\u00f6r att korruptioner uppst\u00e5r.<\/p>\n
Om du n\u00e5gonsin har provat att redigera dumpfiler l\u00e4rde du dig snabbt att de \u00e4r allt annat \u00e4n en textfil. S\u00e5 det enda garanterade s\u00e4ttet att undvika problem \u00e4r att l\u00e4mna dumpfilerna ifred.<\/p>\n
18 Anv\u00e4nd MyISAM-blockstorleksinst\u00e4llningen<\/strong><\/h2>\n
VARCHAR (1) tar extra byte f\u00f6r att lagra information, s\u00e5 om du str\u00e4nger ett enda tecken, \u00e4r det b\u00e4ttre att anv\u00e4nda CHAR (1).<\/p>\n
3 Anv\u00e4nd CHAR-datatypen f\u00f6r att endast lagra data med fast l\u00e4ngd<\/strong><\/h2>\nTill exempel: Om l\u00e4ngden p\u00e5 data \u00e4r mindre \u00e4n 1000, kommer anv\u00e4ndning av char (1000) ist\u00e4llet f\u00f6r varchar (1000) att f\u00f6rbruka mer utrymme.<\/p>\n
4 Undvik att anv\u00e4nda regionala datumformat<\/strong><\/h2>\nN\u00e4r du anv\u00e4nder datatypen DATETIME eller DATE ska du alltid anv\u00e4nda datumformatet \u00c5\u00c5\u00c5\u00c5-MM-DD eller ISO-datumformatet som passar din SQL Engine. Regionala format som DD-MM-\u00c5\u00c5\u00c5\u00c5 eller MM-DD-\u00c5\u00c5\u00c5\u00c5 kommer inte att lagras korrekt.<\/p>\n
5 Index nyckelkolumner<\/strong><\/h2>\nDet \u00e4r \u00f6nskv\u00e4rt att fr\u00e5gan returnerar resultatet snabbt, s\u00e5 se till att indexera kolumnerna som anv\u00e4nds i JOIN-satser.<\/p>\n
Om du anv\u00e4nder UPDATE-satsen som involverar mer \u00e4n en tabell, se till att indexera alla kolumner som anv\u00e4nds f\u00f6r att sammanfoga tabellerna.<\/p>\n
6 Anv\u00e4nd inte funktioner \u00f6ver indexerade kolumner…<\/strong><\/h2>\n\u2026 f\u00f6r d\u00e5 tappar indexet sitt syfte.<\/p>\n
Anta till exempel att du vill f\u00e5 data d\u00e4r de tv\u00e5 f\u00f6rsta tecknen i kundkoden \u00e4r AK. Skriva:<\/p>\n
SELECT columns FROM table WHERE customer_code like 'AK%'<\/code><\/p>\noch skriv inte<\/p>\n
SELECT columns FROM table WHERE left (customer_code,2)='AK\u2019<\/code><\/p>\nVarf\u00f6r? Det f\u00f6rsta exemplet kommer att anv\u00e4nda indexet, vilket kommer att resultera i en snabbare svarstid.<\/p>\n
7 Anv\u00e4nd SQL SELECT * endast om det beh\u00f6vs<\/strong><\/h2>\nF\u00f6lj listan \u00f6ver MySQL b\u00e4sta praxis, anv\u00e4nd inte bara blint SELECT * i koden. Om tabellen har m\u00e5nga kolumner kommer alla att returneras. Detta kommer att sakta ner svarstiden, s\u00e4rskilt om du skickar resultatet till en front-end-applikation.<\/p>\n
Skriv i st\u00e4llet uttryckligen de kolumnnamn som faktiskt beh\u00f6vs.<\/p>\n
Notera: kom ih\u00e5g att alla SELECT-satser kr\u00e4ver en WHERE-sats.<\/p>\n
8 Anv\u00e4nd endast ORDER BY-klausul om det beh\u00f6vs<\/strong><\/h2>\nOm du vill visa resultatet i front-end-applikationen, l\u00e5t den BEST\u00c4LLA resultatupps\u00e4ttningen. Om du g\u00f6r detta i SQL kan svarstiden bli l\u00e5ngsammare i fleranv\u00e4ndarmilj\u00f6n.<\/p>\n
9 V\u00e4lj en l\u00e4mplig databasmotor<\/strong><\/h2>\nOm du utvecklar en applikation som l\u00e4ser data oftare \u00e4n att skriva (t.ex. en s\u00f6kmotor), v\u00e4lj MyISAM-lagringsmotor.<\/p>\n
Att v\u00e4lja fel lagringsmotor kommer att p\u00e5verka prestandan.<\/p>\n
10 Anv\u00e4nd EXISTS-klausulen d\u00e4r det beh\u00f6vs<\/strong><\/h2>\nF\u00f6r att kontrollera f\u00f6rekomsten av data, anv\u00e4nd EXISTS-satsen som \u00e4r snabbare i svarstid. Anv\u00e4nd till exempel:<\/p>\n
If EXISTS(SELECT * from Table WHERE col=\u2019some value\u2019)<\/code><\/p>\nAnv\u00e4nd inte :<\/p>\n
If (SELECT count(*) from Table WHERE col=\u2019some value\u2019)>0<\/code><\/p>\n11 F\u00d6RKLARA dina SELECT-fr\u00e5gor<\/strong><\/h2>\nOm du anv\u00e4nder nyckelordet EXPLAIN kan du f\u00e5 insikt om vad MySQL g\u00f6r f\u00f6r att utf\u00f6ra din fr\u00e5ga. Detta kan hj\u00e4lpa dig att uppt\u00e4cka problem med din fr\u00e5ga eller tabellstrukturer (t.ex. flaskhalsar).<\/p>\n
En EXPLAIN-fr\u00e5ga resulterar i att visa dig vilka index som anv\u00e4nds, hur tabellen skannas, sorteras, etc.<\/p>\n
Allt du beh\u00f6ver g\u00f6ra \u00e4r att l\u00e4gga till nyckelordet EXPLAIN framf\u00f6r en SELECT-fr\u00e5ga (helst en komplex med joins). Dessutom, om du anv\u00e4nder phpmyadmin f\u00f6r detta, kommer dina resultat att visas i en trevlig tabell.<\/p>\n
12 Anv\u00e4nd LIMIT 1 n\u00e4r du f\u00e5r en unik rad<\/strong><\/h2>\nIbland vet du i f\u00f6rv\u00e4g att du bara letar efter en rad n\u00e4r du fr\u00e5gar efter dina tabeller. Du kanske till exempel h\u00e4mtar en unik post, eller s\u00e5 kanske du bara kontrollerar att det finns ett antal poster som uppfyller din WHERE-sats.<\/p>\n
I s\u00e5dana fall vill du anv\u00e4nda MySQL limit-funktionen f\u00f6r att \u00f6ka prestandan. H\u00e4r \u00e4r en annan av MySQL b\u00e4sta praxis: l\u00e4gg bara till LIMIT 1 i din fr\u00e5ga. P\u00e5 s\u00e5 s\u00e4tt beh\u00f6ver inte databasmotorn g\u00e5 igenom hela tabellen eller indexet. Den kommer att sluta skanna n\u00e4r den bara hittar en post av det du letar efter.<\/p>\n
\/\/ do I have anyusersfrom Alabama?<\/code><\/p>\n\/\/ vad man INTE ska g\u00f6ra:
\n$r = mysql_query(”SELECT * FROM user WHERE state = ’Alabama’");
\nif (mysql_num_rows($r) > 0) {
\n\/\/ \u2026
\n}<\/p>\n
\/\/ mycket b\u00e4ttre:
\n$r = mysql_query(”SELECT 1 FROM user WHERE state = ’Alabama’ LIMIT 1");
\nif (mysql_num_rows($r) > 0) {
\n\/\/ \u2026
\n}<\/p>\n
13 Indexera och anv\u00e4nd samma kolumntyper f\u00f6r kopplingar<\/strong><\/h2>\nEtt annat viktigt tips om MySQL b\u00e4sta praxis \u2013 om din applikation har m\u00e5nga JOIN-fr\u00e5gor, se till att kolumnerna du g\u00e5r med i \u00e4r indexerade i b\u00e5da tabellerna. Detta p\u00e5verkar den interna optimeringen av join-operationen av MySQL.<\/p>\n
Dessutom m\u00e5ste de sammanfogade kolumnerna vara av samma typ. Om du till exempel kopplar en DECIMAL-kolumn till en INT-kolumn fr\u00e5n en annan tabell, kommer MySQL inte att kunna anv\u00e4nda n\u00e5got av indexen. \u00c4ven teckenkodningarna m\u00e5ste vara av samma typ f\u00f6r kolumner av str\u00e4ngtyp.<\/p>\n
\/\/ looking for companies in my state $r = mysql_query(\"SELECT company_name FROM users LEFT JOIN companies ON (users.state = companies.state) WHERE users.id = $user_id\");<\/code><\/p>\n\/\/ b\u00e5da tillst\u00e5ndskolumnerna b\u00f6r indexeras
\n\/\/ och de b\u00e5da ska vara av samma typ och teckenkodning
\n\/\/ eller s\u00e5 kan MySQL g\u00f6ra genoms\u00f6kningar av hela tabeller<\/p>\n
14 D\u00f6lj MySQL fr\u00e5n Internet<\/strong><\/h2>\nErfarna databasadministrat\u00f6rer och s\u00e4kerhetspersonal vet det \u2013 v\u00e4rd aldrig databasen under webbserverns rot.<\/p>\n
F\u00f6r webbaktiverade applikationer b\u00f6r MySQL d\u00f6ljas bakom en brandv\u00e4gg. Kommunikation b\u00f6r endast aktiveras mellan applikationsservrar och dina webbservrar.<\/p>\n
Ett annat alternativ \u00e4r att anv\u00e4nda MySQL skip-n\u00e4tverk. N\u00e4r det \u00e4r aktiverat, lyssnar MySQL endast efter lokala socket-anslutningar och ignorerar alla TCP-portar.<\/p>\n
15 Anv\u00e4nd de minsta m\u00f6jliga datatyperna<\/strong><\/h2>\n<\/a><\/p>\nL\u00e5t mig ber\u00e4tta en historia. N\u00e4r jag gick p\u00e5 college var filosofin att "minnet \u00e4r knappt". Det var de dagar med 256 MB h\u00e5rddiskar. Nuf\u00f6rtiden verkar ingen bry sig ett dugg om minne eller h\u00e5rddiskutrymme. Den nya filosofin \u00e4r att "minnet \u00e4r billigt". Det kan vara sant i dollartermer, men att l\u00e4sa stora datatyper tar fortfarande l\u00e4ngre tid \u00e4n att l\u00e4sa mindre. Stora datatyper kr\u00e4ver att fler skivsektorer kan l\u00e4sas in i minnet.<\/p>\n
Moralen \u00e4r att ignorera frestelsen att omedelbart hoppa till den st\u00f6rsta datatypen n\u00e4r du designar dina tabeller. T\u00e4nk p\u00e5 att anv\u00e4nda en int ist\u00e4llet f\u00f6r en bigint.<\/p>\n
Undvik ocks\u00e5 largechar (255) textf\u00e4lt n\u00e4r en varchar eller mindre char r\u00e4cker.<\/p>\n
Om du anv\u00e4nder r\u00e4tt datatyp kommer fler poster att f\u00e5 plats i minnet eller indexnyckelblocket. Detta leder till f\u00e4rre l\u00e4sningar och snabbare prestanda.<\/p>\n
16 Utnyttja query caching<\/strong><\/h2>\nCachning av fr\u00e5gor \u00e4r en av de mest effektiva metoderna f\u00f6r att f\u00f6rb\u00e4ttra prestandan. De flesta MySQL-servrar har det aktiverat som standard.<\/p>\n
Fr\u00e5gecachen lagrar texten i en SELECT-sats tillsammans med motsvarande resultatupps\u00e4ttning. Om servern senare f\u00e5r en identisk sats kommer den att h\u00e4mta resultaten fr\u00e5n fr\u00e5gecachen ist\u00e4llet f\u00f6r att analysera och k\u00f6ra satsen igen. Fr\u00e5gecachen delas mellan sessioner, s\u00e5 en resultatupps\u00e4ttning som genereras av en klient kan skickas som svar p\u00e5 samma fr\u00e5ga fr\u00e5n en annan klient.<\/p>\n
Men hur bra det \u00e4n \u00e4r har query caching sina begr\u00e4nsningar. Ta f\u00f6ljande uttalande:<\/p>\n
Problemet h\u00e4r \u00e4r att fr\u00e5gor inneh\u00e5ller vissa icke-deterministiska funktioner, som NOW() och RAND(). MySQL kan inte ber\u00e4kna s\u00e5dana funktioner i f\u00f6rv\u00e4g, s\u00e5 det slutar med att de inte cachelagras.<\/p>\n
Lyckligtvis finns det en enkel l\u00f6sning p\u00e5 det: du kan lagra funktionsresultaten i en variabel.<\/p>\n
17 Redigera inte dumpfiler<\/strong><\/h2>\nDumpfiler \u00e4r mycket vilseledande och kan orsaka korruption. Varf\u00f6r? Om du n\u00e5gonsin har sett dumpfilerna skapade av mysqldump, kommer du att h\u00e5lla med om att de ser ut som vanliga, ofarliga textfiler. Det \u00e4r d\u00e4rf\u00f6r de flesta redigerar dem i en vanlig textredigerare, vilket g\u00f6r att korruptioner uppst\u00e5r.<\/p>\n
Om du n\u00e5gonsin har provat att redigera dumpfiler l\u00e4rde du dig snabbt att de \u00e4r allt annat \u00e4n en textfil. S\u00e5 det enda garanterade s\u00e4ttet att undvika problem \u00e4r att l\u00e4mna dumpfilerna ifred.<\/p>\n
18 Anv\u00e4nd MyISAM-blockstorleksinst\u00e4llningen<\/strong><\/h2>\n
N\u00e4r du anv\u00e4nder datatypen DATETIME eller DATE ska du alltid anv\u00e4nda datumformatet \u00c5\u00c5\u00c5\u00c5-MM-DD eller ISO-datumformatet som passar din SQL Engine. Regionala format som DD-MM-\u00c5\u00c5\u00c5\u00c5 eller MM-DD-\u00c5\u00c5\u00c5\u00c5 kommer inte att lagras korrekt.<\/p>\n
5 Index nyckelkolumner<\/strong><\/h2>\nDet \u00e4r \u00f6nskv\u00e4rt att fr\u00e5gan returnerar resultatet snabbt, s\u00e5 se till att indexera kolumnerna som anv\u00e4nds i JOIN-satser.<\/p>\n
Om du anv\u00e4nder UPDATE-satsen som involverar mer \u00e4n en tabell, se till att indexera alla kolumner som anv\u00e4nds f\u00f6r att sammanfoga tabellerna.<\/p>\n
6 Anv\u00e4nd inte funktioner \u00f6ver indexerade kolumner…<\/strong><\/h2>\n\u2026 f\u00f6r d\u00e5 tappar indexet sitt syfte.<\/p>\n
Anta till exempel att du vill f\u00e5 data d\u00e4r de tv\u00e5 f\u00f6rsta tecknen i kundkoden \u00e4r AK. Skriva:<\/p>\n
SELECT columns FROM table WHERE customer_code like 'AK%'<\/code><\/p>\noch skriv inte<\/p>\n
SELECT columns FROM table WHERE left (customer_code,2)='AK\u2019<\/code><\/p>\nVarf\u00f6r? Det f\u00f6rsta exemplet kommer att anv\u00e4nda indexet, vilket kommer att resultera i en snabbare svarstid.<\/p>\n
7 Anv\u00e4nd SQL SELECT * endast om det beh\u00f6vs<\/strong><\/h2>\nF\u00f6lj listan \u00f6ver MySQL b\u00e4sta praxis, anv\u00e4nd inte bara blint SELECT * i koden. Om tabellen har m\u00e5nga kolumner kommer alla att returneras. Detta kommer att sakta ner svarstiden, s\u00e4rskilt om du skickar resultatet till en front-end-applikation.<\/p>\n
Skriv i st\u00e4llet uttryckligen de kolumnnamn som faktiskt beh\u00f6vs.<\/p>\n
Notera: kom ih\u00e5g att alla SELECT-satser kr\u00e4ver en WHERE-sats.<\/p>\n
8 Anv\u00e4nd endast ORDER BY-klausul om det beh\u00f6vs<\/strong><\/h2>\nOm du vill visa resultatet i front-end-applikationen, l\u00e5t den BEST\u00c4LLA resultatupps\u00e4ttningen. Om du g\u00f6r detta i SQL kan svarstiden bli l\u00e5ngsammare i fleranv\u00e4ndarmilj\u00f6n.<\/p>\n
9 V\u00e4lj en l\u00e4mplig databasmotor<\/strong><\/h2>\nOm du utvecklar en applikation som l\u00e4ser data oftare \u00e4n att skriva (t.ex. en s\u00f6kmotor), v\u00e4lj MyISAM-lagringsmotor.<\/p>\n
Att v\u00e4lja fel lagringsmotor kommer att p\u00e5verka prestandan.<\/p>\n
10 Anv\u00e4nd EXISTS-klausulen d\u00e4r det beh\u00f6vs<\/strong><\/h2>\nF\u00f6r att kontrollera f\u00f6rekomsten av data, anv\u00e4nd EXISTS-satsen som \u00e4r snabbare i svarstid. Anv\u00e4nd till exempel:<\/p>\n
If EXISTS(SELECT * from Table WHERE col=\u2019some value\u2019)<\/code><\/p>\nAnv\u00e4nd inte :<\/p>\n
If (SELECT count(*) from Table WHERE col=\u2019some value\u2019)>0<\/code><\/p>\n11 F\u00d6RKLARA dina SELECT-fr\u00e5gor<\/strong><\/h2>\nOm du anv\u00e4nder nyckelordet EXPLAIN kan du f\u00e5 insikt om vad MySQL g\u00f6r f\u00f6r att utf\u00f6ra din fr\u00e5ga. Detta kan hj\u00e4lpa dig att uppt\u00e4cka problem med din fr\u00e5ga eller tabellstrukturer (t.ex. flaskhalsar).<\/p>\n
En EXPLAIN-fr\u00e5ga resulterar i att visa dig vilka index som anv\u00e4nds, hur tabellen skannas, sorteras, etc.<\/p>\n
Allt du beh\u00f6ver g\u00f6ra \u00e4r att l\u00e4gga till nyckelordet EXPLAIN framf\u00f6r en SELECT-fr\u00e5ga (helst en komplex med joins). Dessutom, om du anv\u00e4nder phpmyadmin f\u00f6r detta, kommer dina resultat att visas i en trevlig tabell.<\/p>\n
12 Anv\u00e4nd LIMIT 1 n\u00e4r du f\u00e5r en unik rad<\/strong><\/h2>\nIbland vet du i f\u00f6rv\u00e4g att du bara letar efter en rad n\u00e4r du fr\u00e5gar efter dina tabeller. Du kanske till exempel h\u00e4mtar en unik post, eller s\u00e5 kanske du bara kontrollerar att det finns ett antal poster som uppfyller din WHERE-sats.<\/p>\n
I s\u00e5dana fall vill du anv\u00e4nda MySQL limit-funktionen f\u00f6r att \u00f6ka prestandan. H\u00e4r \u00e4r en annan av MySQL b\u00e4sta praxis: l\u00e4gg bara till LIMIT 1 i din fr\u00e5ga. P\u00e5 s\u00e5 s\u00e4tt beh\u00f6ver inte databasmotorn g\u00e5 igenom hela tabellen eller indexet. Den kommer att sluta skanna n\u00e4r den bara hittar en post av det du letar efter.<\/p>\n
\/\/ do I have anyusersfrom Alabama?<\/code><\/p>\n\/\/ vad man INTE ska g\u00f6ra:
\n$r = mysql_query(”SELECT * FROM user WHERE state = ’Alabama’");
\nif (mysql_num_rows($r) > 0) {
\n\/\/ \u2026
\n}<\/p>\n
\/\/ mycket b\u00e4ttre:
\n$r = mysql_query(”SELECT 1 FROM user WHERE state = ’Alabama’ LIMIT 1");
\nif (mysql_num_rows($r) > 0) {
\n\/\/ \u2026
\n}<\/p>\n
13 Indexera och anv\u00e4nd samma kolumntyper f\u00f6r kopplingar<\/strong><\/h2>\nEtt annat viktigt tips om MySQL b\u00e4sta praxis \u2013 om din applikation har m\u00e5nga JOIN-fr\u00e5gor, se till att kolumnerna du g\u00e5r med i \u00e4r indexerade i b\u00e5da tabellerna. Detta p\u00e5verkar den interna optimeringen av join-operationen av MySQL.<\/p>\n
Dessutom m\u00e5ste de sammanfogade kolumnerna vara av samma typ. Om du till exempel kopplar en DECIMAL-kolumn till en INT-kolumn fr\u00e5n en annan tabell, kommer MySQL inte att kunna anv\u00e4nda n\u00e5got av indexen. \u00c4ven teckenkodningarna m\u00e5ste vara av samma typ f\u00f6r kolumner av str\u00e4ngtyp.<\/p>\n
\/\/ looking for companies in my state $r = mysql_query(\"SELECT company_name FROM users LEFT JOIN companies ON (users.state = companies.state) WHERE users.id = $user_id\");<\/code><\/p>\n\/\/ b\u00e5da tillst\u00e5ndskolumnerna b\u00f6r indexeras
\n\/\/ och de b\u00e5da ska vara av samma typ och teckenkodning
\n\/\/ eller s\u00e5 kan MySQL g\u00f6ra genoms\u00f6kningar av hela tabeller<\/p>\n
14 D\u00f6lj MySQL fr\u00e5n Internet<\/strong><\/h2>\nErfarna databasadministrat\u00f6rer och s\u00e4kerhetspersonal vet det \u2013 v\u00e4rd aldrig databasen under webbserverns rot.<\/p>\n
F\u00f6r webbaktiverade applikationer b\u00f6r MySQL d\u00f6ljas bakom en brandv\u00e4gg. Kommunikation b\u00f6r endast aktiveras mellan applikationsservrar och dina webbservrar.<\/p>\n
Ett annat alternativ \u00e4r att anv\u00e4nda MySQL skip-n\u00e4tverk. N\u00e4r det \u00e4r aktiverat, lyssnar MySQL endast efter lokala socket-anslutningar och ignorerar alla TCP-portar.<\/p>\n
15 Anv\u00e4nd de minsta m\u00f6jliga datatyperna<\/strong><\/h2>\n<\/a><\/p>\nL\u00e5t mig ber\u00e4tta en historia. N\u00e4r jag gick p\u00e5 college var filosofin att "minnet \u00e4r knappt". Det var de dagar med 256 MB h\u00e5rddiskar. Nuf\u00f6rtiden verkar ingen bry sig ett dugg om minne eller h\u00e5rddiskutrymme. Den nya filosofin \u00e4r att "minnet \u00e4r billigt". Det kan vara sant i dollartermer, men att l\u00e4sa stora datatyper tar fortfarande l\u00e4ngre tid \u00e4n att l\u00e4sa mindre. Stora datatyper kr\u00e4ver att fler skivsektorer kan l\u00e4sas in i minnet.<\/p>\n
Moralen \u00e4r att ignorera frestelsen att omedelbart hoppa till den st\u00f6rsta datatypen n\u00e4r du designar dina tabeller. T\u00e4nk p\u00e5 att anv\u00e4nda en int ist\u00e4llet f\u00f6r en bigint.<\/p>\n
Undvik ocks\u00e5 largechar (255) textf\u00e4lt n\u00e4r en varchar eller mindre char r\u00e4cker.<\/p>\n
Om du anv\u00e4nder r\u00e4tt datatyp kommer fler poster att f\u00e5 plats i minnet eller indexnyckelblocket. Detta leder till f\u00e4rre l\u00e4sningar och snabbare prestanda.<\/p>\n
16 Utnyttja query caching<\/strong><\/h2>\nCachning av fr\u00e5gor \u00e4r en av de mest effektiva metoderna f\u00f6r att f\u00f6rb\u00e4ttra prestandan. De flesta MySQL-servrar har det aktiverat som standard.<\/p>\n
Fr\u00e5gecachen lagrar texten i en SELECT-sats tillsammans med motsvarande resultatupps\u00e4ttning. Om servern senare f\u00e5r en identisk sats kommer den att h\u00e4mta resultaten fr\u00e5n fr\u00e5gecachen ist\u00e4llet f\u00f6r att analysera och k\u00f6ra satsen igen. Fr\u00e5gecachen delas mellan sessioner, s\u00e5 en resultatupps\u00e4ttning som genereras av en klient kan skickas som svar p\u00e5 samma fr\u00e5ga fr\u00e5n en annan klient.<\/p>\n
Men hur bra det \u00e4n \u00e4r har query caching sina begr\u00e4nsningar. Ta f\u00f6ljande uttalande:<\/p>\n
Problemet h\u00e4r \u00e4r att fr\u00e5gor inneh\u00e5ller vissa icke-deterministiska funktioner, som NOW() och RAND(). MySQL kan inte ber\u00e4kna s\u00e5dana funktioner i f\u00f6rv\u00e4g, s\u00e5 det slutar med att de inte cachelagras.<\/p>\n
Lyckligtvis finns det en enkel l\u00f6sning p\u00e5 det: du kan lagra funktionsresultaten i en variabel.<\/p>\n
17 Redigera inte dumpfiler<\/strong><\/h2>\nDumpfiler \u00e4r mycket vilseledande och kan orsaka korruption. Varf\u00f6r? Om du n\u00e5gonsin har sett dumpfilerna skapade av mysqldump, kommer du att h\u00e5lla med om att de ser ut som vanliga, ofarliga textfiler. Det \u00e4r d\u00e4rf\u00f6r de flesta redigerar dem i en vanlig textredigerare, vilket g\u00f6r att korruptioner uppst\u00e5r.<\/p>\n
Om du n\u00e5gonsin har provat att redigera dumpfiler l\u00e4rde du dig snabbt att de \u00e4r allt annat \u00e4n en textfil. S\u00e5 det enda garanterade s\u00e4ttet att undvika problem \u00e4r att l\u00e4mna dumpfilerna ifred.<\/p>\n
18 Anv\u00e4nd MyISAM-blockstorleksinst\u00e4llningen<\/strong><\/h2>\n
\u2026 f\u00f6r d\u00e5 tappar indexet sitt syfte.<\/p>\n
Anta till exempel att du vill f\u00e5 data d\u00e4r de tv\u00e5 f\u00f6rsta tecknen i kundkoden \u00e4r AK. Skriva:<\/p>\n
och skriv inte<\/p>\n Varf\u00f6r? Det f\u00f6rsta exemplet kommer att anv\u00e4nda indexet, vilket kommer att resultera i en snabbare svarstid.<\/p>\n F\u00f6lj listan \u00f6ver MySQL b\u00e4sta praxis, anv\u00e4nd inte bara blint SELECT * i koden. Om tabellen har m\u00e5nga kolumner kommer alla att returneras. Detta kommer att sakta ner svarstiden, s\u00e4rskilt om du skickar resultatet till en front-end-applikation.<\/p>\n Skriv i st\u00e4llet uttryckligen de kolumnnamn som faktiskt beh\u00f6vs.<\/p>\n Notera: kom ih\u00e5g att alla SELECT-satser kr\u00e4ver en WHERE-sats.<\/p>\n Om du vill visa resultatet i front-end-applikationen, l\u00e5t den BEST\u00c4LLA resultatupps\u00e4ttningen. Om du g\u00f6r detta i SQL kan svarstiden bli l\u00e5ngsammare i fleranv\u00e4ndarmilj\u00f6n.<\/p>\n Om du utvecklar en applikation som l\u00e4ser data oftare \u00e4n att skriva (t.ex. en s\u00f6kmotor), v\u00e4lj MyISAM-lagringsmotor.<\/p>\n Att v\u00e4lja fel lagringsmotor kommer att p\u00e5verka prestandan.<\/p>\n F\u00f6r att kontrollera f\u00f6rekomsten av data, anv\u00e4nd EXISTS-satsen som \u00e4r snabbare i svarstid. Anv\u00e4nd till exempel:<\/p>\n Anv\u00e4nd inte :<\/p>\n Om du anv\u00e4nder nyckelordet EXPLAIN kan du f\u00e5 insikt om vad MySQL g\u00f6r f\u00f6r att utf\u00f6ra din fr\u00e5ga. Detta kan hj\u00e4lpa dig att uppt\u00e4cka problem med din fr\u00e5ga eller tabellstrukturer (t.ex. flaskhalsar).<\/p>\n En EXPLAIN-fr\u00e5ga resulterar i att visa dig vilka index som anv\u00e4nds, hur tabellen skannas, sorteras, etc.<\/p>\n Allt du beh\u00f6ver g\u00f6ra \u00e4r att l\u00e4gga till nyckelordet EXPLAIN framf\u00f6r en SELECT-fr\u00e5ga (helst en komplex med joins). Dessutom, om du anv\u00e4nder phpmyadmin f\u00f6r detta, kommer dina resultat att visas i en trevlig tabell.<\/p>\n Ibland vet du i f\u00f6rv\u00e4g att du bara letar efter en rad n\u00e4r du fr\u00e5gar efter dina tabeller. Du kanske till exempel h\u00e4mtar en unik post, eller s\u00e5 kanske du bara kontrollerar att det finns ett antal poster som uppfyller din WHERE-sats.<\/p>\n I s\u00e5dana fall vill du anv\u00e4nda MySQL limit-funktionen f\u00f6r att \u00f6ka prestandan. H\u00e4r \u00e4r en annan av MySQL b\u00e4sta praxis: l\u00e4gg bara till LIMIT 1 i din fr\u00e5ga. P\u00e5 s\u00e5 s\u00e4tt beh\u00f6ver inte databasmotorn g\u00e5 igenom hela tabellen eller indexet. Den kommer att sluta skanna n\u00e4r den bara hittar en post av det du letar efter.<\/p>\n \/\/ vad man INTE ska g\u00f6ra: \/\/ mycket b\u00e4ttre: Ett annat viktigt tips om MySQL b\u00e4sta praxis \u2013 om din applikation har m\u00e5nga JOIN-fr\u00e5gor, se till att kolumnerna du g\u00e5r med i \u00e4r indexerade i b\u00e5da tabellerna. Detta p\u00e5verkar den interna optimeringen av join-operationen av MySQL.<\/p>\n Dessutom m\u00e5ste de sammanfogade kolumnerna vara av samma typ. Om du till exempel kopplar en DECIMAL-kolumn till en INT-kolumn fr\u00e5n en annan tabell, kommer MySQL inte att kunna anv\u00e4nda n\u00e5got av indexen. \u00c4ven teckenkodningarna m\u00e5ste vara av samma typ f\u00f6r kolumner av str\u00e4ngtyp.<\/p>\n \/\/ b\u00e5da tillst\u00e5ndskolumnerna b\u00f6r indexeras Erfarna databasadministrat\u00f6rer och s\u00e4kerhetspersonal vet det \u2013 v\u00e4rd aldrig databasen under webbserverns rot.<\/p>\n F\u00f6r webbaktiverade applikationer b\u00f6r MySQL d\u00f6ljas bakom en brandv\u00e4gg. Kommunikation b\u00f6r endast aktiveras mellan applikationsservrar och dina webbservrar.<\/p>\n Ett annat alternativ \u00e4r att anv\u00e4nda MySQL skip-n\u00e4tverk. N\u00e4r det \u00e4r aktiverat, lyssnar MySQL endast efter lokala socket-anslutningar och ignorerar alla TCP-portar.<\/p>\n L\u00e5t mig ber\u00e4tta en historia. N\u00e4r jag gick p\u00e5 college var filosofin att "minnet \u00e4r knappt". Det var de dagar med 256 MB h\u00e5rddiskar. Nuf\u00f6rtiden verkar ingen bry sig ett dugg om minne eller h\u00e5rddiskutrymme. Den nya filosofin \u00e4r att "minnet \u00e4r billigt". Det kan vara sant i dollartermer, men att l\u00e4sa stora datatyper tar fortfarande l\u00e4ngre tid \u00e4n att l\u00e4sa mindre. Stora datatyper kr\u00e4ver att fler skivsektorer kan l\u00e4sas in i minnet.<\/p>\n Moralen \u00e4r att ignorera frestelsen att omedelbart hoppa till den st\u00f6rsta datatypen n\u00e4r du designar dina tabeller. T\u00e4nk p\u00e5 att anv\u00e4nda en int ist\u00e4llet f\u00f6r en bigint.<\/p>\n Undvik ocks\u00e5 largechar (255) textf\u00e4lt n\u00e4r en varchar eller mindre char r\u00e4cker.<\/p>\n Om du anv\u00e4nder r\u00e4tt datatyp kommer fler poster att f\u00e5 plats i minnet eller indexnyckelblocket. Detta leder till f\u00e4rre l\u00e4sningar och snabbare prestanda.<\/p>\n Cachning av fr\u00e5gor \u00e4r en av de mest effektiva metoderna f\u00f6r att f\u00f6rb\u00e4ttra prestandan. De flesta MySQL-servrar har det aktiverat som standard.<\/p>\n Fr\u00e5gecachen lagrar texten i en SELECT-sats tillsammans med motsvarande resultatupps\u00e4ttning. Om servern senare f\u00e5r en identisk sats kommer den att h\u00e4mta resultaten fr\u00e5n fr\u00e5gecachen ist\u00e4llet f\u00f6r att analysera och k\u00f6ra satsen igen. Fr\u00e5gecachen delas mellan sessioner, s\u00e5 en resultatupps\u00e4ttning som genereras av en klient kan skickas som svar p\u00e5 samma fr\u00e5ga fr\u00e5n en annan klient.<\/p>\n Men hur bra det \u00e4n \u00e4r har query caching sina begr\u00e4nsningar. Ta f\u00f6ljande uttalande:<\/p>\n Problemet h\u00e4r \u00e4r att fr\u00e5gor inneh\u00e5ller vissa icke-deterministiska funktioner, som NOW() och RAND(). MySQL kan inte ber\u00e4kna s\u00e5dana funktioner i f\u00f6rv\u00e4g, s\u00e5 det slutar med att de inte cachelagras.<\/p>\n Lyckligtvis finns det en enkel l\u00f6sning p\u00e5 det: du kan lagra funktionsresultaten i en variabel.<\/p>\n Dumpfiler \u00e4r mycket vilseledande och kan orsaka korruption. Varf\u00f6r? Om du n\u00e5gonsin har sett dumpfilerna skapade av mysqldump, kommer du att h\u00e5lla med om att de ser ut som vanliga, ofarliga textfiler. Det \u00e4r d\u00e4rf\u00f6r de flesta redigerar dem i en vanlig textredigerare, vilket g\u00f6r att korruptioner uppst\u00e5r.<\/p>\n Om du n\u00e5gonsin har provat att redigera dumpfiler l\u00e4rde du dig snabbt att de \u00e4r allt annat \u00e4n en textfil. S\u00e5 det enda garanterade s\u00e4ttet att undvika problem \u00e4r att l\u00e4mna dumpfilerna ifred.<\/p>\nSELECT columns FROM table WHERE customer_code like 'AK%'<\/code><\/p>\nSELECT columns FROM table WHERE left (customer_code,2)='AK\u2019<\/code><\/p>\n7 Anv\u00e4nd SQL SELECT * endast om det beh\u00f6vs<\/strong><\/h2>\n
8 Anv\u00e4nd endast ORDER BY-klausul om det beh\u00f6vs<\/strong><\/h2>\n
9 V\u00e4lj en l\u00e4mplig databasmotor<\/strong><\/h2>\n
10 Anv\u00e4nd EXISTS-klausulen d\u00e4r det beh\u00f6vs<\/strong><\/h2>\n
If EXISTS(SELECT * from Table WHERE col=\u2019some value\u2019)<\/code><\/p>\nIf (SELECT count(*) from Table WHERE col=\u2019some value\u2019)>0<\/code><\/p>\n11 F\u00d6RKLARA dina SELECT-fr\u00e5gor<\/strong><\/h2>\n
12 Anv\u00e4nd LIMIT 1 n\u00e4r du f\u00e5r en unik rad<\/strong><\/h2>\n
\/\/ do I have anyusersfrom Alabama?<\/code><\/p>\n
\n$r = mysql_query(”SELECT * FROM user WHERE state = ’Alabama’");
\nif (mysql_num_rows($r) > 0) {
\n\/\/ \u2026
\n}<\/p>\n
\n$r = mysql_query(”SELECT 1 FROM user WHERE state = ’Alabama’ LIMIT 1");
\nif (mysql_num_rows($r) > 0) {
\n\/\/ \u2026
\n}<\/p>\n13 Indexera och anv\u00e4nd samma kolumntyper f\u00f6r kopplingar<\/strong><\/h2>\n
\/\/ looking for companies in my state $r = mysql_query(\"SELECT company_name FROM users LEFT JOIN companies ON (users.state = companies.state) WHERE users.id = $user_id\");<\/code><\/p>\n
\n\/\/ och de b\u00e5da ska vara av samma typ och teckenkodning
\n\/\/ eller s\u00e5 kan MySQL g\u00f6ra genoms\u00f6kningar av hela tabeller<\/p>\n14 D\u00f6lj MySQL fr\u00e5n Internet<\/strong><\/h2>\n
15 Anv\u00e4nd de minsta m\u00f6jliga datatyperna<\/strong><\/h2>\n
<\/a><\/p>\n16 Utnyttja query caching<\/strong><\/h2>\n
17 Redigera inte dumpfiler<\/strong><\/h2>\n
18 Anv\u00e4nd MyISAM-blockstorleksinst\u00e4llningen<\/strong><\/h2>\n
![\"22](\"https:\/\/wordpress.mediadoma.com\/wp-content\/uploads\/2022\/01\/post-206970-61e8d4b8518b8.jpg\")
<\/a><\/p>\n![\"22](\"https:\/\/wordpress.mediadoma.com\/wp-content\/uploads\/2022\/01\/post-206970-61e8d4b96bb8a.jpg\")
<\/a><\/p>\n