Opencart mı //Hayat Bazen Tatlıdır//--//Aşıksan vur saza şofrsen bas gaza// https://zulfumehmet.com/ Kişisel bir olay

select `products`. from bu kısımda products ta ki tüm sütunları almışsın buradan sadece işe yarayanları alırsan daha iyi olur ve en çok where sorgusu yaptığın sütunları indexlemen lazım diye biliyorum Real Eyes Realize Real Lies

bi ihtimal up herkes programcı olmak zorunda değildir, lütfen bir zorunluluk gibi programlama dilleri ğrenmeye çalışmayın. yabancı dil filan ğrenin amq.// s. kimin etini yerim, kasaba minnet etmem.// ince düşünene kalın girer.//

MySQL 8.0.16 versionu kullanıyorum. Aşağıdaki sorguda yavaşlık vardı. Index oluşturmadığım için yavaş olduğu için aşağıdaki şekilde indexler oluşturdum. Sonrasında sorgunun hızında bir değişiklik olmadığı için EXPLAIN ile sorgu planını gzden geçirip birazda araştırdığımda oluşturduğum indexlerin kullanılmadığı kanaatine vardım. Sorgu: select `products`. from `product_filter` inner join `products` on `products`.`id` = `product_filter`.`product_id` where `product_filter`.`brand_id` = 5 and `is_active` = 1 group by `product_id` limit 5 offset 0; Oluşturduğum Indexler: Tablo: products Indexler: products_is_active_IDX Tablo: product_filter Indexler: product_filter_brand_id_IDX EXPLAIN Sonucu: https://paste.ubuntu.com/p/SjjjNpnFtW/ Araştırmalarıma gre "key" kolonu altında yazan index'ler query esnasında kullanılmış olanlar. Yukardaki sonuçta da gzüktüğü gibi sadece PK için oluşturulan key kullanılıyor. Normalde onun yanında product_filter_brand_id_IDX indexininde kullanılması gerekiyor. Aynı şekilde products tablosun içinde products_is_active_IDX indexi kullanılması gerekiyor ancak onuda kullanmıyor. Kafa gitti yani. Nerede hata yapıyorum anlayamadım? herkes programcı olmak zorunda değildir, lütfen bir zorunluluk gibi programlama dilleri ğrenmeye çalışmayın. yabancı dil filan ğrenin amq.// s. kimin etini yerim, kasaba minnet etmem.// ince düşünene kalın girer.//

Çzdüm hacılar. Güzel güzel where'den sonra gelen kolonlara index atarız diye gülüp geçiyordukta hiç group by dan sonraki kolonlar aklımıza gelmemiş hiçbirimizin :) brand_id ve product_id için product_filter tablosunda birleşik index attım, EXPLAIN sonucu artık index kullandığı gzüküyor. Selam ve dua ile herkes programcı olmak zorunda değildir, lütfen bir zorunluluk gibi programlama dilleri ğrenmeye çalışmayın. yabancı dil filan ğrenin amq.// s. kimin etini yerim, kasaba minnet etmem.// ince düşünene kalın girer.//

x-files bunu yazdı Opencart mı Yok dostum kendi geliştirdiğimiz bir uygulama. herkes programcı olmak zorunda değildir, lütfen bir zorunluluk gibi programlama dilleri ğrenmeye çalışmayın. yabancı dil filan ğrenin amq.// s. kimin etini yerim, kasaba minnet etmem.// ince düşünene kalın girer.//

Query yazarken birkaç şeye dikkat etmen lazım. Query filterların where join vs ve onun sonunda dnen data üzerinde yapacağın işlemler group by analitik fonksiyonlar window fonksiyonları. Indeks koymak insertlerini hatta querylerini yavaşlatabilir. Indeks te bir tablodur. Senin 1gb tablon varsa yanına 500mb indeks eklemiş olabilirsin. Bu sefer 100m kayıta çıktığında gol yersin. İlk indeks e force etmesini istiyorsan indeks hint vermen daha doğru olur. https://dev.mysql.com/doc/refman/8.0/en/index-hints.html#: :targetText=The%20FORCE%20INDEX%20hint%20acts, index%20names%2C%20not%20column%20names. Aynen index'in insert, update, delete de dezavantaj yaratacağı durumların farkındayım. Ancak bu tablom statikden hallice olacak . Aslında en güzeli solr'a yada elastice indexletip oradan çatır çatır çekmek var ancak şuanda bu şekilde ilerlemek zorundayım ne yazikki. Şu durumda zaten tablonun kendi boyutundan fazla index boyutu oluşacak gibi daha 5 tane daha ekstra index oluşturmam gerekecek :S Index hint'i denemiştim yinede index vurmamıştı ve normalmiş indexleri yanlış oluşturmuşum. Teşekkürler tekrardan. herkes programcı olmak zorunda değildir, lütfen bir zorunluluk gibi programlama dilleri ğrenmeye çalışmayın. yabancı dil filan ğrenin amq.// s. kimin etini yerim, kasaba minnet etmem.// ince düşünene kalın girer.//

Mysql tarafını bilemeyeceğimde, sunucu tarafında okuma/yazma hızı ne alemde, hiç test yaptın mı hocam? Şu aşamada sunucu kaynakları ve mysql'in konfigurasyon optimizasyonundan nce query deki saçma index kullanamam problemini çzmeyi düşündüğüm için hiç oralara bakmadım. Çünkü çok basit birşey 3m'lik bir tabloya sorgu atıyorsan nce bi indexlerin düzgün ayarlanması gerektiğini düşünüyorum :) herkes programcı olmak zorunda değildir, lütfen bir zorunluluk gibi programlama dilleri ğrenmeye çalışmayın. yabancı dil filan ğrenin amq.// s. kimin etini yerim, kasaba minnet etmem.// ince düşünene kalın girer.//

select `products`. from bu kısımda products ta ki tüm sütunları almışsın buradan sadece işe yarayanları alırsan daha iyi olur ve en çok where sorgusu yaptığın sütunları indexlemen lazım diye biliyorum Hocam. dan sonraki muhabbeti biliyorum. Ancak şu aşamada oradaki kolonları optimize etmemin faydası yok ne yazikki. Where sorgusu içinde kullandığım kolonları indexlemiş olmama rağmen bir şekilde o indexleri kullanmıyor meret :S herkes programcı olmak zorunda değildir, lütfen bir zorunluluk gibi programlama dilleri ğrenmeye çalışmayın. yabancı dil filan ğrenin amq.// s. kimin etini yerim, kasaba minnet etmem.// ince düşünene kalın girer.//

Mysql tarafını bilemeyeceğimde, sunucu tarafında okuma/yazma hızı ne alemde, hiç test yaptın mı hocam?

Query yazarken birkaç şeye dikkat etmen lazım. Query filterların where join vs ve onun sonunda dnen data üzerinde yapacağın işlemler group by analitik fonksiyonlar window fonksiyonları. Indeks koymak insertlerini hatta querylerini yavaşlatabilir. Indeks te bir tablodur. Senin 1gb tablon varsa yanına 500mb indeks eklemiş olabilirsin. Bu sefer 100m kayıta çıktığında gol yersin. İlk indeks e force etmesini istiyorsan indeks hint vermen daha doğru olur. https://dev.mysql.com/doc/refman/8.0/en/index-hints.html#: :targetText=The%20FORCE%20INDEX%20hint%20acts, index%20names%2C%20not%20column%20names. ftw