MySQL: Büyük VARCHAR mı TEXT mi?

MySQL'de kullanıcılar arasındaki mesajları kaydeden bir mesaj tablosu var. Tipik kimlikler ve mesaj türleri (tüm tamsayı türleri) dışında gerçek mesaj metnini VARCHAR veya TEXT olarak kaydetmem gerekiyor. 3000 karakterlik bir ön uç sınırı ayarlıyorum, bu da mesajların db'ye asla bundan daha uzun eklenmeyeceği anlamına geliyor.

VARCHAR (3000) veya METİN ile devam etmenin bir mantığı var mı? Sadece VARCHAR (3000) yazmayla ilgili bir şekilde karşı sezgisel bir şey var. Stack Overflow ile ilgili diğer benzer yayınlardan geçtim, ancak bu tür ortak mesaj depolamaya özgü görünümler elde etmek iyi olurdu.

• TEXTve BLOB edebilir göre tablosu, gerçek depolama konumunu gösteren bir işaretçi sahip masadan saklanır. Depolandığı yer, veri boyutu, sütun boyutu, row_format ve MySQL sürümü gibi birçok şeye bağlıdır.

• VARCHARtablo ile yerinde saklanır. VARCHARboyutu makul olduğunda daha hızlıdır, bunun daha hızlı olacağı verilerinize ve donanımınıza bağlıdır, gerçek dünya senaryosunu verilerinizle karşılaştırmak istersiniz.

Kullanıcı girişinin ne kadar olacağını tahmin edebilir misiniz?

VARCHAR (X)

Vaka: kullanıcı adı, e-posta, ülke, konu, şifre

---

METİN

Durum: mesajlar, e-postalar, yorumlar, biçimlendirilmiş metin, html, kod, resimler, bağlantılar

---

MEDIUMTEXT

Vaka: büyük json cisimleri, kısa ve orta uzunlukta kitaplar, csv dizeleri

---

LONGTEXT

Durum: ders kitapları, programlar, yıllarca günlük dosyaları, harry potter ve ateş kadehi, bilimsel araştırma kaydı

En iyi uygulamayı netleştirmek için:

1. Metin biçimindeki mesajlar neredeyse her zaman TEXT olarak depolanmalıdır (sonuç olarak keyfi olarak uzun olur)

2. Dize nitelikleri VARCHAR (hedef kullanıcı adı, konu vb.) Olarak saklanmalıdır.

Ön uç sınırınız olduğunu anlıyorum. * sırıtma * Hile DB onu bağlanan uygulamalardan ayrı olarak düşünmektir. Bir uygulamanın verilere bir sınır koyması, verilerin kendiliğinden sınırlı olduğu anlamına gelmez.

Mesajların kendileri hakkında onları asla 3000 karakterden fazla olmaya zorlayan şey nedir? Bu yalnızca rastgele bir uygulama kısıtlamasıysa (örneğin, bir metin kutusu veya benzeri bir şey için) TEXTveri katmanında bir alan kullanın .

Feragatname: Ben bir MySQL uzmanı değilim ... ama bu konudaki anlayışım.

Sanırım TEXT mysql satır dışında saklanırken, sanırım VARCHAR satır bir parçası olarak saklanır. Mysql satırları için maksimum satır uzunluğu vardır .. böylece VARCHAR'ı kullanarak bir satırda ne kadar başka veri depolayabileceğinizi sınırlayabilirsiniz.

Ayrıca VARCHAR'ın satırın bir parçasını oluşturması nedeniyle, bu alana bakan sorguların bir METİN parçası kullananlardan biraz daha hızlı olacağından şüpheleniyorum.

Kısa cevap: Pratik, performans veya depolama, fark yok.

Uzun cevap:

(MySQL'de) ve VARCHAR(3000)(veya başka bir büyük limit) ile arasında hiçbir fark yoktur TEXT. Birincisi 3000 karakterle kesilecek ; İkincisi 65535 de keser bayt . ( Bir karakter birden çok bayt alabileceğinden baytlar ve karakterler arasında bir ayrım yaparım .)

Daha küçük sınırlar için VARCHAR, bazı avantajlar vardır TEXT.

• "daha küçük", sürüme, bağlama ve bağlı olarak 191, 255, 512, 767 veya 3072 vb. anlamına gelir CHARACTER SET.
• INDEXesbir sütunun ne kadar büyük dizine eklenebileceği ile sınırlıdır. (767 veya 3072 bayt ; bu sürüme ve ayarlara bağlıdır)
• Kompleks tarafından oluşturulan ara tablolar SELECTsiki farklı şekilde ele alınır: BELLEK (daha hızlı) veya MyISAM (daha yavaş). 'Büyük' ​​sütunlar söz konusu olduğunda, daha yavaş teknik otomatik olarak seçilir. (8.0 sürümünde yapılan önemli değişiklikler; dolayısıyla bu madde işareti değişebilir.)
• Önceki öğeyle ilgili olarak, tüm TEXTveri türleri (aksine VARCHAR) doğrudan MyISAM'e atlar. Yani, TINYTEXToluşturulan geçici tablolar için otomatik olarak eşdeğerden daha kötüdür VARCHAR. (Ama bu tartışmayı üçüncü bir yöne götürüyor!)
• VARBINARYgibidir VARCHAR; BLOBgibidir TEXT.

Diğer cevaplara tekabül

Orijinal soru bir şey sordu (hangi veri tipinin kullanılacağı); kabul edilen cevap başka bir şeye cevap verdi (kayıt dışı depolama). Bu cevap şimdi güncel değil.

Bu iş parçacığı başlatıldığında ve yanıtlandığında, InnoDB'de yalnızca iki "satır biçimi" vardı. Kısa süre sonra, iki biçim daha ( DYNAMICve COMPRESSED) tanıtıldı.

İçin depolama yeri TEXTve VARCHAR()dayanmaktadır boyutu değil üzerinde, veri türü adı . Bir İçin güncellenmiş büyük metin / damla sütun açık / kapalı-kayıt depolama tartışma, bkz bu .

Önceki cevaplar ana problem üzerinde yeterince ısrar etmiyor: çok basit sorgularda bile

(SELECT t2.* FROM t1, t2 WHERE t2.id = t1.id ORDER BY t1.id) 

geçici bir tablo gerekebilir ve bir VARCHARalan varsa CHAR, geçici tablodaki bir alana dönüştürülür . Yani tablonuzda bir VARCHAR(65000)alan ile 500 000 satır varsa , bu sütun tek başına 6.5 * 5 * 10 ^ 9 bayt kullanır. Bu tür geçici tablolar bellekte işlenemez ve diske yazılır. Etkinin felaket olması beklenebilir.

Kaynak (metriklerle): https://nicj.net/mysql-text-vs-varchar-performance/ (Bu, TEXTvs'nin VARCHAR"standart" (?) MyISAM depolama motorunda ele alınmasını ifade eder . Diğerlerinde farklı olabilir, örneğin, InnoDB.)

Bir yoktur BÜYÜK VARCHAR ve METİN arasındaki fark. VARCHAR alanları dizine eklenebilirken, TEXT alanları eklenemez. VARCHAR türü alanlar TEXT çevrimdışı depolanırken satır içi olarak saklanır, yalnızca TEXT verilerine işaretçiler kayıtlarda saklanır.

Alanınızı daha hızlı arama için dizine eklemeniz gerekiyorsa, ne kadar büyük olursa olsun, VARCHAR için olduğundan daha fazla güncelleme yapın veya güncelleyin. VARCHAR (10000000) hiçbir zaman METİN alanı ile aynı olmayacaktır çünkü bu iki veri türü doğası gereği farklıdır.

• Alanınızı yalnızca arşivleme için kullanıyorsanız
• veri hızı rekabeti umrunda değil
• hızı önemsiyorsunuz ancak arama sorgunuzda '% LIKE%' operatörünü kullanacaksınız, böylece dizin oluşturma çok yardımcı olmayacak
• veri uzunluğu sınırını tahmin edemezsiniz

METİN için gitmekteyiz.

Varchar, e-posta adresleri gibi küçük veriler için, Metin ise haber makaleleri, resimler gibi ikili veriler için Blob gibi çok daha büyük veriler içindir.

Varchar'ın performansı daha güçlüdür çünkü tamamen bellekten çalışır, ancak varchar(4000)örneğin veri çok büyükse durum böyle olmaz .

Öte yandan, metin belleğe yapışmaz ve disk performansından etkilenir, ancak metin verilerini ayrı bir tabloda ayırarak ve metin verilerini almak için sol birleştirme sorgusu uygulayarak bunu önleyebilirsiniz.

Blob çok daha yavaştır, bu yüzden 10000 görüntü gibi çok fazla veriye sahip değilseniz kullanın, bu da 10000 kayda mal olacaktır.

Maksimum hız ve performans için şu ipuçlarını izleyin:

1. Ad, başlıklar, e-postalar için varchar kullanın

2. Büyük veriler için Metin kullanma

3. Farklı tablolardaki metni ayırma

4. Telefon numarası gibi bir kimlikte Sol Birleştirme sorgularını kullanma

5. Blob'u kullanacaksanız Metin ile aynı ipuçlarını uygulayın

Bu, 10 M'den büyük veri ve 10 GB'a kadar boyut garantisi olan tablolarda sorguların milisaniye maliyetini sağlayacaktır.