Veritabanı Danışmanlığı

Forumda da böyle bir konu başlığı olmadığı için, veritabanı konusunda, özellikle MySQL konusunda aklınıza takılan sorulara burada cevap verelim.

Bu konu başlığı veritabanları konusunda birşeyler öğrenmek isteyen tüm kullanıcılara açıktır.

öncelikle bu şekilde bir konu için teşekkürler.
aklıma uzun zamandır bir kaç soru takılmakta
mysql da kullanmadığım verilerin olması yavaşlığa sebebiyet verirmi ?
scriptin aslında puanlama sistemi mevcuttu ben şu anda bu verileri kullanmıyorum bu veriler site için problem oluştururmu ? mysql dosyam çok çok büyük değil topu topu 200 kb


bu şekilde kod kullanıyorum daha verimli kullanım mevcutmudur ?

1. sorunuz: mysql da kullanmadığım verilerin olması yavaşlığa sebebiyet verirmi ?

Ufak tablolar için çok sorun teşkil etmez.

Ancak ingilizce "best practices" dediğimiz Türkçeye ise "en iyi şekilde uygulama kuralları" olarak çevirebileceğimiz bazı genel kurallar vardır.

Bu kurallar uyarınca gerekmeyen verileri günlük kullanılan veritabanından alıp arşivlemek gerekir.
Eğer bu veri ileride hiç gerekmeyecekse silinebilir de.

Kullanılmayan verinin veritabanında tutulmasının sakıncası:
- Mysql tablo index keylerini bellekte tutar. key_buffer olarak adlandırdığımız bu alan, kullanılmayan verilerin indexleri için de boşuna bellekte yer tutacaktır. Bu bellke alanını sadece kullanılan veriler için tahsis ettiğimizde daha çok index keyleri bellekte tutulur ve bu da daha az disk erişimi yanı hızlanma demektir.

2. sorunuz: Bu kod optimize edilebilir mi "select * from oyunlar where kat='$oyunkat' order by rand() limit 6"

Bu kod tablodan rastgele veri çekmeyi sağlar. rand() foksiyonu sorguyu yavaşlatır. Eğer rastgele veriye ihtiyacınız yoksa order by rand() ı kaldırabilirsiniz.

Eğer rastgele veriye ihtiyacınız varsa, her sayfa gösterildiğinde rastgele veri sorgulamanıza gerek yok. Bu sorgudan dönen veriyi xcache gibi bir cache sisteminin variable (değişken) cache inde saklayarak, örneğin 120 saniyede bir sorgulama yapmasını sağlayabilirsiniz.

PHP için Xcache gibi bir opcode cache kullanmıyorsanız sonucu bir timestamp.txt dosyasında da saklayabilirsiniz. Bu timestamp.txt dosyasının mantığını isterseniz açıklayabilirim.

teşekkürler rand ları en aza indirgemeye çalışıcam eğer veriler ve hit büyürse bu işi işin ehli birine yaptırmak daha hayırlı olacaktır.
Anlamadığım bir nokta free onarcade script gibi scriptlerde oldukça fazla rastgele içerik çeken pencere mevcut ama daha az mysql sorunları yaşıyorlar gibime geliyor. scriptleri incelemedim ama variable cache veta timestamp.txt mi kullanıyorlardır acaba ?

Bahsettiğiniz scriptler hakkında bilgim bulunmuyor.

Select * from yerine select id,baslik,icerik from gibi kullanmak malumunuz yükü bir nebze hafifletiyor.

Ama ben şunu sormak istiyorum. Sadece başlık, icerik ve id olmak üzere 3 alanımız olsun ve sorguda 3'ü de ihtiyaç durumunda. Her iki şekil de kullanılabilir durumda ( Select * from, select id,baslik,icerik from ). Bu şekilde ele alırsak sunucu üzerinde oluşturacakları yükler arasında farklılık oluyor mu ?

Merhaba Hugo,
Sorunuz: Sadece başlık, icerik ve id olmak üzere 3 alanımız olsun ve sorguda 3'ü de ihtiyaç durumunda. Her iki şekil de kullanılabilir durumda ( Select * from, select id,baslik,icerik from ). Bu şekilde ele alırsak sunucu üzerinde oluşturacakları yükler arasında farklılık oluyor mu ?

Hayır bu durumda bir fark olmaz. Veritabanı kendi içinde * ı zaten tektek alan adlarına dönüştürür. Bu işlemi veritabanı optimizeri yapar.

Aslında genellikle "select * from tablo where a=x, b=y" ile "select c,d from tablo where a=x, b=y" arasında performans bakımından hissedilmeyecek kadar az, belkide mikro saniyenin binde biri kadar fark vardır.

İstisna durumlar: Tablodaki alan sayıları çok fazla ise ve birsürü text alan varsa. Örneğin 250 alanlı bir tablo ve 200 alanı text ve büyük varchar verilerden oluşsun. Bu durumda boşu boşuna bu kadar veriyi çekmenin bir manası yok. Bu gereksiz veriler mysql lokal makinada ise I/O haricinde yine çok sorun yaratmaz, ancak mysql makinanız webserver dan ayrı yerde ise bu veri hem I/O hem de network paketleri ile taşınacağı için sonuç gecikmeli gelir. Gecikme zincirleme performans sorunu yaratabilir. Anlık httpd sayısı artar ve Apache yavaşlar, bellekte yer kalmaz, Swapping başlar vb...

Yukarıda bahsettiğimiz gibi "best practices" işin içine girdiğinde her zaman sadece gerekli alanları sorgulamak doğru olanıdır.

Sorgularda asıl dikkat edilecek husus WHERE den sonra gelen alanların indeksli olmasıdır. Doğru indexlenmiş bir tablo sorgularda binlerce kat daha hızlı dönüş sağlayabilir.