Merhaba,
Genel olarak performans sorunu yaşadığınız query 'nin execution planına ve query ye bakmak lazım. Ancak böyle index kullanılıp kullanılmadığı belirlenebilir. Örneğin bir order by kullanımımız varsa sort buffer arttırılmaya ve bu sıralama operasyonunun hedefi olan veri kümesi küçültülmeye çalışılabilir. Tabi bu konular genel çözümler değil özel çözümler üretilmesi gereken konulardır. Eğer aynı select tekrar tekrar gönderiliyorsa mysql query cache çok işe yarayabilir. Bazı filtreleme kullanımları vardır ki index kullanımı kesin olarak engeller ve bu veritabanı tipinden bağımsız bir konudur. "Select * from mytable where myfield like '%bişey%" böyle bir sorgudur. Mytable tablosunun tüm satırlarındaki myfield alanına, "bişey" kelimesini içeriyor mu bakmak gerekir sonuç kümesi hazırlamak için. Buradaki myfield alanı indexli olsa da, filtre koşulu tüm index kayıtları taranmadan bulunamayacağında ve bu ek bir yük ve yavaşlama dışında bir Kazanım sağlamayacağından , index otomatik olarak kullanılmaz. Ve kullanılmaması daha iyi bir fikirdir gerçektende. Tabi en iyi fikir filtrelemede mümkünse "=" operatörü kullanmak, değilse "%bişey%" yerine "bişey%" gibi bir yapı kullanmaktır. İlla filtreleme içerisinde "%bişey%" kullanılacak ve query çok yavaş diyorsanız bu konuya öncelikle my.ini , execution plan ve diğer tunning opsiyonlarından başlayarak donanım upgrade kararına kadar giden bir yolda değerlendireceksiniz demektir. İki veritabanı tipide kendine has özellikleri ve aslında kullanım alanları olan yapılardır. Örneğin innodb üzerindeki kilitleme mekanizması row level locking dediğimiz şekilde çalışır. Yani update operasyonlarında sadece update edilen satır değişikliklere kapatılır. Tablonuzda eş zamanlı değişiklik miktarı fazla ise bu durum çok önemli olur. Sadece select gelecekse de önemli olmaz. Ayrıca myisam foreign key desteklemez ve data block değil index cache tutar. Myisam transactional değildir. Innodb transactional' dır ve her kritik uygulama transaction yapısına ihtiyaç duyar desek yanlış olamaz heralde. İlk anda aklıma gelen önemli bulduğum farklılıklar bunlar. Selamlar Barış AKVERDİ From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: Sunday, December 11, 2011 1:01 AM To: [email protected] Subject: [Linux-sunucu] Re: Mysql'de 15 milyon kayıt bulunan bir tabloda select sıkıntısı 5 alanı ayrı ayrı index mevcut ancak index yapmadanda denedim sonuç çok değişmedi oe-rder kullanıyorum kullanıcının seçeceği 3 alandan birine göre tablo tipini myisam ve innodb olarak denedim ikiside süreyi kısaltmadı şimdilik anlık sorgulama yapan 1 kişi var ancak sunucuya talşıyınca 50 civarı olucak Vedat beyin dediği gibi tabloyu parçalamayı düşünüyorum, bu durumda mecburen 5 alanı 1 e düşürerek sadece isme göre arama yapıcam ve kayıt işleminide başharfe göre gerekli tabloya yazıcam conf dosyası aşağıda, bu dosyayı internetten okuduğum bilgilere göre değiştirdim port = 3306 socket = /var/run/mysqld/mysqld.sock [mysqld] port = 3306 socket = /var/run/mysqld/mysqld.sock skip-locking #key_buffer_size = 384M key_buffer_size = 1G max_allowed_packet = 8M table_open_cache = 512 sort_buffer_size = 2M read_buffer_size = 2M read_rnd_buffer_size = 8M myisam_sort_buffer_size = 64M thread_cache_size = 8 query_cache_size = 32M thread_concurrency = 8 log-bin=mysql-bin server-id = 1 innodb_buffer_pool_size = 1024M innodb_additional_mem_pool_size = 256M innodb_thread_concurrency = 8 innodb_flush_method = O_DIRECT [mysqldump] quick max_allowed_packet = 16M [mysql] no-auto-rehash [myisamchk] key_buffer_size = 256M sort_buffer_size = 256M read_buffer = 2M write_buffer = 2M [mysqlhotcopy] interactive-timeout 10.12.2011 23:49, Atıf CEYLAN yazmış: Sorgulama yaptıgınız alanlarda ındex varmı? Bırde mysql ındexlemeyı eskıden farklı fıeldları ayrı ayrı ındexledıgınızde hafızada map etmeyı beceremıyordu (sanırım 6-7 yıl önce). Bu nedenle birlikte kullanılan alanları birlikte indexlemek cok işe yarıyordu. Tabi bu kadar zamandır mysql kullanmadığım için fazla yorum yapamıyacağım ancak indexlemede sorun yoksa bu sayıda bir tablodan sadece where clause ekleyerek sorgu yapmanın bu kadar uzun sürmemesi lazım. Tabi order, group vb işlemler yapmıyor olduğunuzu farz ediyorum. Ayrıca mysql konfigurasyonu ve kullandığınız tablo tipi nedir? Anlık sorgulama yapan kaç kullanıcı var? Bu soruların cevapları da önemli. 10.12.2011 16:00, [email protected] yazmış: Merhaba arkadaşlar ; Mysql de 15 milyon olan ve ayda 100 bin artan bir tablomuz var 27 alandan oluşan ve sorgulama arayüzünü delphi7 de yaptım; 5 alana göre arama yapıyorum kullanıcı 5 alanadan istediğini veri girerek sorgulama yapabiliyor, dönen adet 500 ü geçiyorsa kriteri artırımasını istiyorum ancak geri dönüş süreleri çok uzun oluyor minimum 1 dk 40 sn civarı bu süreyi nasıl minimuma indirebilirm ? denediklerim -- tabloyu myisam ile oluşturdum 1dk 40sn -3 dkcivarı sonuç aldım -- innodb ye çevirdim durum biraz garipleşti 30 sn ile 7 dk arasında değişti -- tabloyu bölemiyorum sabit bir kriterim yok (sene gibi 2004, 2005) aramalarımda 3 alan için "like %" diğer iki alan için "=" kullanıyorum, 5 alanıda ayrı ayrı indexledim. sistem özellikleri ; mysql Ver 14.14 Distrib 5.1.49, for debian-linux-gnu (x86_64) using readline 6.1 test makinam : Intel(R) Core(TM) i5 CPU 650 @ 3.20GHz 3GB RAM tüm denemeleri bu sistemde yaptım. -- /** * @author Atıf CEYLAN * Software Developer & System Admin * http://www.atifceylan.com */ _______________________________________________ Linux-sunucu E-Posta Listesi [email protected] Liste kurallarını http://liste.linux.org.tr/kurallar.php bağlantısından okuyabilirsiniz; Bu Listede neden bulunduğunuzu bilmiyorsanız veya artık bu listeden gelen e-postaları almak istemiyorsanız aşağıdaki bağlantı adresini kullanarak 1 dakika içinde üyeliğinizi sonlandırabilirsiniz. https://liste.linux.org.tr/mailman/listinfo/linux-sunucu
_______________________________________________ Linux-sunucu E-Posta Listesi [email protected] Liste kurallarını http://liste.linux.org.tr/kurallar.php bağlantısından okuyabilirsiniz; Bu Listede neden bulunduğunuzu bilmiyorsanız veya artık bu listeden gelen e-postaları almak istemiyorsanız aşağıdaki bağlantı adresini kullanarak 1 dakika içinde üyeliğinizi sonlandırabilirsiniz. https://liste.linux.org.tr/mailman/listinfo/linux-sunucu
