Merhaba
Uzunca bir tablodan sorgulama yapıyorum yaklaşık 170,000 kayıt e haliyle yavaş geliyor bende sorguladığım alanlara bir index oluşturdum
ama query ile birlikte index nasıl kullanılır bilmiyorum.
Yardımcı olursanız memnun olurum .
Kolaygelsin.
Query ve İndex Kullanımı ?
Index kullanımı için bazı kriterlere bakılıyor.
Eğer tablolar büyükse, arama ve sıralama işlemleri için index kullanımı kaçınılmaz oluyor. Fakat Tablolar küçükse indexsiz aramalar daha hızlı olabilir. Genellikle satır sayısı büyüyen tabloları, arama anahtarlarına göre indexlemek performansı yükseltir.
Ayrıca tekil satırların garantilenmesi isteniyorsa ve referantial integrity (tablolara arası tutarlılık) kullanılacaksa index kullanılmalı. (Tablolar küçük olsa bile)
Tabii indexleme yapılınca bir dosya daha yaratılıyor. Bu da bir kaynak kullanımı demek. Ayrıca bu dosyanın dengesinin korunmasına da dikkat etmek gerekiyor.
Sorgu kriterlerine uygun indexler veri tabanı tarafından kendiliğinden kullanılır. Sorgulamada birden çok kriter varsa, en küçük sonuç setini üreten kriterden başlayan cümlelere kurmak daha hızlı sonuçlar verebilir.
Eğer tablolar büyükse, arama ve sıralama işlemleri için index kullanımı kaçınılmaz oluyor. Fakat Tablolar küçükse indexsiz aramalar daha hızlı olabilir. Genellikle satır sayısı büyüyen tabloları, arama anahtarlarına göre indexlemek performansı yükseltir.
Ayrıca tekil satırların garantilenmesi isteniyorsa ve referantial integrity (tablolara arası tutarlılık) kullanılacaksa index kullanılmalı. (Tablolar küçük olsa bile)
Tabii indexleme yapılınca bir dosya daha yaratılıyor. Bu da bir kaynak kullanımı demek. Ayrıca bu dosyanın dengesinin korunmasına da dikkat etmek gerekiyor.
Sorgu kriterlerine uygun indexler veri tabanı tarafından kendiliğinden kullanılır. Sorgulamada birden çok kriter varsa, en küçük sonuç setini üreten kriterden başlayan cümlelere kurmak daha hızlı sonuçlar verebilir.
Eğer kullandığınız DB Paradox ise, kayıt sayısı arttıkça DB'nin yavaşlaması kaçınılmaz oluyor (Bariz bir şekilde farkediyor)
Xbase'lere nazaran, SQL Tabanlı DB'lerde (Interbase/FireBird, Oracle, Sybase, Informix, DB2 gibi) bunlardaki yavaşlamalar daha az oluyor.
Daha az oluyor dedim çünkü data sayısı arttıkça yavaşlama kaçınılmazdır.
Aslında tek bir kayıt ararken (eğer uygun indexiniz var ise) hemen hemen her veri tabanı aşağı yukarı aynı zamanlamalarda kayda ulaşırlar. Fakat burada ayrıştırılması gereken nokta ulaşmak istediğiniz kayıtın yada (kayıtların) boyutu.
Query'den dönecek olan ResultSet eğer tek bir kayıttan oluşuyor ise index'in faydasını görürsünüz, ama dönen resultset çok büyük birşey ise (örneğin 10,000 kayıt ve içinde memofieldlar, blobfieldlar var gibi) sizin index işleminizden çok clientın serverdan çekeceği bilgi asıl zamanı alır.
Bir çok SQL tabanlı DB'ler Natural Order - Table Scan (indexsi olmayan tablelarda) yeterince iyi sorgulama yapabiliyor ancak indexli olursa bu çok daha fazla bir hıza kavuşuyor.
MS-SQL Server üzerinde yaptığım Plan analizlerinde ve Performans Tuning araştırmalarında gördüğüm şu oldu, eğer table'da 8-10 kayıt gibi sayısı çok düşük miktarda record var ise, index olmuş yada olmamış farketmiyor (indexlemede page taşması yaratmayacak şekilde düşünün, yani indexlense bile tek bir index page'ine tüm recordları yerleştirebileceği sayıda) ve Server burada genelde Table Scan'i tercih ediyor. Ancak kayıt sayısı arttıkça index ihtiyacı ortaya çıkıyor.
Örneğin iki table var, Master ve Detail diye düşünün, master'da fatura başlık bilgileri, detail'de ise detay bilgileri bulunsun, bir query dizayn edip, tüm fatura bilgilerini listelediğinizi düşünün, yazılacak olan query'de kurulacak olan link detail'deki faturano (veya Autoincremental bir field oluşturmaz isek, masterdeki kaydın ID'si) ile kurulup sorgu sonucu döndürülür. Bunu Server yorumlarken, eğer index'i var ise ve işlem tamamıyle server üzerinde gerçekleşen bir işlem ise (join) çok hızlı bir şekilde gerçekleştirecektir. Gerekli indexler oluşturulmadıysa hız farkı gözlemlenebilir indexsiz olarak resultset'in daha yavaş döndüğü gözlemlenir.
Performans Tuning aslında kendi başına bir konudur, ancak sizlere şu tavsiyelerde bulunabilirim. (Özetle)
1. Index kullanın
2. Table'larınızı mümkün mertebe çok fieldlı oluşturmayın. Yani bir table'de 15-20'den fazla field oluşturmamaya özen gösterin. (Bu verdiğim rakam öylesine bir rakam, illa olacak diye bir şey yok). Eğer elzem ise, memo, blob gibi fieldları ayrı table'lare atın ve bu attığınız ayrı table'lara master kaydın IDsini verin.
3. Autoincremental-Identity fieldlar oluşturun ve tablelar arasında bu linkleri kullanın. (Bu bir tavsiye)
4. Indexlerinizde mümkün olduğunca sayısal (Integer) fieldlara ağırlık verin, ve linklerinizde kullanacağınız Autoincremental alanları kullanın. Unutmayın, String bir field'ı indexlemek ve üzerinde arama yapmak, Integer bir field'ı indexleyip arama yapmaktan daha uzun zaman alacaktır. (Genel olarak)
5. Oluşturulan indexlerde, datası az tekrar edenden fieldları, indexte ön sıralarda tutmaya özen gösterin. Örneğin bir table'ınız var ve bu tableda ISLEM_TARIHI, MAMUL_KODU, SIRKET_KODU, CALISMA_YILI, IRSALIYE_NO gibi fieldlar olsun. Indexlemeyi yaparken içlerinde en sık tekrar edebilecek nitelikte olan SIRKET_KODU ardından CALISMA_YILI ardından MAMUL_KODU ardından ISLEM_TARIHI ve son olarak da IRSALIYE_NO fieldını indexte sıralı biçimde verilmelidir. Bu Server'ın seek time'ını minimuma indirecektir. (Dikkat sadece örneğimize göre, bu böyle kesindir diye bir şey yok !) Örneğimizde, server üzerinde 2,000,000kayıt olduğunu varsayalım. Bu kayıtların 800,000 kaydın A sirketine kalan 1,200,000 kaydın B şirketine ait olduğunu varsayalım. Indexlemede en sık tekrar eden alan SIRKET_KODU olduğu için Queryde 'WHERE SIRKET_KODU = "A" ' dediğiniz anda otomatikman, 1,200,000 kaydı ilk etapta dışarı atmış olursunuz ve geriye server'ın incelemesi gereken 800,000 kayıt kalır. Çalışma yıllarıda örneğimizde 2000, 2001, 2002 ve 2003 olsun. Ayıklanan 800,000 kayıttan 250,000'i 2000 yılına 230,000'i 2001 yılına, 200,000'i 2002 yılına ve kalan 120,000 kayıtta 2003 yılına ait olsun. Querymizdeki where clause ise 'WHERE SIRKET_KODU = "A" AND CALISMA_YILI = 2003 ' dediğimizde incelenecek kayıt sayısı 2,000,000'dan bir anda 120,000'e iner
Böylece tekrar sayısı düşük olan alanları indexlerde son kısımlara bırakarak, Server'ın arama yaparken kullanacağı (BinaryTree gibi düşünebiliriz) arama mantığını rahatlatarak performans artışını sağlarız. Yani server arama yaptığınız recordları bulurken birkaç adımda bulma olanağına sahip olur. Biraz uzun bir madde oldu ama umarım anlaşılabilmiştir.
6. Xbase'lerde Summary fieldları tutun (Biraz ağlarsınız ve abidik gubidik işler yapmak zorunda kalırsınız ama hızınızı arttırır ), SQL Tabanlı DB'lerde tutmayın bırakın Server uğraşsın, viewler veya Stored Procedure'lere yıkın bu tür işleri.
7. Client ile Server arasında mümkün olduğunca az iletişim kurmasını sağlayacak yöntemler kullanın. Örneğin basit kontrolleri olan bir döngü (table üzerinde bir kontrol yapıp biryerlere birşeyler işleyen bir döngüyü hayal edin) programınız ile server arasında sürekli, query1.next veya skip gibi işlemler yaptırmayın bunun yerine eğer olabiliyorsa bu tür işlerinizi stored procedure'lere yıkın. Hızınınızın inanılmaz acayip bir şekilde arttığını göreceksiniz. Başımıza gelen bir olaydan bahsedeyim, bir eşleme işleminde program tarafında işlemlerimizi hallediyorduk, veri nbüyüdükçe acayip yavaşladı, yaklaışk 20-30 dakika sürer bir hale geldi ve oturup biz bu eşlemeleri stored procedure haline döndürdük bu 20-30 dakikalar 20 saniyenin altına indi. Dikkat 20 saniye, dakika değil
Bu denli hızlanmalar olur.
daha yazacaklar var ama bende şu anda yazmaktan sıkıldım ancak konu ile ilgili muhakkak Adminimiz Mustafa'nın bir yerlerde bir yazısı veya linki vardır o tavsiyede bulunsun.
Kolay Gelsin.
Xbase'lere nazaran, SQL Tabanlı DB'lerde (Interbase/FireBird, Oracle, Sybase, Informix, DB2 gibi) bunlardaki yavaşlamalar daha az oluyor.
Daha az oluyor dedim çünkü data sayısı arttıkça yavaşlama kaçınılmazdır.
Aslında tek bir kayıt ararken (eğer uygun indexiniz var ise) hemen hemen her veri tabanı aşağı yukarı aynı zamanlamalarda kayda ulaşırlar. Fakat burada ayrıştırılması gereken nokta ulaşmak istediğiniz kayıtın yada (kayıtların) boyutu.
Query'den dönecek olan ResultSet eğer tek bir kayıttan oluşuyor ise index'in faydasını görürsünüz, ama dönen resultset çok büyük birşey ise (örneğin 10,000 kayıt ve içinde memofieldlar, blobfieldlar var gibi) sizin index işleminizden çok clientın serverdan çekeceği bilgi asıl zamanı alır.
Bir çok SQL tabanlı DB'ler Natural Order - Table Scan (indexsi olmayan tablelarda) yeterince iyi sorgulama yapabiliyor ancak indexli olursa bu çok daha fazla bir hıza kavuşuyor.
MS-SQL Server üzerinde yaptığım Plan analizlerinde ve Performans Tuning araştırmalarında gördüğüm şu oldu, eğer table'da 8-10 kayıt gibi sayısı çok düşük miktarda record var ise, index olmuş yada olmamış farketmiyor (indexlemede page taşması yaratmayacak şekilde düşünün, yani indexlense bile tek bir index page'ine tüm recordları yerleştirebileceği sayıda) ve Server burada genelde Table Scan'i tercih ediyor. Ancak kayıt sayısı arttıkça index ihtiyacı ortaya çıkıyor.
Örneğin iki table var, Master ve Detail diye düşünün, master'da fatura başlık bilgileri, detail'de ise detay bilgileri bulunsun, bir query dizayn edip, tüm fatura bilgilerini listelediğinizi düşünün, yazılacak olan query'de kurulacak olan link detail'deki faturano (veya Autoincremental bir field oluşturmaz isek, masterdeki kaydın ID'si) ile kurulup sorgu sonucu döndürülür. Bunu Server yorumlarken, eğer index'i var ise ve işlem tamamıyle server üzerinde gerçekleşen bir işlem ise (join) çok hızlı bir şekilde gerçekleştirecektir. Gerekli indexler oluşturulmadıysa hız farkı gözlemlenebilir indexsiz olarak resultset'in daha yavaş döndüğü gözlemlenir.
Performans Tuning aslında kendi başına bir konudur, ancak sizlere şu tavsiyelerde bulunabilirim. (Özetle)
1. Index kullanın
2. Table'larınızı mümkün mertebe çok fieldlı oluşturmayın. Yani bir table'de 15-20'den fazla field oluşturmamaya özen gösterin. (Bu verdiğim rakam öylesine bir rakam, illa olacak diye bir şey yok). Eğer elzem ise, memo, blob gibi fieldları ayrı table'lare atın ve bu attığınız ayrı table'lara master kaydın IDsini verin.
3. Autoincremental-Identity fieldlar oluşturun ve tablelar arasında bu linkleri kullanın. (Bu bir tavsiye)
4. Indexlerinizde mümkün olduğunca sayısal (Integer) fieldlara ağırlık verin, ve linklerinizde kullanacağınız Autoincremental alanları kullanın. Unutmayın, String bir field'ı indexlemek ve üzerinde arama yapmak, Integer bir field'ı indexleyip arama yapmaktan daha uzun zaman alacaktır. (Genel olarak)
5. Oluşturulan indexlerde, datası az tekrar edenden fieldları, indexte ön sıralarda tutmaya özen gösterin. Örneğin bir table'ınız var ve bu tableda ISLEM_TARIHI, MAMUL_KODU, SIRKET_KODU, CALISMA_YILI, IRSALIYE_NO gibi fieldlar olsun. Indexlemeyi yaparken içlerinde en sık tekrar edebilecek nitelikte olan SIRKET_KODU ardından CALISMA_YILI ardından MAMUL_KODU ardından ISLEM_TARIHI ve son olarak da IRSALIYE_NO fieldını indexte sıralı biçimde verilmelidir. Bu Server'ın seek time'ını minimuma indirecektir. (Dikkat sadece örneğimize göre, bu böyle kesindir diye bir şey yok !) Örneğimizde, server üzerinde 2,000,000kayıt olduğunu varsayalım. Bu kayıtların 800,000 kaydın A sirketine kalan 1,200,000 kaydın B şirketine ait olduğunu varsayalım. Indexlemede en sık tekrar eden alan SIRKET_KODU olduğu için Queryde 'WHERE SIRKET_KODU = "A" ' dediğiniz anda otomatikman, 1,200,000 kaydı ilk etapta dışarı atmış olursunuz ve geriye server'ın incelemesi gereken 800,000 kayıt kalır. Çalışma yıllarıda örneğimizde 2000, 2001, 2002 ve 2003 olsun. Ayıklanan 800,000 kayıttan 250,000'i 2000 yılına 230,000'i 2001 yılına, 200,000'i 2002 yılına ve kalan 120,000 kayıtta 2003 yılına ait olsun. Querymizdeki where clause ise 'WHERE SIRKET_KODU = "A" AND CALISMA_YILI = 2003 ' dediğimizde incelenecek kayıt sayısı 2,000,000'dan bir anda 120,000'e iner
Böylece tekrar sayısı düşük olan alanları indexlerde son kısımlara bırakarak, Server'ın arama yaparken kullanacağı (BinaryTree gibi düşünebiliriz) arama mantığını rahatlatarak performans artışını sağlarız. Yani server arama yaptığınız recordları bulurken birkaç adımda bulma olanağına sahip olur. Biraz uzun bir madde oldu ama umarım anlaşılabilmiştir.6. Xbase'lerde Summary fieldları tutun
(Biraz ağlarsınız ve abidik gubidik işler yapmak zorunda kalırsınız ama hızınızı arttırır ), SQL Tabanlı DB'lerde tutmayın bırakın Server uğraşsın, viewler veya Stored Procedure'lere yıkın bu tür işleri. 7. Client ile Server arasında mümkün olduğunca az iletişim kurmasını sağlayacak yöntemler kullanın. Örneğin basit kontrolleri olan bir döngü (table üzerinde bir kontrol yapıp biryerlere birşeyler işleyen bir döngüyü hayal edin) programınız ile server arasında sürekli, query1.next veya skip gibi işlemler yaptırmayın bunun yerine eğer olabiliyorsa bu tür işlerinizi stored procedure'lere yıkın. Hızınınızın inanılmaz acayip bir şekilde arttığını göreceksiniz. Başımıza gelen bir olaydan bahsedeyim, bir eşleme işleminde program tarafında işlemlerimizi hallediyorduk, veri nbüyüdükçe acayip yavaşladı, yaklaışk 20-30 dakika sürer bir hale geldi ve oturup biz bu eşlemeleri stored procedure haline döndürdük bu 20-30 dakikalar 20 saniyenin altına indi. Dikkat 20 saniye, dakika değil
Bu denli hızlanmalar olur.daha yazacaklar var ama bende şu anda yazmaktan sıkıldım ancak konu ile ilgili muhakkak Adminimiz Mustafa'nın bir yerlerde bir yazısı veya linki vardır o tavsiyede bulunsun.
Kolay Gelsin.
Kuri Yalnız Jedi
Harbi Özgürlük İçin Pisi http://www.pisilinux.org/
Harbi Özgürlük İçin Pisi http://www.pisilinux.org/