MySQL adalah batuan padat, database server cepat pencahayaan yang telah dirancang untuk dua faktor kecepatan dan performa. Ini adalah Ferrari dari database: Ringan, cepat dan Dirancang untuk trek kecepatan tinggi!
Aku masih mendengar banyak sekali cerita dari pemilik yang menjalankan dua database lambat. Dalam pengalaman saya, tiga tempat utama untuk mencari masalah adalah:
1. Kesalahan Database Design
2. Pertanyaan Buruk
3. Server faktor
Kesalahan Database Design
desain database yang tepat merupakan faktor paling penting untuk memastikan kinerja dan pemeliharaan database. Berikut adalah apa yang Anda butuhkan untuk menjawab ketika merancang sebuah tabel: Apakah saya dapat mengurangi ukuran data yang setiap baris akan memiliki? Berikut adalah apa yang dapat Anda lakukan:
1. Gunakan nilai numerik unsigned saat aplikasi tidak akan menyimpan angka negatif. Seperti kuantitas "perintah" dari item dalam aplikasi e-commerce yang tidak akan pernah - $ 125.
2. Gunakan panjang variabel nilai dibandingkan dengan nilai panjang tetap i. e. digunakan varchar bukan char.
3. Jangan gunakan tidak perlu ukuran lapangan yang luas. Untuk aplikasi e-commerce yang paling "smallint unsigned" lebih dari cukup untuk menyimpan menghitung persediaan. lapangan A digambarkan sebagai "smallint unsigned" dapat menyimpan nilai maksimum 65535.
4. Jangan mengabaikan normalisasi; yang membantu mencegah pengulangan yang tidak perlu data. B bagian dari ini, jangan normalisasi berlebihan. Jika tabel tidak akan tumbuh dalam ukuran secara signifikan, tidak ada gunanya normalisasi. Misalnya, jika tabel pengguna memiliki hanya 20 baris (yaitu 20 karyawan di sebuah perusahaan), segala usaha normalisasi terbuang.
5. Gunakan Tombol. Jangan memutuskan tombol oleh "id pelanggan harus diindeks pada tabel urutan". Jika pesanan meja sedang dicari 90% kali oleh "tanggal order", akan lebih masuk akal untuk indeks "urutan tanggal".
Ingat, bagaimana tabel akan digunakan harus menentukan bagaimana dirancang. Menghabiskan waktu di sini akan menghemat tahun frustrasi.
Pertanyaan Buruk
Kedengarannya terlalu bagus untuk menjadi kenyataan tetapi Anda wont percaya jumlah pengembang di luar sana yang benar-benar payah menulis query. Ada dua jenis pertanyaan yang buruk:
a) Pertanyaan yang tidak perlu: Ini adalah permintaan yang tidak seharusnya dilakukan di tempat pertama. Satu-satunya cara untuk menghindari ini adalah bertanya, "Apakah saya benar-benar membutuhkan data ini? "
b) inefisien Pertanyaan: Ini adalah permintaan yang tidak menggunakan struktur tabel yang mendasari atau fungsi-fungsi MySQL dengan cara yang benar.
Berikut ini adalah titik awal untuk mulai mencari di daerah masalah:
1. Penggunaan yang tidak perlu "" laporan Pilih * ketika seluruh proses yang dilakukan pada kolom tunggal. Semakin banyak data yang diambil dari server MySQL memiliki lebih banyak pekerjaan yang harus dilakukan dan bandwidth yang lebih dibutuhkan.
2. Menggunakan sub-query, bukan join. Pada database yang dirancang dengan baik, bergabung yang sangat cepat. Menggunakan sub-query hanya menunjukkan kurangnya pengetahuan.
3. Tombol yang tidak tepat penggunaan. Hal ini terutama berlaku untuk cek jangkauan. Ingatlah untuk menggunakan "Jelaskan" pernyataan untuk memeriksa penggunaan kunci dan kemudian menggunakan tombol "menggunakan" pernyataan dalam Anda "di mana" klausa untuk memaksa penggunaan kunci.
Faktor Server
Semuanya dilakukan dengan benar, dapat saja masih terdapat beberapa faktor server yang dapat menyebabkan sistem menjadi lambat. Ini adalah:
1. Hardware terkait
2. Server konfigurasi terkait
Berikut adalah apa yang dapat Anda lakukan tentang hardware:
1. RAM lebih banyak pada sistem semakin baik. MySQL sering menjemput data dari RAM dan lebih RAM adalah pada sistem, semakin baik.
2. Beli RAM tercepat yang memungkinkan! Sebuah RAM lambat hanya ironi.
3. Setelah Anda diselesaikan dengan ukuran RAM dan kecepatan, cari kecepatan pemrosesan. MySQL dapat menggunakan beberapa prosesor.
Setelah Anda puas dengan hardware, ada satu set variabel dalam "saya. CNF "bahwa Anda harus melihat:
a) key_buffer_size: ini menggambarkan memori yang tersedia untuk menyimpan kunci indeks. Defaultnya adalah 8 MB, tapi Anda dapat mengatur untuk 25% dari RAM.
b) query_cache_size: Nilai ini secara default 0. jika Anda memiliki banyak mengulangi permintaan seperti dalam pelaporan aplikasi dll, pastikan Anda menetapkan nilai tinggi.
c) table_open_cache: Ini menentukan jumlah meja yang deskriptor MySQL akan tetap dalam cache. Nilai default adalah 64. Tapi, jika Anda memiliki 100 pengguna yang mengakses sebuah tabel secara bersamaan maka nilai ini harus atleast 100. Anda juga harus memperhatikan pertimbangan bergabung dll demikian, nilai ini juga harus terus tinggi.
Saya harap artikel ini akan mengambil satu langkah lebih jauh dalam unlocking misteri server lambat dan membantu memecahkan beberapa masalah.