Toplamaya değer: eksiksiz bir MySQL spesifikasyon kılavuzu
1. Veritabanı komut özelliği
-
Tüm veritabanı nesne adları küçük harf kullanmalı ve alt çizgilerle ayrılmalıdır;
-
Tüm veritabanı nesne adlarının mysql ayrılmış anahtar sözcüklerini kullanması yasaktır (tablo adı sorgu için anahtar sözcükler içeriyorsa, tek tırnak içine alınması gerekir);
-
Veritabanı nesnelerinin isimlendirilmesi isme göre tanınabilmeli ve son sayı 32 karakteri geçmemelidir;
-
Geçici veritabanı tablolarının önüne tmp eklenmeli ve tarih son eklenmiş olmalı ve yedek tabloların önüne bak eklenmeli ve tarih (zaman damgası) eklenmelidir;
-
Aynı verileri depolayan tüm sütun adları ve sütun türleri tutarlı olmalıdır (genellikle ilişkili sütunlar olarak, ilişkili sütun türleri sorgu sırasında tutarsızsa, veri türlerinin örtük dönüşümü otomatik olarak gerçekleştirilir, bu da sütundaki dizinin geçersiz olmasına ve sorgu verimliliğini düşürmesine neden olur).
İkincisi, veritabanının temel tasarım özellikleri
1. Tüm tablolar Innodb depolama motorunu kullanmalıdır Özel gereksinimler yoksa (yani sütun depolama, depolama alanı verileri gibi Innodb'un karşılayamadığı işlevler), tüm tablolar Innodb depolama motorunu kullanmalıdır (Myisam, mysql5.5'ten önceki varsayılandır ve Innodb, 5.6'dan sonra varsayılandır) Innodb işlemleri destekler , Satır düzeyinde kilit, daha iyi kurtarma, yüksek eşzamanlılık altında daha iyi performans desteği.
2. Veritabanının ve tablonun karakter kümesi UTF8'i aynı şekilde kullanır Uyumluluk daha iyidir Birleştirilmiş karakter seti, karakter seti dönüşümünün neden olduğu bozuk karakterleri önleyebilir.Farklı karakter setlerini karşılaştırmadan önce dönüşüm gerçekleştirme ihtiyacı indeks hatasına neden olur.
3. Tüm tabloların ve alanların yorum eklemesi gerekir Tablolar ve sütunlar için açıklamalar eklemek ve veri sözlüğünü baştan korumak için yorum cümlesini kullanın.
4. Tek tablo verilerinin boyutunu kontrol etmeye çalışın ve 5 milyon içinde kontrol etmeniz önerilir MySQL veritabanının sınırı 5 milyon değildir.Aşırı toplantı, tablo yapısının değiştirilmesinde, yedeklemede ve kurtarmada büyük sorunlara neden olacaktır.
Veri miktarını kontrol etmek için geçmiş veri arşivlemeyi (günlük verilerine uygulanır), alt veritabanını ve alt tabloyu (iş verilerine uygulanır) kullanabilirsiniz.
5. MySQL bölüm tablolarını dikkatli kullanın Bölüm tablosu fiziksel olarak birden çok dosya olarak temsil edilir ve mantıksal olarak bir tablo olarak temsil edilir. Bölüm anahtarını dikkatlice seçin, bölümler arası sorgunun verimliliği daha düşük olabilir ve büyük verileri fiziksel olarak bölümlere ayırarak yönetmeniz önerilir.
6. Sıcak ve soğuk verileri ayırmaya ve tablonun genişliğini azaltmaya çalışın MySQL, tablo başına 4096 sütunun depolanmasını sınırlar ve her veri satırının boyutu 65535 baytı aşamaz. Disk G / Ç'sini azaltın ve sıcak verilerin bellek önbellek isabet oranını sağlayın (tablo ne kadar genişse, tablo bellek arabellek havuzuna yüklendiğinde bellek kaplanır Ne kadar büyük olursa, o kadar çok GÇ tüketilir.) Bir tabloda sıklıkla birlikte kullanılan gereksiz soğuk verileri ve sütunları okumaktan kaçınmak için önbelleğin daha etkili kullanımı (daha fazla ilişkili işlemden kaçının)
7. Tabloda ayrılmış alanlar oluşturmak yasaktır Ayrılmış alanların adlandırılması, adları tanımlamak zordur. Ayrılmış alanlar depolanan veri türünü onaylayamaz, bu nedenle uygun tür seçilemez. Ayrılmış alan türlerinde yapılan değişiklikler tabloyu kilitler
8. Veritabanında resimler ve dosyalar gibi büyük ikili verilerin saklanması yasaktır. Genellikle büyük bir dosya, kısa bir süre içinde veri miktarında hızlı bir artışa neden olur. Veritabanı, veritabanından okunduğunda, genellikle çok sayıda rastgele IO işlemi gerçekleştirilir. Dosya büyük olduğunda, GÇ işlemi zaman alır. Genellikle dosya sunucusunda ve yalnızca veritabanında saklanır Dosya adresi bilgileri.
9. Çevrimiçi veritabanı stres testi yapmak yasaktır
10. Oluşturulan ortam veritabanına geliştirme ortamından ve test ortamından doğrudan bağlanmak yasaktır.
Üç, veritabanı alanı tasarım özellikleri
1. Tercihen depolama ihtiyaçlarını karşılayan en küçük veri türünü seçin
-
sebep
Sütun alanı ne kadar büyükse, dizinleme için gereken alan o kadar büyük, bir sayfada saklanabilen dizin düğümlerinin sayısı o kadar küçük ve az ve geçiş sırasında gereken GÇ süresi o kadar fazla , Endeksin performansı da daha kötü.
-
yöntem
1) Bir IP adresini plastik verilere dönüştürmek gibi bir karakter dizesini dijital depolamaya dönüştürün.
mysql, ip adreslerini işlemek için iki yöntem sağlar:
Veri eklemeden önce, ip adresini bir tam sayıya dönüştürmek için inet_aton kullanın, bu da yerden tasarruf sağlayabilir. Verileri görüntülerken, tamsayı ip adresini adres görüntüsüne dönüştürmek için inet_ntoa kullanın.
2) Negatif olmayan veriler için (kendi kendine artan kimlik, tamsayı IP gibi), önce depolama için işaretsiz tamsayı kullanılmalıdır.
Çünkü: imzasız, imzalı ile karşılaştırıldığında depolama alanını ikiye katlayabilir
VARCHAR (N) içindeki N, bayt sayısını değil, karakter sayısını temsil eder
255 Çince karakteri saklamak için UTF8 kullanın Varchar (255) = 765 bayt. Aşırı uzunluk daha fazla bellek tüketir
2. TEXT ve BLOB veri türlerini kullanmaktan kaçının, en yaygın TEXT türü 64k veri depolayabilir
-
BLOB veya TEXT sütunlarını ayrı bir uzantı tablosuna ayırmanız önerilir.
Mysql bellek geçici tabloları TEXT ve BLOB gibi büyük veri türlerini desteklemez. Sorguya bu tür veriler dahil edilirse, sıralama işlemleri sırasında bellek geçici tabloları kullanılamaz ve disk geçici tabloları kullanılmalıdır.
Ve bu tür veriler için, Mysql hala ikinci bir sorgu yapmak zorundadır, bu da sql performansını çok zayıflatacaktır, ancak bu, bu tür veri türlerinin kullanılmaması gerektiği anlamına gelmez.
Kullanmanız gerekiyorsa, BLOB veya TEXT sütununu ayrı bir genişletilmiş tabloya ayırmanız önerilir.Sorgulama sırasında seçme * kullanmayın, yalnızca gerekli sütunları almanız gerekir.TEXT sütununun verilerine ihtiyacınız olmadığında sütunu sorgulamayın.
-
TEXT veya BLOB türü yalnızca önek dizinini kullanabilir
MySQL'in dizin alanlarının uzunluğu konusunda kısıtlamaları olduğundan, TEXT türü yalnızca önek dizinlerini kullanabilir ve TEXT sütununda varsayılan değerler olamaz.
3. ENUM türünü kullanmaktan kaçının
ENUM değerini değiştir, ALTER deyimini kullanmak gerekir
-
ENUM türü ORDER BY işlemi verimsizdir ve ek işlemler gerektirir
-
ENUM'un numaralandırma değerleri olarak sayısal değerlerin kullanılması yasaktır.
4. Tüm sütunları olabildiğince BOŞ DEĞİL olarak tanımlayın
sebep:
-
Index NULL sütunu kaydetmek için fazladan alana ihtiyaç duyar, bu nedenle daha fazla yer kaplar;
-
Karşılaştırma ve hesaplama yapılırken NULL değerlere özel işlem yapılmalıdır.
5. Zamanı saklamak için TIMESTAMP (4 bayt) veya DATETIME türünü (8 bayt) kullanın TIMESTAMP, 1970-01-0100:00:01 ~ 2038-01-19-03: 14: 07 zaman aralığını kaydeder. TIMESTAMP 4 bayt yer kaplar. INT ile aynı, ancak INT'den daha okunabilir TIMESTAMP değer aralığını aşan verileri depolamak için DATETIME türünü kullanın. Çoğu zaman insanlar tarih verilerini saklamak için dizeler kullanır (yanlış uygulama):
-
Dezavantaj 1: Hesaplama ve karşılaştırma için tarih işlevleri kullanılamaz
-
Dezavantaj 2: Tarihleri saklamak için bir dize kullanmak daha fazla yer kaplar
6. Finans ile ilgili miktar verileri ondalık tür kullanmalıdır
-
Hassas olmayan kayan nokta: kayan nokta, çift
-
Hassas kayan nokta: ondalık
Ondalık tür, hassas bir kayan noktalı sayıdır ve hesaplama sırasında hassasiyet kaybolmaz. Kaplanan alan tanımlanan genişliğe göre belirlenir.Her 4 bayt 9 hane saklayabilir ve ondalık nokta bir bayt kaplar. Bigint'den büyük tamsayı verilerini depolamak için kullanılabilir.
Dört, dizin tasarım özellikleri
1. Her tablodaki dizin sayısını sınırlayın. Tek bir tabloda 5'ten fazla dizin olmaması önerilir. Dizinler mümkün olduğu kadar çok değil! Dizinler verimliliği artırabilir ve aynı zamanda verimliliği azaltabilir.
Dizinler sorgu verimliliğini artırabilir, ancak aynı zamanda ekleme ve güncellemelerin verimliliğini azaltabilir ve hatta bazı durumlarda sorgu verimliliğini azaltabilir.
Çünkü mysql optimizer sorguyu nasıl optimize edeceğini seçtiğinde, en iyi yürütme planını oluşturmak için kullanılabilecek her bir dizini birleştirilmiş bilgilere göre değerlendirecektir.Aynı anda çok sayıda dizin varsa sorgu için kullanılabilir, Mysql optimize edicinin bir yürütme planı oluşturması için geçen süreyi artıracak ve ayrıca sorgu performansını azaltacaktır.
2. Tablodaki her sütun için ayrı bir dizin oluşturmak yasaktır. 5.6 sürümünden önce, bir sql bir tabloda yalnızca bir indeks kullanabilir 5.6'dan sonra, indeksleri birleştirmek için bir optimizasyon metodu olmasına rağmen, birleşik indeks sorgulama metodu kullanmaktan hala uzaktır.
3. Her Innodb tablosunun bir birincil anahtarı olmalıdır Innodb, indeksle organize edilmiş bir tablodur: veri depolamanın mantıksal sırası ve indekslerin sırası aynıdır.
Her tablonun birden fazla dizini olabilir, ancak tablonun yalnızca bir saklama sırası olabilir Innodb, tabloyu birincil anahtar dizini sırasına göre düzenler.
Sık güncellenen sütunları birincil anahtarlar olarak kullanmayın ve çok sütunlu birincil anahtarları uygulamayın (birleşik dizinlere eşdeğer). UUID, MD5, HASH veya dize sütunlarını birincil anahtar olarak kullanmayın (sıralı veri büyümesi garanti edilemez).
Birincil anahtar için otomatik artışlı bir kimlik değeri kullanılması önerilir.
Beş, ortak dizin sütunu önerileri
-
SELECT, UPDATE ve DELETE ifadelerinin WHERE yan tümcesinde görünen sütunlar
-
ORDER BY, GROUP BY, DISTINCT içindeki alanlar
1 ve 2'deki alanlarla eşleşen tüm sütunlar için bir dizin oluşturmayın. Genellikle 1 ve 2'deki alanlarda ortak bir dizin oluşturmak daha iyidir.
-
Çoklu tablo ilişkili sütunları birleştirme
Altı, dizin sütunlarının sırası nasıl seçilir
İndekslemenin amacı, indeks yoluyla veri aramak, rastgele IO'yu azaltmak ve sorgu performansını arttırmaktır. İndeksin ne kadar az veri filtreleyebilirse, diskten o kadar az veri okunacaktır.
-
En yüksek ayrım, eklem indeksinin en sol tarafına yerleştirilir (ayrım = sütundaki farklı değerlerin sayısı / sütundaki toplam satır sayısı);
-
Küçük bir alan uzunluğuna sahip olan sütunu ortak dizinin en soluna koymaya çalışın (çünkü alan uzunluğu ne kadar küçükse, bir sayfada saklanabilecek veri miktarı ne kadar büyükse, GÇ performansı o kadar iyi olur);
-
En sık kullanılan sütunlar, eklem dizininin sol tarafına yerleştirilir (böylece daha az dizin oluşturabilirsiniz).
Yedi, gereksiz dizinler ve yinelenen dizinler oluşturmaktan kaçının
Çünkü bu, sorgu iyileştiricisinin bir yürütme planı oluşturması için gereken süreyi artıracaktır.
-
Yinelenen dizin örnekleri: birincil anahtar (kimlik), dizin (kimlik), benzersiz dizin (kimlik)
-
Gereksiz dizin örnekleri: dizin (a, b, c), dizin (a, b), dizin (a)
Sekiz, dizinleri kapsamaya öncelik verin
Sık sorgular için, bir kaplama indeksi kullanmaya öncelik verin.
Kapsama indeksi: tüm sorgu alanlarını içeren dizindir (burada, seçim, sıralama, alanlara göre gruplama)
Dizinleri kapatmanın faydaları:
-
Innodb tablo dizininin ikincil sorgusundan kaçının
Innodb, kümelenmiş dizin sırasına göre depolanır Innodb için, yaprak düğümde depolanan ikincil dizin, satırın birincil anahtar bilgisidir.
Verileri ikincil bir dizinle sorguluyorsanız, karşılık gelen anahtar değerini bulduktan sonra, gerçekten ihtiyacımız olan verileri elde etmek için birincil anahtar aracılığıyla ikincil bir sorgu gerçekleştirmelisiniz. Bir kapsama indeksinde, tüm veriler, birincil anahtarda ikincil sorguları önleyen, GÇ işlemlerini azaltan ve sorgu verimliliğini artıran ikincil dizinin anahtar değerinden elde edilebilir.
-
Rastgele GÇ, sorgu verimliliğini artırmak için sıralı GÇ'ye dönüştürülebilir
Kapsam indeksi, anahtar değerler sırasına göre saklandığından, IO-yoğun aralık araması için, her veri satırını diskten rasgele okumaktan çok daha az IO olduğundan, kapsama indeksi, erişim sırasında diski rastgele hale getirmek için de kullanılabilir. Okunan IO, dizin aramasının sıralı IO'suna dönüştürülür.
Dokuz, dizin SET belirtimi
Yabancı anahtar kısıtlamalarını kullanmaktan kaçınmaya çalışın
-
Yabancı anahtar kısıtlamalarının kullanılması tavsiye edilmez, ancak tablo ile tablo arasında ilişkili anahtar üzerinde bir dizin oluşturulması gerekir;
-
Verilerin referans bütünlüğünü sağlamak için yabancı anahtarlar kullanılabilir, ancak bunların iş tarafında uygulanması önerilir;
-
Yabancı anahtarlar, üst ve alt tabloların yazma işlemlerini etkileyecek ve performansı düşürecektir.
10. Veritabanı SQL geliştirme özellikleri
1. Veritabanı işlemleri için hazırlanmış ifadelerin kullanılması önerilir
Hazırlanan ifadeler bu planları yeniden kullanabilir, SQL derlemesi için gereken süreyi azaltabilir ve ayrıca dinamik SQL'in neden olduğu SQL enjeksiyon sorununu çözebilir; yalnızca parametreleri iletmek, SQL ifadelerini iletmekten daha etkilidir; aynı ifade bir kez, birçok kez ayrıştırılabilir İşleme verimliliğini artırmak için kullanın.
2. Veri türlerinin dolaylı olarak dönüştürülmesinden kaçının
Örtük dönüştürme, dizin hatasına neden olur. Örneğin: isim seçin, id = '111' olan müşteriden telefon;
3. Tablodaki mevcut dizinlerden tam olarak yararlanın
-
Çift% arama koşullarını kullanmaktan kaçının.
Örneğin, "% 123%" gibi bir (önde gelen% yoksa, yalnızca arka%, sütundaki dizin kullanılabilir)
-
Bir SQL, aralık sorgusu için bileşik dizinde yalnızca bir sütun kullanabilir
Örneğin, a, b ve c sütunlarının ortak bir indeksi varsa ve sorgu koşulunda a sütununun bir aralık sorgusu varsa, b ve c sütunlarındaki dizin kullanılmayacaktır.Birleşik indeksi tanımlarken, a sütunu gerekliyse Aralık araması kullanırsanız, birleşik dizinin sağına a sütununu koymalısınız.
Çalışmama durumunu optimize etmek için sol birleştirmeyi kullanın veya mevcut değil
Çünkü değil de genellikle indeks hatası kullanın.
4. Bir veritabanı tasarlarken, gelecekteki genişletmeleri düşünmelisiniz
5. Program farklı veritabanlarına bağlanır ve farklı hesaplar ve ondalık sistemde veritabanı çapraz sorgu kullanır
-
Veritabanı geçişi ve alt veritabanı alt tablosu için yer bırakın
-
İş birleşimini azaltın
-
Aşırı izinlerin neden olduğu güvenlik risklerinden kaçının
6, SELECT kullanımını yasaklayın * SELECT kullanmalısınız < Alan Listesi > Sormak
sebep:
-
Ağ bant genişliği kaynakları ile daha fazla CPU ve IO tüketin
-
Örtme indeksi kullanılamaz
-
Tablo yapısı değişikliklerinin etkisini azaltabilir
7. INSERT deyimlerinin alan listesi olmadan kullanılması yasaktır
Örneğin: değerlere ekle ("a", "b", "c");
T (c1, c2, c3) değerlerine ekle ("a", "b", "c") kullanılmalıdır;
8. Alt sorguları kullanmaktan kaçının, alt sorguları birleştirme işlemlerinde optimize edebilirsiniz
Genellikle alt sorgu in cümlesindedir ve alt sorgu basit SQL'dir (birleşim, gruplama ölçütü, sıralama ölçütü ve sınır cümleleri dahil değildir), daha sonra alt sorgu optimizasyon için ilişkili bir sorguya dönüştürülebilir.
Yetersiz alt sorgu performansının nedenleri:
-
Dizinler, bir alt sorgunun sonuç kümesi için kullanılamaz.Genellikle bir alt sorgunun sonuç kümesi geçici bir tabloda depolanır.Ne bellek geçici tablosunda ne de disk geçici tablosunda dizin olmaz, bu nedenle sorgu performansı belirli bir ölçüde etkilenir;
-
Özellikle nispeten büyük bir sonuç kümesi döndüren alt sorgular için, sorgu performansı üzerindeki etkisi o kadar büyük olur;
-
Alt sorgu çok sayıda geçici tablo oluşturacağından ve dizin oluşturmayacağından, çok fazla CPU ve GÇ kaynağı tüketecek ve bu da çok sayıda yavaş sorguya neden olacaktır.
9. Çok fazla tabloyu ilişkilendirmek için JOIN kullanmaktan kaçının
Mysql için, ilişkili bir önbellek vardır ve önbelleğin boyutu join_buffer_size parametresi ile ayarlanabilir.
Mysql'de, aynı SQL için bir tabloya katılırsanız, bir tane daha ilişkilendirme önbelleği tahsis edilecektir.Bir SQL'de ilişkili daha fazla tablo varsa, bellek o kadar fazla kullanılır.
Programda çok sayıda çoklu tablo ilişkilendirme işlemi kullanılıyorsa ve join_buffer_size ayarı mantıksız ise, sunucu veritabanı performansının kararlılığını etkileyecek şekilde kolayca sunucu belleği taşmasına neden olacaktır.
Aynı zamanda, ilişkilendirme işlemleri için, sorgu verimliliğini etkileyen geçici tablo işlemleri meydana gelecektir.Mysql, 61 tablonun ilişkilendirilmesine izin verir ve 5'i geçmemesi önerilir.
10. Veritabanıyla etkileşim sayısını azaltın
Veritabanı, toplu işlemleri işlemek için daha uygundur. Birden fazla özdeş işlemi bir araya getirmek, işlem verimliliğini artırabilir
11. Aynı sütuna karşılık gelen icra veya yargıda bulunurken, yerine in kullanın veya
İndeksi daha etkin kullanmak için işlemlerde in değeri 500'ü geçmemelidir veya çoğu durumda indeks nadiren kullanılır.
12. Rastgele sıralama için rand () ile sıralama kullanmak yasaktır.
Tablodaki tüm uygun verileri hafızaya yükleyecek ve ardından hafızadaki tüm verileri rastgele oluşturulmuş değere göre sıralayacak ve her satır için rastgele bir değer oluşturabilir.Koşulları karşılayan veri seti çok büyükse, Çok fazla CPU ve IO ve bellek kaynağı tüketecek.
Programda rastgele bir değer elde etmeniz ve ardından veri tabanından veri almanız önerilir.
13. WHERE cümlesindeki sütunlarda fonksiyon dönüşümü ve hesaplama yapmak yasaktır.
Bir sütunda işlev dönüştürme veya hesaplama gerçekleştirirken, dizin kullanılamaz.
-
Tavsiye edilmez:
-
önermek:
14. Yinelenen değerlerin olmayacağı açık olduğunda UNION yerine UNION ALL kullanın
-
UNION, tekilleştirme işlemini gerçekleştirmeden önce iki sonuç kümesinin tüm verilerini geçici tabloya koyacaktır.
-
UNION ALL artık sonuç kümesini tekilleştirmeyecek
15. Karmaşık büyük SQL'i birden çok küçük SQL'e bölün
-
Büyük SQL: Mantıksal olarak karmaşık, hesaplama için çok fazla CPU gerektiren SQL
-
MySQL: Bir SQL hesaplama için yalnızca bir CPU kullanabilir
-
SQL bölündükten sonra, işleme verimliliğini artırmak için paralel olarak yürütülebilir
11. Veritabanı İşlemi için Davranış Kuralları
1. Toplu yazma (UPDATE, DELETE, INSERT) işlemlerinin toplu işlerde birden çok kez 1 milyon satırın üzerinde gerçekleştirilmesi gerekir
-
Büyük toplu işlemler, ciddi ana-bağımlı gecikmesine neden olabilir
Bir master-slave ortamında, büyük ölçekli işlemler ciddi master-slave gecikmelerine neden olabilir. Büyük ölçekli yazma işlemlerinin yürütülmesi genellikle belirli bir süre gerektirir ve yalnızca ana kitaplıktaki yürütme tamamlandıktan sonra diğer bağımlı kitaplıklarda yürütülecektir, bu nedenle Ana kütüphane ile bağımlı kütüphane arasında uzun bir gecikmeye neden olur.
-
Binlog günlüğü satır biçiminde olduğunda çok sayıda günlük oluşturulacaktır
Toplu yazma işlemleri, özellikle satır biçimi ikili veriler için çok sayıda günlük oluşturacaktır.Her veri satırının değiştirilmesi satır biçiminde kaydedildiğinden, bir seferde ne kadar çok veri değiştirirsek, o kadar fazla günlük üretilecektir. Günlük aktarımı ve kurtarması ne kadar uzun sürerse, bu da ana-bağımlı gecikmenin bir nedenidir.
-
Büyük işlem işlemlerinden kaçının
Verilerin toplu olarak değiştirilmesi, tablodaki büyük miktarda verinin kilitlenmesine neden olacak ve MySQL'in performansı üzerinde çok büyük bir etkiye sahip olan büyük miktarda engellemeye neden olacak bir işlemde gerçekleştirilmelidir.
Özellikle, uzun vadeli engelleme, veritabanına yönelik mevcut tüm bağlantıları dolduracak ve bu da üretim ortamındaki diğer uygulamaların veritabanına bağlanamamasına neden olacaktır, bu nedenle toplu yazma işlemlerine dikkat etmeliyiz.
2. Büyük tablolar için tablo yapısını değiştirmek için pt-online-schema-change kullanın
-
Büyük tablo modifikasyonunun neden olduğu master-slave gecikmesinden kaçının
-
Tablo alanlarını değiştirirken tabloyu kilitlemekten kaçının
Özellikle üretim ortamında tolere edilemeyen ciddi tablo kilit işlemlerine neden olacağından, büyük bir tablonun veri yapısını değiştirirken dikkatli olmalısınız.
pt-online-schema-change İlk olarak orijinal tablo ile aynı yapıya sahip yeni bir tablo oluşturacak ve yeni tablodaki tablo yapısını değiştirecek ve ardından orijinal tablodaki verileri yeni tabloya ve orijinal tablodaki verileri kopyalayacaktır. Bazı tetikleyiciler ekleyin.
Orijinal tablodaki yeni eklenen verileri yeni tabloya kopyalayın Satırdaki tüm veriler kopyalandıktan sonra, yeni tablo orijinal tablo olarak adlandırılır ve orijinal tablo silinir.
Orijinal DDL işlemini birden çok küçük grup halinde ayrıştırın.
3. Program tarafından kullanılan hesaba süper izin verilmesi yasaktır
Maksimum bağlantı sayısına ulaşıldığında, süper izne sahip bir kullanıcı da bağlanmak için çalışır. Süper izin yalnızca DBA'nın sorunu ele aldığı hesap için ayrılabilir.
4. Program bağlantısı veritabanı hesabı için en az yetki ilkesine uyun
Program tarafından kullanılan veritabanı hesabı yalnızca bir DB altında kullanılabilir ve veritabanları arası hesapların prensip olarak bırakma izinlerine sahip olmasına izin verilmez.
Kaynak: "Taro Source" genel hesabından yeniden yayınlandı
