Veritabanlarının kullanımı, bir kişinin hayatını büyük ölçüde kolaylaştırır, verilerle çalışır, gerekli bilgileri veritabanından hızlı bir şekilde almanıza veya ona yazmanıza olanak tanır. Bununla birlikte, verilerle çalışmak uygun bir yaklaşım gerektirir, programcı veritabanlarıyla etkileşimin bazı yönlerini hesaba katmalıdır. Özellikle MySQL'den bahsediyoruz. Şimdi, MySQL veritabanlarıyla iletişimi optimize etmeye yönelik ipuçlarına bir göz atalım.
MySQL sorgularını önbelleğe alınabilir hale getirin
MySQL sunucusundaki yerleşik sorgu önbelleğe alma mekanizması, performansı önemli ölçüde artırabilir. Çoğu MySQL veritabanı sunucusu bir önbelleğe alma mekanizması içerir. Kısa bir süre içinde veritabanına yapılan birçok özdeş sorgu, performansta önemli kayıplara neden olabilir, önbellekleme mekanizması bu tür sorguları önbelleğe alabilir ve verileri zaten önbellekten verir. MySQL'in önbelleğe alamadığı sorgular vardır ve bu sorguları biraz farklı yapmanız önerilir.
// MySQL bu sorguyu önbelleğe alamıyor $ res = mysql_query ("SEÇ kullanıcı adı WHERE signup_date> = CURDATE ()"); // farklı şekilde yapabilirsiniz $ bugün = tarih ("Y-m-d"); $ res = mysql_query ("NEREDE kayıt_tarihi kullanıcısından kullanıcı adını SEÇ> =" $ bugün "");
Gerçek şu ki, ilk istekte CURDATE () işlevi kullanıldı, işleminin özelliği, sorgu sonuçlarının önbelleğe alınmasına izin vermiyor. Tarih değeri sorgu dizesine önceden yazılabilir, bu, sorguda CURDATE () işlevinin kullanımını ortadan kaldıracaktır.
Benzer şekilde, MySQL sunucusunun kendisi tarafından önbelleğe alınmayan başka işlevler de vardır; bunlar arasında RAND (), ŞİMDİ () ve sonucu deterministik olmayan diğer işlevler vardır.
EXPLAIN sözdizimini kullanarak sorgunuzun nasıl yürütüldüğünü görüntüleyin
EXPLAIN sözdizimini kullanarak MySQL'in sorgunuzu nasıl yürüttüğünü görebilirsiniz. Kullanımı, sorgu performansındaki ve tablo yapısındaki zayıflıkları belirlemeye yardımcı olabilir. Sorgu sonucunda EXPLAIN, hangi dizinlerin kullanıldığını, verilerin tablolardan nasıl getirildiğini, nasıl sıralandığını vb. gösteren verileri döndürür. Bunu yapmak için, SELECT sorgusunun başına EXPLAIN anahtar sözcüğünü eklemek yeterlidir, ardından verileri içeren bir tablo gösterilecektir.
Bir kayda ihtiyacınız olduğunda, LIMIT 1'i ayarlayın
Tablodan en az bir kaydın varlığını kontrol etmeniz gereken birçok durum vardır, bu durumda sorguya LIMIT 1 parametresini eklemeniz önerilir.Bu onu daha optimal hale getirecektir, çünkü veritabanı motoru, ilk kaydı bulduktan sonra, tüm verileri getirmek yerine veri almayı durduracaktır. Kaynaklardan tasarruf edersiniz.
// Shymkent kodu ile bir şehir talebi veritabanından $ res = mysql_query ("SELECT * FROM location WHERE city =" Shymkent ""); if (mysql_num_rows ($ res)> 0) () // sorguyu optimize etmek için LIMIT 1 ekleyin $ res = mysql_query ("SELECT * FROM location WHERE city =" Shymkent "LIMIT 1"); if (mysql_num_rows ($ res)> 0) ()
Aranan alanları indeksleyin
Özel bir durumda dizin, arama yaptığınız alanların dizini anlamına gelir, bu arama hızını artıracaktır. Bu arada, normal bir dizin, normal ifadeler biçimindeki koşullarla çalışamaz:
// şehir LIKE indeksi burada tetiklenecek 'shym%' // indeks hemen kullanılmayacak şehir LIKE '% shymkent%'
Normal ifadelere sahip koşullar için bir dizin oluşturmak için, kendi dizin sisteminizi kullanmalı veya düşünmelisiniz.
Tabloların birleştiği alanları indeksleyin
Birden çok tablo birleşimleri kullanıyorsanız, birleşmeye dahil olan alanların her iki tabloda da dizine eklenip eklenmediğini göz önünde bulundurmalısınız. Bu konu, MySQL'in tablo alanlarının birleşimlerini dahili olarak nasıl optimize edeceğini etkiler. Birleşim alanları aynı türde ve aynı kodlamada olmalıdır. Onlar. örneğin, bir alan DECIMAL türünde ve diğeri INT ise, MySQL dizini kullanamaz.
ORDER BY RAND () yerine bir alternatif bulun
Rastgele sıralamanın kullanımı gerçekten de oldukça uygundur ve birçok acemi programcı aynı fikirdedir. Ancak, tuzaklar var ve çok önemli, sorgularınızda benzer bir örnekleme yöntemini kullanarak bir performans darboğazı bırakıyorsunuz. Burada veri miktarı arttıkça size kendini hatırlatacak performans darboğazından kurtulmak için alternatif olarak ORDER BY RAND() kullanmak yerine ek koda başvurmanız önerilir.
SEÇ * yerine belirli alanları seçin
"*" - tüm alanların seçimi yerine seçim yaparken sorguda belirli zorunlu alanları belirtmek için tembel olmayın, gerçek şu ki tablodan ne kadar fazla veri okunursa, sorgunuz o kadar yavaş olur.
Tüm tablolar için bir kimlik alanı ekleyin
İyi performans gösteren her tablo, birincil anahtar (PRIMARY_KEY) ve AUTO_INCREMENT olan INT türünde bir kimlik alanına sahip olmalıdır. Ayrıca alan için UNSIGNED parametresi belirtilmelidir, bu da değerin her zaman pozitif olacağı anlamına gelir.
MySQL, birincil anahtarı kullanabilen dahili işlemlere sahiptir, bu, kümeler, paralellik vb. gibi karmaşık veritabanı yapılandırmaları için devreye girer.
Ayrıca, birden fazla tablonuz varsa ve birleştirilmiş bir sorgu çalıştırmak istiyorsanız, tablo kimlikleri kullanışlı olacaktır.
VARCHAR'a alternatif olarak ENUM
Bir tabloya belirli bir değerler kümesi içermesi gereken bir alan eklemek istediğinizi varsayalım. Geleneksel olarak, birçok programcı, alanlar için VARCHAR türünü ortaya çıkarır. Ancak, çok daha hızlı ve daha kompakt olan başka bir alan türü daha var. Bu türdeki değerler, TINYINT ile aynı şekilde saklanır, ancak bir dize türünde olduğu gibi görüntülenir.
NULL yerine NULL DEĞİL kullanın
NULL alanlar, bu NULL değerini işaretlemek gerektiğinden kayıtta daha fazla yer kaplar. MyISAM tabloları, NULL'lu alanlar, her alan en yakın bayta yuvarlanan 1 ekstra bit alacak şekilde saklanır. Bir alanda NULL kullanılması zorunlu değilse, NOT NULL kullanılması önerilir.
Hazır İfadeleri Kullan
$ res = "UPDATE ana bilgisayarları SET ip = INET_ATON (" ($ _ SERVER ["REMOTE_ADDR"]) ") NEREDE id = $ host_id";Statik tablolar kullanın
Statik bir tablo, tablodaki her alanın sabit bir boyutu olması dışında, veritabanındaki normal bir tablodur. Tabloda sabit olmayan uzunlukta sütunlar varsa, örneğin, şunlar olabilir: VARCHAR, TEXT, BLOB, statik olmaktan çıkar ve MySQL bunu biraz farklı şekilde ele alacaktır. Statik tablolar veya sabit boyutlu tablolar olarak da adlandırılabilirler, statik olmayanlardan daha hızlı çalışırlar. Bu tür tablolardan alınan kayıtlar daha hızlı taranacaktır, gerekli satırı seçmeniz gerekirse MySQL konumunu hızlı bir şekilde hesaplayacaktır. Alan sabit bir boyutta değilse, bu durumda arama indeks tarafından gerçekleştirilir. Statik tablolar kullanmanın başka avantajları da vardır, gerçek şu ki, bu tabloların önbelleğe alınması ve ayrıca bir veritabanı çökmesinden sonra kurtarılması daha kolaydır.
Dikey ayırma kullan
Dikey bölme - Bu, tablonun performansını artırmak için tablonun sütunlara bölünmesi anlamına gelir. Örneğin, tabloda çok nadir kullanılan alanlar varsa veya bunlar değişken uzunlukta alanlarsa, ayrı bir tabloya taşınabilirler, böylece tabloyu boşaltırsınız, böylece çalışma hızınızı arttırırsınız.
Ayrı Hacimli INSERT ve DELETE Sorguları
Bu tür çok sayıda sorgunun yürütülmesi, tablonun kilitlenmesine yol açabilir, bunun sonucunda uygulama bir bütün olarak düzgün çalışmaz. Web sunucusuna yapılan paralel istekler, ek tablo erişimi oluşturabilir. Bir tablo önceki bir istek tarafından engellenirse, sonraki istekler sıraya alınır ve sonuç olarak bu, site yavaşlaması ve hatta sunucu çökmesi şeklinde kendini gösterir.
Çok fazla istek yapmanız gerekiyorsa, her şeyi veritabanına atmak yerine bunları küçük gruplar halinde göndererek kontrol etmeye çalışın. Bu durumda, isteğiniz daha uzun sürebilir, ancak bunun diğer kullanıcılar üzerinde daha az etkisi olacaktır.
Örnek:
while (1) (mysql_query ("DELETE FROM günlükleri WHERE log_date<= "2015-07-20" LIMIT 1000"); if (mysql_affected_rows() == 0){ // записи удалены успешно break; } usleep(50000); // делаем небольшую паузу }
Küçük marjlar kullanmaya çalışın
Bildiğiniz gibi, veritabanı verileri sabit diskte saklanır, bu genellikle bir web uygulamasının zayıf noktalarından biri olabilir. Mesele şu ki, küçük boyutlu kayıtlar daha çok tercih edilir, çünkü bunları kullanmak, sabit sürücü ile çalışmayı azaltır. Belirli bir tablonun birkaç satır depolayacağından eminseniz, mantıklı çözüm, mümkün olan en düşük değerlere sahip alan türlerini kullanmak olacaktır. Örneğin, ana anahtar INT türündeyse ve tabloda yalnızca az miktarda veri depolayacaksanız, bunu MEDIUMINT, SMALLINT veya hatta TINYINT türünde yapmak daha iyidir.
İhtiyaçlarınız için tablo türlerini seçin
Günümüzde yaygın olarak bilinen iki tablo türü, her birinin avantajları ve dezavantajları olan MyISAM ve InnoDB'dir. Örneğin, MyISAM, büyük hacimli tablolardaki verileri okumakta iyidir, ancak yazarken daha yavaştır. SELECT COUNT (*) gibi sorgularda da iyi performans gösterir.
InnoDB'nin depolama motoru MyISAM'den daha karmaşıktır, ancak satır kilitlerini destekler, bu da ölçeklendirme söz konusu olduğunda iyi bir şeydir. Bu nedenle birinin diğerinden daha iyi olduğunu söylemek mümkün değil ve doğru değil, ihtiyacınıza göre türü seçmeniz gerekiyor.
Yazardan: bir arkadaşım arabasını optimize etmeye karar verdi. Önce bir tekerleği çıkardım, bu yüzden çatıyı kestim, sonra motoru ... Genelde, şimdi yürüyerek yürüyor. Bunların hepsi yanlış yaklaşımın sonuçları! Bu nedenle, DBMS'nizin çalışmaya devam etmesi için MySQL'in doğru şekilde optimize edilmesi gerekir.
Ne zaman optimize edilmeli ve neden?
Bir kez daha sunucu ayarlarına girip parametre değerlerini değiştirmeye değmez (özellikle nasıl sonuçlanacağını bilmiyorsanız). Bu konuyu web kaynaklarının performansını iyileştirmenin "çan kulesinden" düşünürsek, o kadar kapsamlıdır ki, 7 ciltte tam bir bilimsel yayına ayrılması gerekir.
Ama belli ki benim böyle bir yazar sabrına sahip değilim, sizin de bir okur sabrınız yok. Bunu daha kolay yapacağız ve MySQL sunucusunu ve bileşenlerini optimize etme çalılıklarına biraz daha derine inmeye çalışacağız. DBMS'nin tüm parametrelerinin optimum ayarı ile çeşitli hedeflere ulaşılabilir:
Sorgu yürütme hızını artırın.
Genel sunucu performansını iyileştirin.
Kaynak sayfalarının yüklenmesi için bekleme süresini azaltın.
Barındırma sunucusu kapasitelerinin tüketimini azaltın.
Kullanılan disk alanı miktarını azaltın.
Tüm optimizasyon konusunu birkaç noktaya bölmeye çalışacağız, böylece "pot"u neyin kaynattığını az çok netleştireceğiz.
Neden bir sunucu kurmak
MySQL'de performans optimizasyonu sunucu ile başlamalıdır. Her şeyden önce, çalışmalarını hızlandırmalı ve isteklerin işlem süresini azaltmalısınız. Tüm bu hedefler için tek noktadan alışveriş, önbelleğe almayı etkinleştirmektir. "Ne olduğunu" bilmiyor musun? Şimdi her şeyi açıklayacağım.
Sunucu örneğinizde önbelleğe alma etkinse, MySQL kullanıcı tarafından girilen sorguyu otomatik olarak "hatırlayacaktır". Ve bir sonraki tekrarında bu sorgu sonucu (seçim için) işlenmez, sistem belleğinden alınır. Bu şekilde sunucunun yanıt vermek için zamandan "kazandığı" ve bunun sonucunda sitenin yanıt verme hızının arttığı ortaya çıktı. Bu aynı zamanda genel indirme hızı için de geçerlidir.
MySQL'de sorgu optimizasyonu, bu DBMS ve PHP temelinde çalışan bu motorlara ve CMS'ye uygulanabilir. Aynı zamanda, programlama dilinde yazılan kod, dinamik bir web sayfası oluşturmak için, bazı yapısal parçalarını ve içeriğini (kayıtlar, arşivler ve diğer sınıflandırmalar) veritabanından talep eder.
MySQL'de etkin önbelleğe alma sayesinde, DBMS sunucusuna yapılan sorguların yürütülmesi çok daha hızlıdır. Bu nedenle, tüm kaynağın bir bütün olarak yükleme hızı artar. Bu da hem kullanıcı deneyimine hem de sitenin arama sonuçlarındaki konumuna olumlu etki yapıyor.
Önbelleğe almayı açın ve yapılandırın
Ama "sıkıcı" teoriden ilginç pratiğe geri dönelim. Veritabanı sunucunuzdaki önbelleğe alma durumunu kontrol ederek MySQL veritabanını daha da optimize etmeye devam edeceğiz. Bunu yapmak için özel bir sorgu kullanarak tüm sistem değişkenlerinin değerlerini görüntüleyeceğiz:
Çok başka bir konu.
MySQL veritabanlarını optimize etmek için bize faydalı olacak, elde edilen değerlere küçük bir genel bakış yapalım:
have_query_cache - değer, sorgunun önbelleğe alınıp alınmadığını "AÇIK" olarak gösterir.
query_cache_type - Etkin önbellek türünü görüntüler. "ON" değerine ihtiyacımız var. Bu, tüm seçim türleri için önbelleğe almanın etkinleştirildiği anlamına gelir (SELECT komutu). SQL_NO_CACHE parametresinin kullanıldığı durumlar dışında (bu sorgu hakkında bilgi kaydetmeyi yasaklar).
Tüm ayarları doğru şekilde ayarladık.
İndeksler ve anahtarlar için önbelleği ölçüyoruz
Şimdi dizinler ve anahtarlar için ne kadar RAM ayrıldığını kontrol etmeniz gerekiyor. MySQL veritabanını optimize etmek için önemli olan bu parametrenin sunucunun kullanabileceği RAM miktarının %20-30'u kadar ayarlanması önerilir. Örneğin, DBMS örneği için 4 "hektar" ayrılmışsa, 32 "metre" koymaktan çekinmeyin. Ancak hepsi, belirli bir tabanın özelliklerine ve tabloların yapısına (türlerine) bağlıdır.
Parametre değerini ayarlamak için, Denver'da aşağıdaki yolda bulunan my.ini yapılandırma dosyasının içeriğini düzenlemeniz gerekir: F: \ Webserver \ usr \ local \ mysql-5.5
Dosyayı Not Defteri ile açın. Ardından, içinde key_buffer_size parametresini buluyoruz ve PC sisteminiz için en uygun boyutu ayarlıyoruz (RAM'in "hektarına" bağlı olarak). Bundan sonra, veritabanı sunucusunu yeniden başlatmanız gerekir.
DBMS birkaç ek alt sistem (alt düzey) kullanır ve bunların tüm ana ayarları da bu yapılandırma dosyasında belirtilir. Bu nedenle, MySQL InnoDB'de optimizasyon yapmanız gerekiyorsa, buraya hoş geldiniz. Bu konuyu sonraki materyallerimizden birinde daha ayrıntılı olarak inceleyeceğiz.
Endeks seviyelerinin ölçülmesi
Tablolarda dizinlerin kullanılması, girilen bir sorguya bir DBMS yanıtı oluşturma ve işleme hızını önemli ölçüde artırır. MySQL, her bir veritabanındaki indeks ve anahtar kullanım düzeyini sürekli olarak "ölçer". Bu değeri elde etmek için şu sorguyu kullanın:
"handler_read%" GİBİ DURUMU GÖSTER
"handler_read%" GİBİ DURUMU GÖSTER |
Ortaya çıkan sonuçta Handler_read_key satırındaki değerle ilgileniyoruz. Orada belirtilen sayı küçükse, bu veritabanında indekslerin neredeyse hiç kullanılmadığı anlamına gelir. Ve bu kötü (bizimki gibi).
Veritabanıyla çalışmak, çoğu web uygulamasının performansındaki en zayıf noktadır. Ve bununla ilgilenmesi gereken sadece DBA'lar değil. Programcılar doğru tablo yapısını seçmeli, optimize edilmiş sorgular yazmalı ve iyi kod yazmalıdır. Aşağıdakiler, programcılar için MySQL çalışmasını optimize etmeye yönelik yöntemlerdir.
1. Sorgu önbelleği için sorguları optimize edin
Çoğu MySQL sunucusunda sorgu önbelleğe alma etkindir. Performansı artırmanın en iyi yollarından biri, yalnızca veritabanının kendisine önbelleğe alma sağlamaktır. Bir sorgu birçok kez tekrarlandığında, sonucu önbellekten alınır ve bu, veritabanına doğrudan bir çağrıdan çok daha hızlıdır. Asıl sorun, birçok kişinin önbelleğe alınamayan istekleri kullanmasıdır:
// istek önbelleğe alınmayacak$ r = mysql_query ( "WHERE signup_date> = CURDATE () adlı kullanıcıdan kullanıcı adını SEÇİN"); // ve öyle olacak! $ bugün = tarih ("E-m-d"); $ r = mysql_query ( "WHERE signup_date> kullanıcısından kullanıcı adını SEÇ> =" $ bugün "");Bunun nedeni, ilk isteğin CURDATE() işlevini kullanmasıdır. Bu, ŞİMDİ (), RAND () ve sonucu deterministik olmayan diğerleri gibi tüm işlevler için geçerlidir. İşlevin sonucu değişebilirse, MySQL sorguyu önbelleğe almaz. Bu örnekte, sorgu yürütülmeden önceki tarih hesaplanarak bu önlenebilir.
2. SELECT sorgularınız için EXPLAIN'i kullanın
// hazırlanmış bir ifade oluştur if ($ stmt = $ mysqli -> hazırla ( "Kullanıcıdan kullanıcı adını SEÇ NEREDE durumu =?")) { // değerleri bağla$ stmt -> bind_param ("s", $ durum); // $ stmt yürüt -> yürüt (); // sonucu bağla$ stmt -> bind_result ($ kullanıcı adı); // veri al$ stmt -> getir (); printf ("% s, % s \ n'den", $ kullanıcı adı, $ durumu); $ stmt -> kapat(); )13. Arabelleğe alınmamış istekler
Genellikle, bir istekte bulunurken, komut dosyası durur ve yürütme sonucunu bekler. Arabelleğe alınmamış sorguları kullanarak bunu değiştirebilirsiniz.
mysql_unbuffered_query () işlevinin belgelerinde iyi bir açıklama var:
“Mysql_unbuffered_query (), mysql_query () gibi sonuç satırlarını getirmeden veya otomatik olarak arabelleğe almadan MySQL'e bir SQL sorgusu gönderir. Bir yandan, bu, büyük sonuç kümeleri üreten SQL sorguları için önemli miktarda bellek tasarrufu sağlar. Öte yandan, ilk satırı aldıktan sonra bir dilimdeki sonuç kümesiyle çalışmaya başlayabilirsiniz: SQL sorgusunun tamamının yürütülmesini beklemeniz gerekmez."
Ancak, belirli sınırlamalar vardır. Başka bir sorgu yürütmeden önce tüm kayıtları okumanız veya mysql_free_result () öğesini çağırmanız gerekecektir. Ayrıca, bir fonksiyonun sonucunda mysql_num_rows() veya mysql_data_seek() kullanamazsınız.
14. IP'yi UNSIGNED INT'de saklayın
Birçok programcı, IP adreslerini tamsayı biçiminde saklanabileceklerini bilmeden bir VARCHAR (15) alanında saklar. INT, 4 bayt uzunluğundadır ve sabit bir alan boyutuna sahiptir.
UNSIGNED INT kullandığınızdan emin olun. IP, 32 bit işaretsiz bir sayı olarak yazılabilir.
Bir IP adresini bir sayıya dönüştürmek için bir istekte INET_ATON () ve onu geri dönüştürmek için INET_NTOA () kullanın. Aynı, bu tür işlevler PHP'de de vardır - ip2long () ve long2ip () (php'de bu işlevler negatif değerler döndürebilir. Habrauser The_Lion'dan not edin).
15. Sabit boyutlu tablolar (statik) - daha hızlı
Bir tablodaki her sütunun sabit bir boyutu varsa, o tabloya "statik" veya "sabit boyut" denir. Sabit uzunlukta olmayan sütunlara bir örnek: VARCHAR, TEXT, BLOB. Böyle bir alanı bir tabloya eklerseniz, artık düzeltilmeyecek ve MySQL tarafından farklı şekilde ele alınacaktır.
Bu tür tabloların kullanılması verimliliği artıracaktır, çünkü MySQL, içindeki kayıtları daha hızlı görüntüleyebilir. Bir tabloda istediğiniz satırı seçmeniz gerektiğinde MySQL, konumunu çok hızlı bir şekilde hesaplayabilir. Kayıt boyutu sabit değilse dizine göre aranır.
Ayrıca, bu tabloların bir veritabanı çökmesinden sonra önbelleğe alınması ve geri yüklenmesi daha kolaydır. Örneğin, VARCHAR'ı (20) CHAR'a (20) dönüştürürseniz, gerçek içeriğinden bağımsız olarak kayıt 20 bayt alacaktır.
"Dikey bölme" yöntemini kullanarak değişken satır uzunluklarına sahip sütunları ayrı bir tabloya taşıyabilirsiniz.
16. Dikey ayırma
Dikey bölme - performansı artırmak için bir tabloyu sütunlara bölmek anlamına gelir.
Örnek 1. Adresler users tablosunda saklanıyorsa, onlara çok sık ihtiyaç duyacağınız bir gerçek değildir. Tabloyu bölebilir ve adresleri ayrı bir tabloda saklayabilirsiniz. Böylece kullanıcı tablosunun boyutu küçülecektir. Verimlilik artacaktır.
Örnek 2. Tabloda bir "last_login" alanınız var. Bir kullanıcı siteye her giriş yaptığında güncellenir. Ancak tablodaki tüm değişiklikler önbelleğini temizler. Bu alanı başka bir tabloda saklayarak, users tablosundaki değişiklikleri minimumda tutarsınız.
Ancak bu tabloların birleşimlerini her zaman kullanırsanız, performansı düşürür.
17. Büyük DELETE ve INSERT ifadelerini ayırın
Büyük bir silme veya ekleme isteği yapmanız gerekiyorsa uygulamayı bozmamaya dikkat etmeniz gerekir. Büyük bir sorgu çalıştırmak tabloyu kilitleyebilir ve tüm uygulamanın arızalanmasına neden olabilir.
Apache aynı anda birden fazla eşzamanlı işlemi çalıştırabilir. Bu nedenle, komut dosyaları mümkün olduğunca hızlı yürütülürse daha verimli çalışır.
Tabloları uzun bir süre (örneğin, 30 saniye veya daha uzun süreyle) engellerseniz, siteye gelen yüksek trafikle birlikte, sitenin yavaş çalışmasına ve hatta sunucu çökmesi.
Bunun gibi sorgularınız varsa, bunları küçük gruplar halinde çalıştırmak için LIMIT'i kullanın.
18. Küçük sütunlar daha hızlıdır
Veritabanı için, sabit diskle çalışmak belki de en zayıf noktadır. Küçük ve kompakt kayıtlar genellikle performans açısından daha iyidir. disk çalışmasını azaltın.
MySQL belgeleri, tüm veri türleri için bir veri depolama gereksinimleri listesi içerir.
Eğer tablonuz birkaç satır saklayacaksa, o zaman birincil anahtar türünü INT yapmak anlamsızdır, onu MEDIUMINT, SMALLINT ve hatta TINYINT yapmak daha iyi olabilir. Saati kaydetmeniz gerekmiyorsa DATETIME yerine DATE kullanın.
Ancak sonunun Slashdot gibi olmamasına dikkat edin.
19. Doğru tablo türünü seçin
20. ORM'yi kullanın
21. Kalıcı bağlantılara dikkat edin
Kalıcı bağlantılar, MySQL ile iletişim kurmanın ek yükünü azaltmak için tasarlanmıştır. Bir bağlantı oluşturulduğunda, komut dosyası tamamlandıktan sonra açık kalır. Bir dahaki sefere, bu komut dosyası aynı bağlantıyı kullanacak.
PHP'de mysql_pconnect ()
Ama bu sadece teoride kulağa hoş geliyor. Kişisel deneyimime (ve başkalarının deneyimine) göre, bu fırsattan yararlanmak haklı değildir. Bağlantı sayısını, hafızayı vb. sınırlama konusunda ciddi problemler yaşayacaksınız.
Apache birçok paralel iş parçacığı oluşturur. Kalıcı bağlantıların istediğimiz gibi çalışmamasının ana nedeni budur. mysql_pconnect () işlevini kullanmadan önce sistem yöneticinize danışın.
Bazen, bir sorgu oluştururken, bir tabloda yalnızca bir benzersiz satıra ihtiyacınız olduğunu zaten bilirsiniz. Benzersiz bir kayda dayalı bir seçim oluşturabilirsiniz. Veya durumunuza uyan herhangi bir sayıda kaydın varlığını kontrol edebilirsiniz.
Bu gibi durumlarda, LIMIT 1 yöntemini kullanmak performansı önemli ölçüde artırabilir:
// California halkının veritabanı var mı? // HAYIR, hiçbiri yok!: $ r = mysql_query ("SELECT * FROM user WHERE durumu =" California ""); if (mysql_num_rows ($ r)> 0) (// ... diğer kod) // Olumlu yanıt $ r = mysql_query ("WHERE durumu =" California "LIMIT 1" kullanıcısından 1 SEÇİN); if (mysql_num_rows ($ r)> 0) (// ... diğer kod)
2. Sorgu önbelleğini işleyerek veritabanı ile çalışmanın optimizasyonu
Çoğu MySQL sunucusu, sorgu önbelleğe alma özelliğini destekler. Veritabanı motorunun sorunsuz bir şekilde ele aldığı en etkili performans artırıcı yöntemlerden biridir.
Aynı istek birkaç kez yürütüldüğünde, sonuç önbellekten alınır. Tüm tabloları tekrar işlemek zorunda kalmadan. Bu, süreci önemli ölçüde hızlandırır.
// sorgu önbelleği desteklenmiyorsa $ r = mysql_query ("Kullanıcı adını SEÇ WHERE signup_date> = CURDATE ()"); // önbellek destekleniyor! $ bugün_tarihi = tarih ("E-a-gün"); $ r = mysql_query ("NEREDE kayıt_tarihi kullanıcısından kullanıcı adını SEÇ> =" $ bugün_tarihi "");
3. Arama alanlarının indekslenmesi
Dizinler yalnızca birincil veya benzersiz anahtarlara atanmak için tasarlanmamıştır. Tablonuzda aradığınız sütunlar varsa, onları dizine eklemeniz neredeyse zorunludur.
Tahmin edebileceğiniz gibi, bu kural arama dizesinin bir kısmı için de geçerlidir: örneğin "last_name LIKE‘% '" gibi. Bir satırın başında arama yaparken, MySQL o sütunu indeksleyebilir.
Ayrıca ne tür sorguların normal dizinleri kullanamayacağını da anlamalısınız. Örneğin, bir kelime ararsanız (örneğin, "WHERE post_content LIKE'% domates% ""), normal bir dizin kullanmak sizin için işe yaramaz, bu durumda MySQL tam eşlemeli arama kullanmak veya oluşturmak daha iyidir. kendi indeksiniz.
4. Birleştirme sırasında aynı türdeki sütunları indeksleme ve kullanma
Uygulamanız çok sayıda birleştirme sorgusu içeriyorsa, katıldığınız her iki tablodaki sütunların dizine alındığından emin olmanız gerekir. Bu, MySQL'in dahili birleştirme işlemlerinin optimizasyonunu etkiler.
Ayrıca, birleştirilmekte olan sütunlar aynı türde olmalıdır. Örneğin, bir tablodan DECIMAL sütunu ve diğerinden bir INT sütununu birleştiriyorsanız, MySQL dizinlerden en az birini kullanamaz.
Birleştirilen sütunların karşılık gelen dizeleri için karakter kodlaması bile aynı türde olmalıdır.
// benim durumumdaki şirketleri arıyorum $ r = mysql_query ("kullanıcılardan şirket_adı SEÇİN SOL şirketlere KATIL AÇIK (users.state = şirketler.state) WHERE users.id = $ user_id"); // her iki durum sütunu da indekslenmeli // ve her ikisi de aynı tipte olmalı ve karşılık gelen dizgiler için aynı karakter kodlamasına sahip olmalı // veya MySQL tüm tabloyu taramak zorunda kalacak
5. Mümkün olduğunda SELECT * gibi sorgular kullanmayın
Bir sorgu sırasında tabloda ne kadar çok veri işlenirse, sorgunun kendisi o kadar yavaş yürütülür. Disk işlemlerinde zaman kaybedilir. Ayrıca veritabanı sunucusu web sunucusundan ayrıldığında, sunucular arasında veri aktarımında gecikmeler yaşanmaktadır.
// istenmeyen sorgu $ r = mysql_query ("SELECT * FROM user WHERE user_id = 1"); $ d = mysql_fetch_assoc ($ r); echo "Hoş Geldiniz ($ d [" kullanıcı adı "])"; // aşağıdaki kodu daha iyi kullanın: $ r = mysql_query ("Kullanıcı adını SEÇ WHERE user_id = 1"); $ d = mysql_fetch_assoc ($ r); echo "Hoş Geldiniz ($ d [" kullanıcı adı "])";
6. Lütfen ORDER BY RAND () sıralama yöntemini kullanmayın
Bu, ilk başta iyi görünen numaralardan biridir ve birçok acemi programcı buna bayılır. Bu filtreyi sorgularınızda kullanmaya başladığınızda, kendinize nasıl bir tuzak kurduğunuzu bilemezsiniz.
Arama sonuçlarınızda belirli dizeleri gerçekten sıralamanız gerekiyorsa, bunu yapmanın çok daha etkili yolları vardır. Diyelim ki sorgunuza ek kod eklemeniz gerekiyor, ancak bu tuzak bunu yapmanızı engelliyor, bu da veritabanı büyüdükçe işlem verimliliğini azaltacaktır.
Sorun, MySQL'in tablodaki her satır için sıralama yapmadan önce (sunucunun hesaplama kaynaklarını kullanan) bir RAND () işlemi gerçekleştirmesidir. Bu durumda, yalnızca bir satır seçilecektir.
// hangi kod KULLANILMAMALIDIR: $ r = mysql_query ("Kullanıcı Adını SEÇ ORDER BY RAND () LIMIT 1"); // şu kodu kullanmak daha doğru olur: $ r = mysql_query ("Sayıyı SEÇ (*) KULLANICIDAN"); $ d = mysql_fetch_row ($ r); $ rand = mt_rand (0, $ d - 1); $ r = mysql_query ("LIMIT $ rand, 1 kullanıcısından kullanıcı adını SEÇİN");
Böylece daha az arama sonucu seçeceksiniz ve ardından 1. paragrafta açıklanan LIMIT yöntemini uygulayabilirsiniz.
7. VARCHAR yerine ENUM türündeki sütunları kullanın
ENUM türündeki sütunlar çok kompakttır ve bu nedenle işlenmesi hızlıdır. Veritabanı içinde, içerikleri TINYINT formatında saklanır, ancak herhangi bir değeri içerebilir ve görüntüleyebilirler. Bu nedenle, içlerinde belirli alanları ayarlamak çok uygundur.
Aynı türden birkaç farklı değer içeren bir alanınız varsa, VARCHAR sütunları yerine ENUM kullanmak daha iyidir. Örneğin, yalnızca "etkin", "etkin değil", "beklemede", "gibi değerleri içeren "Durum" sütunu olabilir. süresi doldu" vesaire.
MySQL'in tablonun yapısını değiştirmeyi "önereceği" bir komut dosyası belirtmek bile mümkündür. VARCHAR alanınız olduğunda, sistem otomatik olarak sütun biçimini ENUM olarak değiştirmenizi önerebilir. Bu, PROCEDURE ANALYZE () işlevi çağrılarak yapılabilir.
IP adreslerini depolamak için İMZASIZ INT alanlarını kullanın
Birçok geliştirici bu amaçla VARCHAR (15) alanları oluştururken, IP adresleri veritabanında ondalık sayılar olarak saklanabilir. INT türündeki alanlar 4 bayta kadar bilgi depolama olanağı sağlar ve aynı zamanda sabit bir alan boyutu atanabilir.
IP adresi 32 bit olduğundan kolonlarınızın UNSIGNED INT formatında olduğundan emin olmalısınız.
Sorgularda, IP adreslerini ondalık sayılara dönüştürmek için INET_ATON () parametresini ve tam tersi INET_NTOA () parametresini kullanabilirsiniz. PHP'nin diğer benzer işlevleri long2ip() ve ip2long() vardır.
8. Dikey kesit (bölme)
Dikey bölümleme, veritabanıyla çalışmayı optimize etmek için bir tablonun yapısının dikey olarak bölündüğü bir işlemdir.
Örnek 1: Diyelim ki, diğer şeylerin yanı sıra ev adreslerini içeren bir kullanıcı tablonuz var. Bu bilgi çok nadiren kullanılır. Tablonuzu bölebilir ve adres verilerini başka bir tabloda saklayabilirsiniz.
Böylece, ana kullanıcılar tablonuzun boyutu gözle görülür şekilde daha küçük olacaktır. Ve bildiğiniz gibi, daha küçük tablolar daha hızlı işlenir.
Örnek 2: Tablonuzda bir "last_login" alanınız var. Kullanıcı kendi kullanıcı adı ile her giriş yaptığında güncellenir. Ancak bir tabloda yapılan her değişiklik, diskte depolanan o tablonun sorgu önbelleğine yazılır. Ana kullanıcı tablonuza gelen isabet sayısını azaltmak için bu alanı farklı bir tabloya taşıyabilirsiniz.
Ancak bölümleme sonrası elde edilen her iki tablonun da gelecekte eşit sıklıkta kullanılmayacağından emin olmalısınız. Aksi takdirde, performansı önemli ölçüde düşürür.
9. Daha küçük sütunlar daha hızlıdır
Veritabanı motorları için disk alanı belki de darboğazdır. Bu nedenle, bilgileri daha kompakt bir şekilde depolamak, performans açısından genellikle faydalıdır. Bu, disk erişim sayısını azaltır.
MySQL Docs, farklı veri türlerini depolamak için bir takım gereksinimler içerir. Bir tablonun çok fazla kayıt içermemesi bekleniyorsa, birincil anahtarı INT, MEDIUMINT, SMALLINT ve hatta bazı durumlarda TINYINT gibi alanlarda saklamak için hiçbir neden yoktur. Tarih biçiminde saat bileşenlerine (saat: dakika) ihtiyacınız yoksa, DATETIME yerine DATE türündeki alanları kullanın.
Ancak, gelecekte büyümek için kendinize yeterli alan bıraktığınızdan emin olun. Aksi takdirde, bir noktada çökme gibi bir şey meydana gelebilir.
Sunucudaki yükün derecesi ve dolayısıyla sitenin yüklenme hızı, büyük ölçüde mySQL veritabanına yapılan sorguların ne kadar iyi optimize edildiğine bağlıdır. MySQL sorgularının optimizasyonu, sunucuyu boşaltmaya ve sitenizin yükleme süresini azaltmaya yardımcı olacaktır.
Neden Veritabanı Sorgularını Optimize Edin?
Kendi kendine yazılan yönetim sistemlerinin kontrolü altındaki sitelerin sahipleri, veritabanına hangi sorguların hızlı ve kolay bir şekilde yürütüldüğünü ve hangilerinin sunucu üzerindeki yükü büyük ölçüde artırdığını ve site yükleme hızını önemli ölçüde yavaşlattığını iyi anlamakla yükümlüdür.
Tanınmış yönetim sistemlerini kullanan ve her türlü üçüncü taraf eklentisini bağlamayı seven ve ayrıca temaları kendileri için, örneğin en popüler ücretsiz CMS'de özelleştirmeyi seven web yöneticileri için konunun özünü kavramaktan zarar gelmez. - WordPress.
Bazı eylemler farklı şekillerde gerçekleştirilebilir, örneğin, mysql_num_rows işlevini kullanarak tabloda bulunan kayıtların sayısını sayabilirsiniz (ancak bu önerilmez) veya SEÇİM SAYISI () yapısını da kullanabilirsiniz. Birkaç yüz bin kayıt içeren ve bir gigabayttan daha ağır olan devasa bir veri tablosu oluşturduğumuz ve ardından belirtilen şekillerde satır sayısını saymaya çalıştığımız bir çalışma yaptık.
Sonuç çıplak gözle görülebiliyordu, çünkü mysql_num_rows kullanılması durumunda sayfa 5 saniye askıda kaldı ve ardından sonuç görüntülendi. İkinci durumda, sonucu neredeyse anında tablodaki kayıt sayısı şeklinde aldık. Sonuç çok bariz olduğundan, bir mikro zamanlayıcı kullanarak komut dosyası yükleme süresini ölçmemize bile gerek yoktu.
Aynı şey diğer tasarımlar için de geçerli. Veritabanı ile bazı işlemler iki, üç, dört veya daha fazla şekilde gerçekleştirilebilir ve her birinin hızı kesin olarak farklılık gösterecek ve sonuç her durumda eşit derecede doğru olacaktır.
Veritabanı sorguları nasıl optimize edilir
Sorguların nasıl optimize edileceğini ve hangi yapıların daha hızlı hangilerinin daha yavaş olduğunu tam olarak anlamak için yine küçük bir deney yapacağız ve hemen şimdi yapacağız.
Yardım için popüler ve çok kullanışlı phpmyadmin'in arayüzüne dönmemiz gerekecek. Başlamak için mevcut veritabanlarından birini seçmemiz ve içinde bir test tablosu oluşturmamız gerekiyor. Bizim durumumuzda, adı oldukça yaygın olacak - test.
CREATE TABLE `test` (` ID` INT NOT NULL AUTO_INCREMENT, `TITLE` VARCHAR (100) KARAKTER SET utf8 COLLATE utf8_unicode_ci NOT NULL,` DUYURU` METİN KARAKTER SET utf8 COLLATE ciTEX_unicode, ( `)) MOTOR = MYİSAM;
Şimdi zaten bir test tablomuz olduğuna göre, onu soyut verilerle doldurmamız gerekiyor. Az önce oluşturduğumuz tablonun yapısından da görebileceğiniz gibi, doldurmamız için aşağıdaki verilere ihtiyacımız var:
- başlık
- Duyuru
- Tam metin
Özet metinler için, alışkanlıktan dolayı, sadece bu amaçlar için oluşturulan Yandex.Özetler hizmetine gideceğiz. "XXI Yüzyılda Burulma Fotonu" konusuna denk gelecek kadar şanslıydık ve hadi alalım.
Başlık olarak rastgele seçilmiş bir konuyu belirttik, duyuru olarak vasat bir metin paragrafı aldık ve makalenin tam metni rolünde boşluklu 4000 karakterlik bir metnimiz olacak. Metindeki karakter sayısını saymak için kendi servisimizi kullandık ve içinde saymanızı öneririz, çünkü boşlukları hesaba katmak ya da etmemek için bir seçenek var.
Ortaya çıkan talebi buraya kopyalamayacağız, çünkü bu oldukça cüretkar olan Yandex'in kendisinden alınan 4000 karakterden fazla benzersiz olmayan metin olacaktır ve buna ihtiyacınız da yoktur. Bunun yerine, veritabanına istediğimiz kadar hızlı kayıt ekleyecek basit bir PHP döngüsü çizeceğiz. Başlangıç olarak, bu 100.000 makale olacak.
Ne kadar az veritabanı sorgusu o kadar iyi
Zaten bu aşamada, size şimdi bilinçli olarak yapacağımız yaygın bir hatayı göstereceğiz.
için ($ ben = 1; $ ben<100000;$i++) { mysql_query("INSERT INTO `test` (`ID`, `TITLE`, `ANNOUNCEMENT`, `TEXT`) VALUES (NULL, "Заголовок", "Анонс", "Полный текст")"); }
Bir istek olarak, ilk makalenin tek bir manuel eklenmesinden sonra ekranda görüntülenen phpmyadmin'den kopyalanan kodu yapıştırdık. Hemen belirtmek isterim ki, veritabanına bu şekilde sorgular oluşturmaya değmez. Bunu sadece tabloyu rastgele verilerle hızla doldurmamız gerektiği için yaptık ve bu sorgu daha uygun olandan daha hızlı yazıldı. Bu döngüde veritabanına 99999 ayrı çağrı aldık (ilkini phpmyadmin'den manuel olarak yaptık), bu çok kötü bir form.
Çok daha doğru bir çözüm, aynı işlemi virgülle ayrılmış tüm satırları listeleyerek, veritabanına yalnızca bir çağrı kullanarak yapmak olacaktır.
`test` (` ID`, `TITLE`,` DUYURU`, `METİN`) DEĞERLERİNE EKLE (BOŞ," Başlık "," Duyuru "," Tam Metin "), (NULL," Başlık "," Duyuru " , "Tam metin"), (BOŞ, "Başlık", "Duyuru", "Tam metin"), ...
İlk yöntemimize geri dönersek, şöyle görünür:
INSERT INTO `test` (` ID`, `TITLE`,` DUYURU`, `METİN`) DEĞERLER (NULL," Title "," Duyuru "," Tam Metin ") INSERT INTO` test` (`ID`,` BAŞLIK`, `DUYURU`,` METİN`) DEĞERLER (BOŞ, "Başlık", "Duyuru", "Tam Metin") `test`e EKLE (` ID`, `BAŞLIK`,` DUYURU`, `METİN`) DEĞERLER (BOŞ, "Başlık", "Duyuru", "Tam Metin") ...
Farkı hissediyor musun? Veritabanına yalnızca bir çağrının kullanıldığı değişken optimaldir. Aynı sonuca götüren bu iki yöntemin çalışma hızı zaman zaman farklılık gösterir ve çıplak gözle herhangi bir ölçüm yapılmadan görülebilir, inanın bu gerçekten böyle.
Yalnızca komut dosyasının ihtiyaç duyduğu alanları getir
Burada her şey çok basit - bu veya bu işlevin hedef tablodan belirli verilere ihtiyacı var. Çoğu zaman, özellikle tablo oldukça büyükse ve bu alanlardan 10'dan fazla varsa, genel olarak tüm alanları çıkarmanız gerektiği ortaya çıkıyor.
`test` İÇİ * SEÇİN
Bu sorguda yıldız işareti, verilerin test tablosunun tüm alanlarından alınacağı anlamına gelir. Peki ya tabloda bu alanlardan 20-30 veya daha fazlası varsa? Senaryonun büyük olasılıkla sadece bir kısmına ihtiyacı var ve hiçbir şekilde kullanılmayacak olan geri kalanı boşuna seçilecek. Bu işlem, yalnızca o anda gerçekten ihtiyacınız olan alanları virgülle ayırarak belirtmenize göre daha yavaş olacaktır.
"Test"ten "Kimlik", "BAŞLIK" SEÇ
Bu örnekte, yazının çalışmasını gözle görülür şekilde hızlandıracak olan duyuruya ve makalenin tam metnine hiç değinmeyeceğiz. Bu nedenle, veritabanı sorgularının optimizasyonunun, sorgularda gerekli alanların belirli bir şekilde belirtilmesi ve evrenselliğin yıldız işareti şeklinde reddedilmesi anlamına geldiği sonucuna varıyoruz.
Birden çok sorguyu tek bir sorguda birleştirme
MySQL ile çalışmanın iyi bir şekilde optimize edilmesinin mümkün olan en az sayıda sorgunun kullanılması anlamına geldiğini sizinle daha önce tartışmıştık ve bir tabloya veri eklemeyle ilgili bir örnek vermiştik.
Eklemeye ek olarak, bu teknik veri getirilirken kullanılabilir ve kullanılmalıdır. Şimdi size en basit örneği verelim. Veritabanınızda iki tablonuz olduğunu düşünün - ilk tablo kayıtlı kullanıcılar hakkında bilgi içerir ve ikincisi bu kullanıcılar tarafından yazılan makaleleri içerir.
Diyelim ki rastgele bir makale göstermeniz ve aşağıdaki yazarın adıyla imzalamanız gerekiyor. Bu durumda tablolar arasındaki ilişki açıktır ve kullanıcı kimliği tarafından oluşur, yani users tablosundaki kullanıcı kimliği, gönderiler tablosundaki USER_ID alanına karşılık gelmelidir. Bu bağlantı standarttır ve istisnasız herkes tarafından anlaşılmalıdır.
Rastgele bir makale seçmek için şöyle bir sorgu yazarsınız:
$ rs_post = mysql_query ("SELECT` ID`, `USER_ID`,` TITLE`, `TEXT` FROM` gönderileri` ORDER by RAND () LIMIT 1 ");
Yazılar tablosundan rastgele bir makale seçilir. Bundan sonra, eylemlerimiz şöyle görünecek:
$ row_post = mysql_fetch_assoc ($ rs_post); $ userID = $ row_post ["USER_ID"];
Artık $ userID değişkeni, bu makalenin yazarı olan kullanıcının tanımlayıcısını içeriyor ve onun verilerini, örneğin NAME (ad) ve SURNAME (soyadı) almak için, users tablosuna ve sorgu şöyle görünecek:
$ rs_user = mysql_query ("SEÇ` ADI`, `SURNAME` FROM` kullanıcılar` NEREDE `Kimlik` =" ". $ row_post [" USER_ID "]." "LIMIT 1");
Bu arada, özellikle dışarıdan veri alındığında, GET veya POST kullanarak isteklerde değişkenleri tek tırnak ile çerçevelemeyi unutmayın. Bu, saldırganlar için ek bir engel oluşturacaktır ve SQL enjeksiyonuna karşı korumayı amaçlayan önlemlerden biridir. Öyleyse örneğimize geri dönelim. Veritabanına istek yapıldıktan sonra, her şey basittir - adı ve soyadını alır ve makalenin imzası olarak görüntüleriz. Görev tamamlandı.
Ancak bu iki sorgu, tek bir sorguya dönüştürülerek optimize edilebilir. Bunu yapmak için LEFT JOIN yapısını kullanacağız:
`gönderiler`.`Kimlik`,` gönderiler`.`KULLANICI_KİMLİK`, `gönderiler`.`TITLE`,` gönderiler`.`METİN`, `kullanıcılar`.`NAME`,` kullanıcılar`.`SURNAME` FROM ` seçin gönderiler` LEFT JOIN `users` ON` gönderiler`.`USER_ID` = `users`.`ID` ORDER by RAND () LIMIT 1
Gördüğünüz gibi, yukarıdaki yapıda karmaşık bir şey yok ve her şey sezgisel olarak açık. Dikkatinizi çekmek istediğim tek şey, aynı anda birkaç tablodan bir seçim olduğu için, alanlarla eşleştirilmiş tabloların açıkça belirtilmesidir. Bazı alanların adları aynıysa, daha sonra sonucu görüntülerken kafanızın karışmaması için mySQL takma adları kullanmalısınız.
Çözüm
Gördüğünüz gibi, veritabanı sorgularını optimize etmek mümkün ve gerekli. Her şeyin sizin için çok hızlı çalıştığını düşünüyorsanız, o zaman hiçbir şeyi değiştirmenin bir anlamı olmadığını düşünüyorsanız, sitenizin veritabanı birkaç kez büyüyene ve bununla birlikte trafik büyüyene kadar bekleyin. Yüksek trafik, boyutu operasyonların hızını da etkileyen daha sık eşzamanlı veritabanı çağrıları anlamına gelir.
Sorguların kötü optimizasyonu, site yeterince büyüdüğünde biraz sonra ortaya çıkabilir ve zamanla değişiklik yapmak giderek daha zor hale gelir, çünkü dosya boyutları ve işlevlerin sayısı yalnızca artmaktadır. Siteye kullanıcı dostu olması için yeni özellikler eklenmiştir. Başka bir deyişle, belirli bir kaynama noktasına gelirse, bunun sonu gelmeyebilir ve yüzlerce dosyaya dağılmış tüm veritabanı çağrılarını optimize etmek birkaç gün, belki de haftalar alacaktır. Bu nedenle, gelecekte kendiniz için gereksiz sorunlar yaratmamak için hemen iyi yapmaya çalışmak daha iyidir.
Avatarların psikolojideki değeri
Avatarların psikolojideki değeri
MS Word'de bir harf nasıl vurgulanır
Bir kişinin avatarı ne anlama gelir?
Kendi Twitter Anınızı Nasıl Yaratabilirsiniz?