En iyi Mysql tablo optimizasyonu yapma. Tablo türü ozellikleri

[vilee]

CREATE TABLE `haberablo` (
`id` int(11) NOT NULL auto_increment,
`konu` text NOT NULL,
`mesaj` text NOT NULL,
`tarih` text NOT NULL,
`okunma` text NOT NULL,
`resim` text NOT NULL,
PRIMARY KEY (`id`)
) TYPE=MyISAM AUTO_INCREMENT=1;

arkadaslar ben mysql tablolurının hepsini alan türlerini " text NOT NULL,"
şeklinde yapıyorum bi zararı var mı ?
varchar md5 gibi şeylerde var ama boyle en basit ve kısa çözüm. diğerleri karışık geliyor.
birde `id` int(11) NOT NULL auto_increment, burda 'id' int(32323) yapsak ne olur.

son oalrak en iyi tablo optimizasyonu nasıl yapılır. 80 - 90 milyon kullanıcılı bir sistem yapıcamda bununiçin en iyi tablo optimizasyonu nasıl olur neler yapılır. daha hızlı sorgu yapmak için ne yapılır.
,mysql daha hızlı çalışması için neler
yapılır ayrıntılı bilgi vermenizi bekliyorum

az kullanıcılı sistemlerde bu tur şeyler fazla onemli değil ama
50 milyondan fazla kullanıcılı sistemlerde bunlar gerekiyor.
teşekkürler

[deathisonitsway]

tarih` text NOT NULL,

bu ne demek ki...her kayıtta kendin mi tarih yazıyorsun...yani topu topu tarih yazdıracaksın text alan niye yapıyorsun o da ayrı bir mevzu...zaten tarih alanına text yapılmaz...okunma ne demek...hit mi?

id int(32323) demek 32 bin 323 karakter alır demek...normalde int alan pozitif degerse ; 0 ile 4294967295 karakter alır...ama yine gereksiz...bu kadar bilgi hiç bir sitede yoktur...

yani temel olarak ezberine kacmıssın işin....varchar veya char ile kısa karakter tanımlamaları yapmayı dene.

[vilee]

evt php ile tarihi alıp kayıt ettiriyorum
o tabloyu ornek verdim
daha dogrusu nasil yapılabilir

[deathisonitsway]

varchar veya char olarak girilmesi daha mantıklı ama duruma gore degisir tabi misal ziyaretciden bilgi mesajı alınması isteniyorsa o zaman da longblob kullanılabilir

mesaj longblob not null gibi



.misal kullanici adi icin gidipte longblob alan kullanılmaz...

[deathisonitsway]

BINARY 1 bayt / karakter Herhangi bir türdeki veri, bu tür alanda saklanabilir. Veri üzerinde çeviri yapılmaz (örneğin metin şekline). Verilerin ikili alana nasıl girildiği, çıktı olarak nasıl görüneceğini belirler.

BIT 1 bayt Yalnızca Evet ve Hayır değerlerinden birini içeren Evet ve Hayır değerleri ve alanları

TINYINT 1 bayt 0 ile 255 arasında bir tamsayı.

MONEY 8 bayt – 922,337,203,685,477.5808 ve 922,337,203,685,477.5807 arasında ölçeklenmiş bir tamsayı.

DATETIME
(See DOUBLE) 8 bayt 100 ve 9999 yılları arasında bir tarih veya saat değeri.

UNIQUEIDENTIFIER 128 bit Uzak yordam çağrılarında kullanılan benzersiz bir kimlik numarası.

REAL 4 bayt Negatif değerler için – 3.402823E38 ile – 1.401298E-45 arasında ve pozitif sayılar ile 0 için 1.401298E-45 ile 3.402823E38 arasında tek duyarlıklı kayan noktalı değerdir.

FLOAT 8 bayt Negatif değerler için – 1.79769313486232E308 ile – 4.94065645841247E-324 arasında ve pozitif sayılar ile 0 için 4.94065645841247E-324 ile 1.79769313486232E308 arasında çift duyarlıklı kayan noktalı değerdir.

SMALLINT 2 bayt – 32,768 ile 32,767 arasında kısa tamsayıdır.

INTEGER 4 bayt – 2,147,483,648 ile 2,147,483,647 arasında uzun tamsayıdır.

DECIMAL 17 bayt 1028 - 1 ile - 1028 - 1 arasında değerleri tutan kesin bir sayısal veri türü. Hem duyarlılığı (1 - 28) hem de ölçeği (0 - tanımlı duyarlık) tanımlayabilirsiniz. Varsayılan duyarlık ve ölçek sırasıyla 18 ile 0'dır.

TEXT 2 bayt / karakter. Sıfır ile en çok 2.14 gigabayt arasıdır.

IMAGE Gerektiği kadar Sıfır ile en çok 2.14 gigabayt arasıdır. OLE nesneleri için kullanılır.

Character: 2 bayt/karakter sıfır ile 255 karakter arasıdır.

.................................................. ..................................................

[vilee]

teşekkürler

[sineld]

int ile maksimum 11 karakter (rakam) kullanabilirsiniz. 99999999999 şeklinde

ancak bazen bir-iki kayıt oluşturmak için bile bunun böyle kullanıldığını görüyorum. bunun yerine tinyint ile 2 yani en fazla 99 kullabilirsiniz.

11 karakter bana yetmez derseniz bigint kullanın bu 22 karaktere kadar destekleyecektir, yani 9999999999999999999999

çok büyük bir rakam topluluğu, kullanımından kaçınılmalı.

[Lazaronnie]

Hortlatma olacak ama başka bilgiye muhtaç arkadaşlar için bende bir ekleme yapmak isterim, performans için başvurulacak bir diğer yol ise index yapmaktır;

Örneğin elinizde bir tablo var diyelim, bu tabloda ülkemizin tüm şehirleri karmaşık bir şekilde (alfabetik olmadan) duruyor ve farz edelimki 81 tane değilde 800.000 tane ilimiz olsun (komik bir örnek ama sonuçta misal veriyoruz)
böyle bir durumda sql ile bir filtre yazalım, sql kardeş sen git bana tüm "N" ile başlayan kayıtları al getir, böyle bir durumda sql bizim malum tabloya gidecek ve ilk kayıttan dalacak tabloya yada alana ve tüm kayıtları tek tek tarayacaktır,800.000 kaydı belki nispeten kısa bir sürede halledebilirsede 8 milyon kayıt olduğu zaman server resmen ağlayacaktır oysaki bu tablodaki tüm veriler alfabetik olarak duruyor olsalar sql bu sefer yaklaşık hangi tabloya gideceğini ortalama olarak kestirebiliyor ve böylece daha az kayıt tarayarak işlem süresi kafa göz yara yara kısalıyor, bu indexlerin nasıl yapılacağına gelirsek, yeni bir tablo açıyoruz ve indexini yapmak istediğimiz tablodaki verileri bu yeni tabloya sıralı bir halde geçiriyoruz, bununda dezavantajı odur ki kapasite artışı (!) öyleyse yapacağımız şey her alanda bu özelliği kullanmamaya dikkat etmeliyiz, yani çok gerekli yerlerde bu işe girişirsek ortaya çıkacak boyut artışının neden olduğu zarar beraberinde getireceği performansla dengelenecektir


Ayrıca açtığınız tüm veritabanı nesnelerini (ki hoş tüm nesnelerde durum bu) kapatın, yoksa serverin belleği şiştikçe şişecektir...


Örneğin üyeleriniz var ve bazı yerlerde bu üyelerin yapmış olduğu herhangi bir işlemin sayısı size lazım oluyor, bu durumda önünüzde iki yol bulunmkta, birinci yoldan giderseniz üyelerin yaptığı işlerin tutulduğu (örneğin mesaj yollama siteye girme okuduğu yazı vs vs) tablolara gidersiniz, muhtemelen bu tabloda diğer tüm üyelerin yaptıkları malum işler toplu bir halde duruyordur,siz bu tabloya bir üyenin id numarasıyla girer ve üyenin idleriyle kayıtlanmış işlemleri seçtirirsiniz ve seçtiğiniz kayıtları gerek bir bileşenle gerekse SQL'in sağladığı toplam bulma seçeneğiyle saydırırsınız ve gereken yerde bu bilgiyi gösterirsiniz, ancak bu sayma işini her lazım olduğunda tekrarlatmak bu istekte bulunan kullanıcı sayısınıda düşünürsek VT'ye gereksiz bir yük bindirir, oysa ikinci yoldan giderek her üyenin üyelik bilgilerinin tutulduğu alanda birde gerekli istatistik alanlarınıda açarsak (nasılki üyenin ismi için bir alan açıyoruz, hemen yanına örneğin toplam mesaj sayısı gibi bir alan açarız) üyenin istatistikleri etkileyici bir işlem yapması durumunda işlemin akabinde direk bu alandaki sayıyı da güncellersek, üyemizin istatsitiklerini hiçbir zaman saymamıza gerek kalmayacak, lazım olan bilgiyi üyenin kayıt alanındaki gerekli hücreye ulaşarak direk elde edebileceğiz, herhalde basit bir hücreye erişip içindeki verinin çekilmesinin bir server'a ve VT'ye ne derecede az bir yük bindireceğini herkes tahmin edebilir, korkulacak tek yer vardır ki üyenin işlem yaptıktan sonra birde istatistik alanının güncellenmesi olayıdır ki burada hem üyenin yaptığı işlemi ilgilendiren "yeni kayıt" "edit" "delete" olayına hemde üyenin yaptığı işlemin istatistiğini tutan alanı güncelleyecek bir bağlantı yaratmak durumundayız, bu durumda mutlaka bir performans düşüşü yaratacaktır ancak tüm kayıtların sayıldığı yukarıdaki senaryoyu göz önüne alırsak pekte dikkate alınası bir dezavantaj değildir...

[nothing__]

Dostum o söylediğin üyelerin yaptığı işlemleri saydırma yöntemi normalizasyon kurallarına ayrıkırı. Büyük sistemlerde tercih edilen bir çözüm değildir. Ayrıca sağlıklı da değildir.

[Lazaronnie]

Büyük sistemlerde nasıl yapıldığını biliyorsan yazar mısın? Benim yazdığımda o zaman küçük sistemler için geçerli bir şey diyebiliriz en azından