Use OPTIMIZE TABLE to reclaim MySQL tablespace - ApsaraDB RDS

Büyük bir MySQL tablosundan veri silmek için DELETE ifadesini kullandığınızda disk alanı hemen serbest bırakılmaz. Veritabanı bunun yerine kayıtları veya veri sayfalarını yalnızca yeniden kullanılabilir olarak işaretler. Tablo alanını geri kazanmak ve disk kullanımını azaltmak için OPTIMIZE TABLE ifadesini çalıştırın.

Ön koşullar

OPTIMIZE TABLE ifadesi yalnızca InnoDB ve MyISAM depolama motorları tarafından desteklenir.
Örneğin kullanılabilir disk alanı, optimize etmek istediğiniz tablonun boyutuna eşit veya ondan büyük olmalıdır.

Not
Kullanılabilir disk alanı yetersizse öncelikle disk alanını genişletin. İşlem tamamlandıktan sonra ihtiyaca göre alanı küçültebilirsiniz; sistem fiyat farkını iade eder.

Kullanım notları

Önce büyük miktarda veriyi silin: DELETE ifadesiyle önemli miktarda veri silmedikçe OPTIMIZE TABLE çalıştırmak tablo alanı kullanımını azaltmada etkisizdir.
Disk alanı kullanımında geçici artış: OPTIMIZE TABLE çalıştırıldığında yeniden düzenlenen verileri depolamak için geçici bir tablo oluşturulur ve bu durum disk alanı kullanımını geçici olarak artırır. İşlem tamamlandığında geçici tablo silinir ve disk alanı kullanımı normale döner.
Geri kazanım sonrası tablo ve dizin istatistikleri değişmeyebilir: Disk alanı serbest bırakılsa da tablo istatistikleri hemen güncellenmeyebilir. Daha fazla bilgi için bkz. ApsaraDB RDS for MySQL örneğimde OPTIMIZE TABLE çalıştırdıktan sonra depolama kullanımı neden değişmiyor?.
Yoğun saatlerde performans etkisi ve riskler: ApsaraDB RDS for MySQL 5,7 ve 8,0 sürümlerinde OPTIMIZE TABLE ifadesi çevrimiçi DDL kullanır ve eşzamanlı DML işlemlerine olanak tanır. Ancak bu işlemi büyük bir tabloda çalıştırmak G/Ç ve arabellek kaynak tüketiminde ani artışlara neden olabilir. Bu durum tablo kilitlenmelerine veya kaynak çekişmesine yol açarak yoğun saatlerde örnek kullanılamaz hale gelmesine veya izleme kesintilerine neden olabilir. Bu nedenle iş etkisini önlemek amacıyla işlemi yoğun olmayan saatlerde gerçekleştirin.

Komut satırını kullanma

Bir istemci kullanarak ApsaraDB RDS for MySQL örneğine bağlanın.
İş gereksinimlerinize göre gereksiz verileri silmek için DELETE ifadesini kullanın.
Tablo alanını geri kazanmak için OPTIMIZE TABLE ifadesini çalıştırın.
```
OPTIMIZE TABLE <$Database1>.<Table1>,<$Database2>.<Table2>;
```
Not
- <$Database1> ve <$Database2> veritabanı adlarıdır. <Table1> ve <Table2> tablo adlarıdır.
- InnoDB depolama motorunda OPTIMIZE TABLE ifadesini çalıştırdığınızda aşağıdaki ileti döndürülür. Bu ileti beklenen bir durumdur ve dikkate alınmayabilir. Çıktıda "ok" varsa işlem başarılı demektir. Daha fazla bilgi için bkz. OPTIMIZE TABLE Statement.
  
  Table does not support optimize, doing recreate + analyze instead

DMS kullanma

DMS kullanarak ApsaraDB RDS for MySQL örneğinde oturum açın.
Sol gezinme bölmesinde hedef örneğin örnek kimliğini seçin, hedef veritabanına çift tıklayın, herhangi bir tablo adına sağ tıklayın ve ardından batch operation table seçeneğini belirleyin.
Alanını geri kazanmak istediğiniz tabloları seçin ve ardından table maintenance > optimize table seçeneklerini belirleyin.
Açılan iletişim kutusunda bilgilerin doğru olduğunu onaylayın ve OK tıklayın.

İlgili belgeler

Tablo parçalanmasından alan geri kazanma

SSS

OPTIMIZE TABLE sonrası depolama kullanımı neden değişmiyor?

Sorun

Resmi ApsaraDB RDS for MySQL belgelerinde # açıklandığı gibi DELETE ifadesiyle büyük miktarda veri sildikten ve tablo alanını geri kazanmak için OPTIMIZE TABLE çalıştırdıktan sonra information_schema.tables içindeki DATA_FREE alanını sorguladığınızda değerin güncellenmediğini görürsünüz. Bu durum işlemin başarısız olduğu ve disk alanının serbest bırakılmadığı yanılgısına yol açabilir.

Neden

Gerçek disk alanı serbest bırakılmıştır ancak MySQL tablo istatistikleri zamanında güncellenmez. Bu sorun, küçük motor sürümü 20250531'den eski olan ApsaraDB RDS for MySQL 5,6, 5,7 ve 8,0 örneklerinde yaygındır. Bu sürümlerde OPTIMIZE TABLE çalıştırmak tablo ve dizin istatistiklerini otomatik olarak güncellemez. Sonuç olarak information_schema.tables içindeki DATA_FREE değeri eski değerini korur ve gerçek alan kullanımını doğru yansıtmaz. Daha fazla bilgi için bkz. Bug #117426: optimize table does not update table and index stats.

Çözüm

Önerilen çözüm: Küçük motor sürümünü 20250531 (MySQL 8,0 için)

Bu sorun ApsaraDB RDS for MySQL 8,0 için küçük motor sürümü 20250531 sürümünde giderilmiştir. Yükseltme sonrasında OPTIMIZE TABLE istatistikleri otomatik olarak yeniler ve DATA_FREE alanı gerçek alan kullanımını doğru şekilde yansıtır.
- MySQL 8,0 için: Bu sorunu kalıcı olarak çözmek amacıyla küçük motor sürümünü 20250531'e yükseltmenizi öneririz.
- MySQL 5,7 ve 5,6 için: İş planınıza göre önce ana sürümü MySQL 8,0'a yükseltin ve ardından küçük motor sürümünü 20250531'e yükseltin.
Geçici çözüm: İstatistik güncellemesini zorlayın Veritabanı sürümünü kısa vadede yükseltemiyorsanız optimize ettiğiniz tabloda ALTER TABLE table_name ENGINE=InnoDB; ifadesini çalıştırabilirsiniz. Bu ifade tablonun yeniden oluşturulmasını ve istatistiklerinin güncellenmesini zorlar. Komut yürütüldükten sonra information_schema.tables içindeki DATA_FREE alanı geri kazanılan alanı doğru şekilde gösterir.

DELETE ifadesi sonrası alan serbest bırakılmazsa ne yapılmalı?

ApsaraDB RDS for MySQL'de verileri silmek için DELETE ifadesini kullandığınızda komut yalnızca kayıt konumlarını veya veri sayfalarını yeniden kullanılabilir olarak işaretler. Disk dosyası boyutu değişmez, yani tablo alanı hemen geri kazanılmaz. Bu durum örnek depolama alanını tüketen depolama parçalanmasına yol açar.

Yerel DDL komutlarını veya DMS'teki kilitsiz şema değişikliği özelliğini kullanabilirsiniz. Her iki yöntemi de kullanmadan önce örneğinizin kilitlenmesini önlemek için yeterli disk alanına sahip olduğundan emin olun.

Komutlarla alan parçalanmasını giderin: Tablo verilerini ve dizin yapılarını yeniden düzenleyerek parçalanmış alanı geri kazanan OPTIMIZE TABLE veya ALTER TABLE <table_name> ENGINE=InnoDB; gibi DDL işlemlerini çalıştırın.

Önemli
Yerel DDL komutlarını kullanırken meta veri kilitlerinden kaçınmak için bu işlemleri yoğun olmayan saatlerde gerçekleştirin. Daha fazla bilgi için bkz. Kullanım notları.
DMS'teki kilitsiz şema değişikliği özelliğini kullanın: Meta veri kilitleriyle ilgili sorunlardan kaçınmak için bu özelliği kullanarak depolama parçalanmasından alan geri kazanın.

TRUNCATE veya DROP ifadesi sonrası alan serbest bırakılmazsa ne yapılmalı?

ApsaraDB RDS for MySQL'de TRUNCATE veya DROP işleminden sonra disk alanının serbest bırakılmadığını fark ederseniz şu adımları izleyin:

Alan geri kazanma mantığını doğrulayın

TRUNCATE veya DROP ifadesini çalıştırdıktan sonra örneğin depolama kullanımını izleyin alanın serbest bırakılıp bırakılmadığını doğrulamak için. Genellikle depolama kullanımındaki azalma, bırakılan tablonun toplam örnek alanına göre boyutunu yansıtır.
Eski bilgilere güvenmekten kaçının

Tablo boyutunu information_schema.tables veya ApsaraDB RDS konsolu (Database Autonomy Service (DAS) > one-click diagnosis > space analysis) kullanarak kontrol ederseniz veri güncelleme gecikmeleri nedeniyle görüntülenen tablo alanı değişmeyebilir. Bu nedenle değerlendirme için birincil ölçüt olarak örneğin genel depolama kullanımı ölçümüne güvenin.
Eşzamansız silmenin etkisi

Örneğiniz için eşzamansız silme özelliği (Alibaba Cloud'un Purge Large File Asynchronously özelliği gibi) etkinleştirilmişse tablo dosyasının kapladığı alan hemen serbest bırakılmaz. Bunun yerine arka plan işlemi tarafından kademeli olarak temizlenir. Disk alanı bu işlem tamamlandıktan sonra serbest bırakılır.