MySQL performans arttırma için indexleme (left join vb. açısından)

Delphi'de kod yazma ile ilgili sorularınızı bu foruma yazabilirsiniz.
Cevapla
fatihbarut
Üye
Mesajlar: 363
Kayıt: 15 Ara 2011 08:02

MySQL performans arttırma için indexleme (left join vb. açısından)

Mesaj gönderen fatihbarut » 01 Kas 2017 11:38

Arkadaşlar,
MySQL indeksleri ile performans artışı sağlayan varsa yöntemini paylaşabilir mi?
selam.

Edit:

Arkadaşlar soran olarak ben birşey paylaşmak istiyorum;

Foreign key ile birbirine bağlı olup join ile çağrılan tablolardaki master tablodaki ve detail tablodaki key'lerinizi indexe çevirdiğinizde gerçekten göz yaşartıcı bir hız artışı olduğuna gözlerimle şahit oldum.

Ben de diyorum bu forumlarda neden index index deyip duruyorlar. Gerçekten çok güzel. Yalnız sanırsam her tabloda mümkün olduğunca bir index kullanmak lazım o da dediğim gibi master tablonun primary key'i detail tablonunda master tabloya bağlanan foreign key'i

Edit 2:
Bir başka konuysa yine bir query hızı. sqlmanager programı ile bir update işlemini daha önce 1 saat 11 dk içinde yapmıştım. İndekslemeden sonra 6 saniyede bitti.

slm.
En son fatihbarut tarafından 18 Kas 2017 03:05 tarihinde düzenlendi, toplamda 2 kere düzenlendi.

mkysoft
Kıdemli Üye
Mesajlar: 2820
Kayıt: 25 Ağu 2003 11:35
Konum: İstanbul
İletişim:

Re: MySQL performans arttırma için indexleme (left join vb. açısından)

Mesaj gönderen mkysoft » 01 Kas 2017 08:06

Index herşeydir, düzgün kullanmazsanız performans kaybedebilirsiniz. Öncelikle veri tabanını izleyen araçlardan yararlanın. Indexsiz çalışan sorguları tespit edin. Yavaş çalışanları tespit edin. Çıkan loglara göre tabloları, gerekirse uygulamanızın işleyişini geliştirin.

ertank
Üye
Mesajlar: 964
Kayıt: 11 Eyl 2015 11:45

Re: MySQL performans arttırma için indexleme (left join vb. açısından)

Mesaj gönderen ertank » 01 Kas 2017 08:31

Merhaba,

PostgreSQL forumlarında yeni bir projenin database yapısı ile ilgili bir sorgu optimizasyonu için uğraşır iken bana verilen cevap şu olmuştu: Yavaşlık sorunu yaşayana kadar (müşterilerden şikayet gelene kadar) primary key indeks olan hali ile çalış. Ancak şikayet gelir ise o zaman optimizasyon için çalış.

Böyle bir yanıtın açıklaması: Eskiden hızlı olup şimdi yavaş çalışan sorgular ancak yavaşlık çıktığında (yeterince veri girişi olduğunda) tespit edilebilir. Çözümü için ancak o zaman uğraşmak mantıklı. Yeterli veri yokken yapılacak optimizasyon çalışması hatalı olma ihtimali çok çok yüksek. Veri arttığı zaman database sorgu planlayıcı farklı bir plan çıkarıp sizin en başta düşündüğünüz optimizasyon çalışmasını tamamen geçersiz kılar ve en başta yapmaya çalıştığınız bütün o uğraşılar kaybedilmiş zamana çevirebilir.

Bunun yanında her ekstra oluşturulan indeks veri giriş ve güncellemelerinde bir miktar yavaşlamaya sebep olacaktır. Çünkü database sistemi veri girildiğinde tablo içine veriyi yazdıktan sonra indeksler içine de daha küçük, sadece indeks ile ilgili bilgileri yazar. Aynı işlem veri güncellemelerinde indeks ile ilgili alanların güncellenmesinde de vardır.

Bu bilgiler ışığında sorunuzun olası cevabı:
Mutlaka performans artışı sağlayan vardır. Yöntem bütün database sistemleri için aynı olup yavaş çalışan sorgu planını inceleyip öncelikle sorgunun kendisini değiştirme ardından yeterli olmaz ise ek indeks oluşturma, veya duruma ve ihtiyaca göre view, materialized view, işletim sistemi RAM artışı, database sistemi geçici dosyalarını işletim sisteminin daha performansı yüksek disk(leri) üzerine taşıma, database sistemi RAM optimizasyonu (maksimum kullanım, çeşitli cache değerleri vb), eski az sorgulanan verilerin başka tablolara taşınması (partitioning), database sunucu yenileme, database dosya sistemi (raid vb) yenileme vb. şeklinde uzayıp giden çok fazla parametre arasından zaman/maliyet/yapılabilirlik/fayda durumu da göz önünde bulundurulup tercih edilir.

Yapılabilirlik ile kastetmeye çalıştığım: Database sistemine bağlı değişikliklerde, eski verileri taşıma gibi işlemlerde veya çok yoğun database sistemlerinde ek bir materialized view oluşturmak için dahi işlemi yapmayıp planlamak ve ileri tarihte denemeyi yapmak zorunda olduğunuz durumlarla karşılaşılabilir. Müşterinin database sisteminin kapatılmasına tahammülü olmayabilir. En fazla senelik bakıma o da saat limitli izin veriyor olabilir. Bunlar dışında akla gelmeyecek çözüm uygulanmasını engelleyici unsurlarla karşılaşmakta mümkün tabii.

fatihbarut
Üye
Mesajlar: 363
Kayıt: 15 Ara 2011 08:02

Re: MySQL performans arttırma için indexleme (left join vb. açısından)

Mesaj gönderen fatihbarut » 01 Kas 2017 09:33

Arkadaşlar soran olarak ben birşey paylaşmak istiyorum;

Foreign key ile birbirine bağlı olup join ile çağrılan tablolardaki master tablodaki ve detail tablodaki key'lerinizi indexe çevirdiğinizde gerçekten göz yaşartıcı bir hız artışı olduğuna gözlerimle şahit oldum.

Ben de diyorum bu forumlarda neden index index deyip duruyorlar. Gerçekten çok güzel. Yalnız sanırsam her tabloda mümkün olduğunca bir index kullanmak lazım o da dediğim gibi master tablonun primary key'i detail tablonunda master tabloya bağlanan foreign key'i
slm.

Kullanıcı avatarı
greenegitim
Üye
Mesajlar: 669
Kayıt: 28 Nis 2011 09:33
Konum: İstanbul

Re: MySQL performans arttırma için indexleme (left join vb. açısından)

Mesaj gönderen greenegitim » 01 Kas 2017 10:26

@ertank hocamın yazdıklarına aynen katılıyorum şöyle bir örnek vereyim bir stok tablosu düşünün ürün adı alanına bu alanda arama çok yapılır deyip index eklediğinizi ama x müşteriniz için bu çok iyi bir şey olurken y müşteriniz hiç bir zaman stokadına göre arama sıralama v.s ihtiyacı olmayabiliyor tüm arama sıralama v.s işlemleri stokkodu alanından gerçekleşiyor y müşterisine stokadı alanında ki index fuzuli olmuş oluyor.
Mücadele güzelleştirir!

Cevapla