MySQL işlem büyüklüğü - ne kadar büyük?

Her sıklıkta çalışan bir ithalat sürecim var ve bunun “tamamen ya da hiç” bir tür anlaşma olmasını istiyorum.

Birçok yön vardır ve ithalat 100k-1mil + kayıtları arasında herhangi bir yerde üretilebilir. Bu, birkaç MB ile birkaç yüz MB arasında değişen veri yüküne eşittir.

Temp tabloları başka bir seçenek olduğunu biliyorum - ancak bu yöntem çok kullanışlı görünüyor.

Bu tür uygulamalarla ilgili olarak komisyonlar arasında büyük miktarda veri manipülasyonuyla ilgili dikkat edilmesi gereken herhangi bir uyarı var mı? (Bir kez taahhüt edildikten sonra tipik yazma / indeksleme yükü patlaması dışında)

— ince buz
kaynak

Şahsen dengeyi severim. 1k veya 10k işlemlerde ithalat yapıyorum, çünkü bunun sadece 900k satıra ulaşacağını biliyorum ve sonra arabellek boyutu veya saçma bir şey yüzünden çökecek. Ondan almak oldukça kolay ve o kadar G / Ç değil.

— Kaptan Hypertext

Dikkat edilmesi gereken bir tıkanıklığı InnoDB Log Buffer. Boyut innodb_log_buffer_size tarafından ayarlanır . İşte MySQL Dokümantasyonunun bu konuda söylediği:

InnoDB'nin diskteki günlük dosyalarına yazmak için kullandığı arabellek bayt cinsinden boyutu. Varsayılan değer 8 MB'dir. Büyük bir günlük arabellek, büyük işlemlerin işlem gerçekleştirmeden önce günlüğü diske yazmaya gerek kalmadan çalışmasını sağlar. Bu nedenle, büyük işlemleriniz varsa, günlük arabelleğini büyütmek disk G / Ç işleminden tasarruf sağlar.

InnoDB Log Buffer, InnoDB Buffer Pool ile karıştırılmamalıdır. Aralarındaki en büyük fark, onların amacıdır. InnoDB Günlük Tamponu, temel olarak yineleme günlüklerine yazılan kısa vadeli değişiklikleri kaydeder (ib_logfile0, ib_logfile1). InnoDB Buffer Pool ( innodb_buffer_pool_size tarafından boyutlandırılmıştır ), işlenecek (sayfalar kirliyse) ve sonunda yazılan) dizin sayfalarını önbelleğe alır. Kabul edildikten sonra, değişiklik sayfaları LRU kuralları ile kaldırılana kadar RAM’de kalır.

Büyük işlemlerin Kayıt Tamponu aracılığıyla yapılması gerekir. Belirtildiği gibi, daha büyük bir günlük arabelleği disk G / Ç'yi azaltacaktır. Sadece büyük bir taahhüt darboğaz yaratabilir.

Yapılandırmak için diğer InnoDB seçeneklerine bakmak isteyebilirsiniz.

innodb_flush_method : Bu, sifonun nasıl işlendiğini ve OS'nin InnoDB'ye yazmalarını önbelleğe almasına izin verip vermemeyi belirler ( O_DSYNC ve O_DIRECT arasında bir deneme yapmanız gerekir )
innodb_read_io_threads (Maks: 64'ü kullanın)
innodb_write_io_threads (Maks: 64'ü kullanın)
innodb_io_capacity (5000 veya 10000 gibi daha yüksek değerler kullanın, ancak donanım sizin için üst sıralara çıkar, Başka bir deyişle, büyük bir sayı atadığınızda donanımın IO kapasitesine karar vermesine izin verin)
innodb_thread_concurrency : Varsayılan değer 0'dır. Bu numarayı Percona NYC 2011'den Ronald Bradford'dan ilk elden 0'da bırakmak için ilk elden öğrendim. InnoDB'nin yapabileceği en iyi eşzamanlılık biletine karar vermesini sağlar )

Daha fazla araştırma için InnoDB'yi optimize etmekle ilgili başka yayınlarım var

— RolandoMySQLDBA
kaynak

Her nasılsa bu konuda olacağını biliyordum. Her zaman verdiğiniz kesin cevaplar için teşekkürler. Yan soru: innodb_io_capacity kullanımıyla ilgili kaynağınız var mı? Belgeler bir 5400/7200 RPM tüketici SATA'nın 100 değerine sahip olduğunu öne sürdüğünde, stratejiniz bu değeri bu kadar yüksek ayarlayarak sadece 'sınırı kaldırmanızı' önerir misiniz?

— 12'de

Genelde innodb_io_capacity değerini yükseltir ve donanımın üstesinden gelmesine izin veririm. Bunu şu anda cevabımı ekleyeceğim.

— RolandoMySQLDBA