sys_schema kullanarak MySQL için Azure Veritabanı - Esnek Sunucu'da performansı ayarlama ve veritabanlarını koruma

  • Makale

ŞUNLAR IÇIN GEÇERLIDIR: MySQL için Azure Veritabanı - Tek Sunucu MySQL için Azure Veritabanı - Esnek Sunucu

Önemli

MySQL için Azure Veritabanı tek sunucu kullanımdan kaldırma yolundadır. Esnek MySQL için Azure Veritabanı sunucuya yükseltmenizi kesinlikle öneririz. MySQL için Azure Veritabanı esnek sunucuya geçiş hakkında daha fazla bilgi için bkz. MySQL için Azure Veritabanı Tek Sunucu'ya neler oluyor?

İlk olarak MySQL 5.5'te kullanılabilen MySQL performance_schema, bellek ayırma, depolanan programlar, meta veri kilitleme gibi birçok önemli sunucu kaynağı için izleme sağlar. Ancak, performance_schema 80'den fazla tablo içerir ve gerekli bilgileri almak için genellikle performance_schema içindeki tabloların ve information_schema tabloların birleştirilmesi gerekir. hem performance_schema hem de information_schema üzerine inşa eden sys_schema, salt okunur bir veritabanında kullanıcı dostu görünümlerden oluşan güçlü bir koleksiyon sağlar ve MySQL için Azure Veritabanı esnek sunucu sürümü 5.7'de tam olarak etkinleştirilir.

Views of sys_schema.

sys_schema 52 görünüm vardır ve her görünüm aşağıdaki ön eklerden birine sahiptir:

  • Host_summary veya GÇ: G/Ç ile ilgili gecikme süreleri.
  • InnoDB: InnoDB arabellek durumu ve kilitleri.
  • Bellek: Konak ve kullanıcılar tarafından bellek kullanımı.
  • Şema: Otomatik artış, dizinler vb. şemayla ilgili bilgiler.
  • Deyim: SQL deyimleriyle ilgili bilgiler; tam tablo taramasına veya uzun sorgu süresine neden olan bir deyim olabilir.
  • Kullanıcı: Tüketilen ve kullanıcılara göre gruplandırılmış kaynaklar. Örnek olarak dosya G/Ç'leri, bağlantılar ve bellek verilebilir.
  • Bekleme: Olayları konak veya kullanıcıya göre gruplandırılmış olarak bekleyin.

Şimdi sys_schema bazı yaygın kullanım desenlerine bakalım. İlk olarak, kullanım desenlerini iki kategoride gruplandıracağız: Performans ayarlama ve Veritabanı bakımı.

Performans ayarlama

sys.user_summary_by_file_io

GÇ, veritabanındaki en pahalı işlemdir. sys.user_summary_by_file_io görünümünü sorgulayarak ortalama GÇ gecikme süresini bulabiliriz. Varsayılan 125 GB sağlanan depolama alanıyla GÇ gecikmem yaklaşık 15 saniyedir.

IO latency: 125 GB.

MySQL için Azure Veritabanı esnek sunucu GÇ'yi depolamaya göre ölçeklendirdiğinden, sağlanan depolama alanımı 1 TB'a yükselttiktan sonra GÇ gecikmem 571 ms'ye düşer.

IO latency: 1TB.

sys.schema_tables_with_full_table_scans

Dikkatli planlamaya rağmen, birçok sorgu tam tablo taramalarına neden olabilir. Dizin türleri ve bunları iyileştirme hakkında daha fazla bilgi için şu makaleye başvurabilirsiniz: Sorgu performansı sorunlarını giderme. Tam tablo taramaları yoğun kaynak kullanır ve veritabanınızın performansını düşürür. Tam tablo taramasıyla tabloları bulmanın en hızlı yolu, sys.schema_tables_with_full_table_scans görünümünü sorgulamaktır.

Full table scans.

sys.user_summary_by_statement_type

Veritabanı performans sorunlarını gidermek için veritabanınızın içinde gerçekleşen olayları tanımlamak yararlı olabilir ve sys.user_summary_by_statement_type görünümünü kullanmak işe yarar.

Summary by statement.

Bu örnekte, MySQL için Azure Veritabanı esnek sunucu yavaş sorgu günlüğünü 44579 kez temizlemek için 53 dakika harcadı. Bu uzun bir süre ve birçok IOS. Yavaş sorgu günlüğünüzü devre dışı bırakarak veya Azure portalında yavaş sorgu oturum açma sıklığını azaltarak bu etkinliği azaltabilirsiniz.

Veritabanı bakımı

sys.innodb_buffer_stats_by_table

[! ÖNEMLİ]

Bu görünümü sorgulamak performansı etkileyebilir. Bu sorun giderme işleminin yoğun olmayan iş saatlerinde gerçekleştirilmesi önerilir.

InnoDB arabellek havuzu bellekte bulunur ve DBMS ile depolama arasındaki ana önbellek mekanizmasıdır. InnoDB arabellek havuzunun boyutu performans katmanına bağlıdır ve farklı bir ürün SKU'su seçilmediği sürece değiştirilemez. İşletim sisteminizdeki bellekte olduğu gibi, eski sayfalar da daha yeni verilere yer açmak için değiştirilir. InnoDB arabellek havuzu belleğinin çoğunu kullanan tabloları bulmak için sys.innodb_buffer_stats_by_table görünümünü sorgulayabilirsiniz.

InnoDB buffer status.

Yukarıdaki grafikte, sistem tabloları ve görünümleri dışında, WordPress sitelerimden birini barındıran mysqldatabase033 veritabanındaki her tablonun bellekte 16 KB veya 1 sayfalık verileri kapladığı açıkça görülüyor.

Sys.schema_unused_indexes &sys.schema_redundant_indexes

Dizinler okuma performansını geliştirmek için harika araçlardır, ancak eklemeler ve depolama için ek maliyetler doğurabilir. Sys.schema_unused_indexes ve sys.schema_redundant_indexes kullanılmayan veya yinelenen dizinler hakkında içgörüler sağlar.

Unused indexes.

Redundant indexes.

Sonuç

Özetle, sys_schema hem performans ayarlama hem de veritabanı bakımı için harika bir araçtır. MySQL için Azure Veritabanı esnek sunucu örneğinizde bu özelliğin avantajlarından yararlandığından emin olun.

Sonraki adımlar

  • En ilgili sorularınızın eş yanıtlarını bulmak veya yeni bir soru/yanıt göndermek için Stack Overflow'u ziyaret edin.