Perkongsian yang sangat disukai: Idea pengoptimuman MySQL yang selaras dengan pengeluaran

                                                                                                               

Kata Pengantar

Titik permulaan menulis artikel ini adalah untuk merekodkan pengalaman terkumpul saya dalam menangani data di tempat kerja Semasa saya menulis dan menulis, saya mendapati bahawa setiap perkara akan diperolehi. Pengetahuan latar belakang lain harus disediakan, seperti semasa mengoptimumkan indeks, anda perlu mempunyai pemahaman tertentu tentang pertanyaan lambat, Jelaskan dan fungsi lain yang berkaitan Sebagai contoh, apabila memperkenalkan Elasticsearch, anda perlu menyelesaikan masalah data penyegerakan, pelajari pengetahuan Elasticsearch, dsb. Oleh kerana panjang artikel, adalah mustahil untuk merangkumi setiap perkara yang semuanya terperinci seperti tutorial video, dan saya hanya boleh meringkaskannya berdasarkan pengetahuan saya yang terhad dan beberapa perkara umum. Walaupun begitu, kepanjangan artikel itu sudah sangat panjang. Jika anda berminat dengan sesuatu perkara, sila pergi ke Baidu/Google untuk pengetahuan mendalam tentang butiran individu.

Artikel itu agak panjang, jadi jika anda berminat, anda mungkin mahu membacanya sehingga anda tidak membuang masa berpuluh-puluh minit. [Pembelajaran yang disyorkan: "Tutorial Video MySQL"]

Perspektif Pemikiran

Teknologi pangkalan data telah melalui peringkat pengurusan manual dan peringkat sistem fail setakat ini dan peringkat sistem pangkalan data.

Pada zaman awal apabila tiada sistem perisian, operasi dunia sebenar perniagaan tertentu juga boleh direalisasikan melalui peringkat pengurusan manual perakaunan manual dan perjanjian lisan Borang ini telah wujud sejak sekian lama dan adalah agak tidak efisien. Pada peringkat seterusnya, dengan perkembangan teknologi komputer, terdapat peringkat sistem fail yang menggantikan perakaunan manual dengan jadual excel, yang meningkatkan produktiviti ke tahap tertentu. Dalam peringkat sistem perisian, iaitu sistem pangkalan data dengan operasi mudah dan kecekapan tinggi, produktiviti telah dipertingkatkan lagi, masalah khusus dalam dunia nyata disarikan kepada data, dan perniagaan dunia nyata diwakili melalui aliran dan perubahan data. Dalam sistem perisian, storan data secara amnya terdiri daripada pangkalan data hubungan dan beberapa pangkalan data bukan hubungan.

Pangkalan data sangat berkaitan dengan perniagaan sistem Ini memerlukan pengurus produk untuk memahami penyimpanan data dan proses pertanyaan semasa mereka bentuk perniagaan, adalah jelas kesan perubahan perniagaan ada pada pangkalan data dan sama ada Timbunan teknologi baharu perlu dirujuk. Sebagai contoh, perniagaan yang direka oleh pengurus produk adalah untuk melakukan analisis statistik dan ringkasan data pada berbilang jadual MySQL dengan jumlah jadual tunggal berjuta-juta Jika pertanyaan berbilang jadual MySQL digunakan secara langsung, pertanyaan perlahan pasti akan berlaku dan menyebabkan msyql perkhidmatan untuk turun Dalam kes ini, penyelesaiannya ialah Sama ada berkompromi pada bahagian produk atau menukar timbunan teknologi.

Seni bina sistem dan penyelesaian pangkalan data harus dipilih agar lebih sesuai untuk keupayaan pasukan syarikat Pada peringkat awal sistem, pengoptimuman pangkalan data yang mudah digabungkan dengan keupayaan bank akan menjadi penyelesaian yang paling kos efektif. tetapi apabila ia datang kepada keupayaan pangkalan data mysql, tiada apa yang boleh anda lakukan, memperkenalkan perkhidmatan perisian yang menumpukan pada fungsi utama akan menjadi penyelesaian yang paling kos efektif nilai.

Seorang budak lelaki miskin jatuh cinta dengan seorang gadis kaya. Kemanisan jangka pendek tidak sepadan dengan ketidaksamaan kelas yang sebenar. Pengakhiran yang bahagia hanya wujud dalam fantasi si miskin dan siri TV Teacher Qiong Yao.

Cara meningkatkan prestasi storan data pada kos terhad ialah idea utama artikel ini.

Pengetahuan latar belakang

Saya percaya anda akan sering bersentuhan dengan kandungan berikut dalam kerja harian anda, jadi saya akan meringkaskannya secara ringkas.

Pangkalan Data Perhubungan

Pangkalan data perhubungan ialah organisasi data yang terdiri daripada jadual dua dimensi dan perkaitan di antaranya, menyediakan ketekalan data transaksi dan Fungsi seperti kegigihan data ialah perkhidmatan storan teras sistem perisian Ia adalah pangkalan data yang paling kerap kami hubungi semasa pembangunan dan temu bual Untuk beberapa projek penyumberan luar kecil, satu MySQL cukup untuk memenuhi semua keperluan perniagaan. Ia adalah sesuatu yang sering kita temui, dan ia sebenarnya penuh dengan rahsia Kita akan membincangkan rahsia secara terperinci dalam bab-bab berikut.
Kelebihan:

1. Transaksi
2. Kegigihan
3. Bahasa SQL yang agak biasa

Masalah

1. Keperluan I/O cakera keras adalah sangat tinggi
2. Kecekapan pertanyaan pengagregatan bagi sejumlah besar data adalah rendah
3. Indeks tidak mencapai
4. Prinsip pemadanan paling kiri bagi indeks membawa kepada ketidaktepatan Sesuai untuk mendapatkan semula teks penuh
5. Penggunaan transaksi yang tidak betul boleh menyebabkan kesesakan kunci
6. Peluasan mendatar membawa pelbagai masalah yang sukar ditangani

Pangkalan data jenis bukan perhubungan - NoSql

Pangkalan data MySQL, sebagai perisian penyimpanan data perhubungan, mempunyai kelebihan dan kelemahan yang jelas, apabila jumlah data sistem perisian terus berkembang dan kerumitan perniagaan terus meningkat, Kami tidak boleh mengharapkan untuk menyelesaikan semua masalah dengan meningkatkan keupayaan pangkalan data MySQL Sebaliknya, kami perlu memperkenalkan perisian storan lain dan menggunakan pelbagai jenis NoSQL untuk menyelesaikan masalah volum data sistem perisian yang berkembang dan meningkatkan kerumitan perniagaan.
Pangkalan data hubungan ialah pengoptimuman pangkalan data hubungan dalam senario yang berbeza Ini tidak bermakna semuanya akan baik dengan memperkenalkan beberapa jenis NoSQL, tetapi ini bermakna memahami sepenuhnya jenis dan kesukaran aplikasi NoSQL di pasaran, dan memilih yang. storan yang sesuai dalam senario yang sesuai adalah cara untuk pergi.

Jenis Nilai Utama

Dalam perniagaan, kandungan jadual tertentu sering disoal, tetapi kebanyakan hasil pertanyaan kekal tidak berubah, jadi perisian storan nilai kunci, terutamanya Memcached dan Redis, telah muncul dan digunakan secara meluas dalam modul cache dalam sistem. Redis mempunyai lebih banyak struktur data dan ketekunan daripada Memcached, menjadikannya yang paling banyak digunakan dalam kalangan NoSQL jenis KV.

Jenis carian

Dalam senario carian teks penuh, pengoptimuman pertanyaan indeks pepohon MySQLB, pertanyaan seperti tidak boleh memukul indeks, dan setiap pertanyaan kata kunci seperti adalah satu masa Imbasan jadual penuh boleh disokong dalam jadual dengan puluhan ribu data, tetapi pertanyaan perlahan akan berlaku pada penghujung data Jika kod perniagaan tidak ditulis dengan baik dan pertanyaan Suka dipanggil dalam transaksi, kunci baca akan berlaku. ElasticSearch, dengan indeks terbalik sebagai terasnya, boleh memenuhi senario carian teks penuh dengan sempurna Pada masa yang sama, ElasticSearch juga menyokong data besar dengan baik, dan dokumentasi dan ekologi juga sangat bagus menaip.

Jenis dokumen

Jenis dokumen NoSql merujuk kepada jenis NoSql yang menyimpan data separa berstruktur sebagai dokumen NoSql jenis dokumen biasanya menyimpan data dalam format JSON atau XML , jadi NoSql jenis dokumen tidak mempunyai Skema Memandangkan tiada ciri Skema, kita boleh menyimpan dan membaca data sesuka hati Oleh itu, kemunculan NoSql jenis dokumen menyelesaikan masalah pengembangan struktur jadual pangkalan data yang tidak selesa. Pengarang tidak pernah menggunakan

Lajur

Untuk perusahaan dengan saiz tertentu, perniagaan selalunya melibatkan ringkasan data masa nyata dan fleksibel, yang tidak sesuai untuk jenis ini perniagaan Gunakan penyelesaian pengiraan terlebih dahulu untuk menyelesaikan masalah Walaupun anda boleh menulis perniagaan menggunakan penyelesaian pengiraan dan ringkasan terlebih dahulu, apabila bilangan data ringkasan meningkat, langkah terakhir untuk mengumpul data ringkasan akan beransur-ansur menjadi. sangat lambat. NoSQL berasaskan lajur adalah hasil daripada senario ini Ia adalah salah satu teknologi yang paling mewakili dalam era data besar yang paling biasa ialah HBase, tetapi aplikasi HBase sangat berat dan sering memerlukan set lengkap Ekosistem Hadoop untuk dijalankan Syarikat pengarang Alibaba Cloud's AnalyticDB digunakan, perisian penyimpanan lajur yang serasi dengan pernyataan pertanyaan MySql. Keupayaan pertanyaan kuat perisian storan lajur ringkasan adalah mencukupi untuk menyokong pelbagai perkhidmatan ringkasan data masa nyata dan fleksibel.

Kes

Mengambil 2021 sebagai nod masa, kebanyakan sistem bermula dengan pelan berikut pada peringkat awal Seterusnya, saya akan menggunakan kes ini Buat beberapa pelarasan perlahan-lahan.

Faedah yang dibawa oleh peningkatan perkakasan adalah lebih rendah seiring dengan berlalunya masa. Ini adalah penyelesaian pengoptimuman terpantas apabila masa dan kakitangan sempit. Faedah yang dibawa oleh pengoptimuman perisian adalah lebih tinggi pada masa hadapan, tetapi tahap kakitangan teknikal yang diperlukan juga lebih tinggi pada masa hadapan Apabila masa dan kakitangan mengizinkan, ia adalah penyelesaian pengoptimuman yang paling kos efektif. Pengoptimuman perkakasan dan perisian tidak saling eksklusif Apabila diperlukan, kedua-duanya boleh menghampiri had atas prestasi MYSQL pada masa yang sama.

Pengoptimuman Keras - Keupayaan Tunai

• Fasa 1

  • Penambahbaikan Untuk I/O cakera, cuba gunakan cakera SSD (peningkatan kualiti)
  • Tingkatkan memori dan ruang cache pertanyaan
  • Tingkatkan bilangan teras CPU dan tingkatkan urutan pelaksanaan

• Fasa 2

  • Ganti mysql binaan sendiri dengan penyedia perkhidmatan mysql service
  • Dayakan fungsi pemisahan baca dan tulis terbina dalam

• Fasa 3

  • Perkhidmatan mysql penyedia perkhidmatan digantikan dengan pangkalan data teragih asli awan
  • Dayakan fungsi pemisahan baca dan tulis terbina dalam
  • Dayakan sub-jadual terbina dalam fungsi

Pengoptimuman Lembut - Pertanyaan - OLTP

OLTP digunakan terutamanya untuk merekodkan kejadian jenis acara perniagaan tertentu, seperti sebagai tingkah laku pengguna. Apabila tingkah laku berlaku, sistem akan merekodkan Bila dan di mana pengguna melakukan sesuatu, baris (atau berbilang baris) data akan dikemas kini dalam pangkalan data dalam bentuk penambahan, pemadaman dan pengubahsuaian prestasi masa nyata yang tinggi, kestabilan yang kukuh dan memastikan data dikemas kini dengan jayanya tepat pada masanya, semua sistem perniagaan biasa adalah milik OLTP, dan pangkalan data yang digunakan ialah pangkalan data transaksi, seperti MySlq, Oracle, dsb. Untuk OLTP, meningkatkan kelajuan pertanyaan dan kestabilan perkhidmatan adalah teras pengoptimuman

• Pertanyaan perlahan
  • Temui SQL yang cekap dengan masalah kecekapan melalui log pertanyaan perlahan
• Arah penyelesaian masalah SQL
  • Ada masalah dengan reka bentuk indeks
  • Terdapat masalah dengan pernyataan SQL
  • Indeks yang salah dipilih dalam pangkalan data
  • Satu jadual adalah besar
• Terangkan analisis khusus
  • Lihat kadar perbandingan pelaksanaan sql
  • Semak situasi hit indeks (titik utama)
• pengoptimum mysql
  • Apabila pengoptimum memilih indeks, ia akan merujuk kepada indeks Kardinaliti
  • Kardinaliti dikekalkan dan dianggarkan secara automatik oleh MySQL dan mungkin tidak tepat
  • Jika indeks tidak terkena atau indeks yang salah digunakan, terdapat masalah dengan langkah pengoptimum
  • analisis boleh mengira semula maklumat indeks dan mengira semula asas
• Indeks daya
  • Kata kunci force boleh memaksa penggunaan indeks dan secara paksa menentukan indeks pada kod perniagaan
• Indeks yang dilindungi - indeks hit yang paling ideal
  • Indeks yang dilindungi bermaksud bahawa indeks yang sama (unik, biasa, indeks bersama, dll.) digunakan daripada pelaksanaan pernyataan pertanyaan kepada hasil yang dikembalikan
  • Indeks penutup boleh mengurangkan bilangan pertanyaan jadual pulangan
  • Jika pertanyaan data menggunakan lebih daripada satu indeks, ia bukan indeks penutup
  • Anda boleh mengoptimumkan pernyataan SQL atau mengoptimumkan indeks bersama Gunakan indeks penutup
• count() fungsi
  • count (medan bukan indeks) - indeks penutup tidak boleh digunakan, teori yang paling perlahan ialah
  • count(medan indeks) - boleh menulis ganti indeks, tetapi masih perlu menentukan sama ada medan adalah batal setiap kali
  • count (kunci utama) - sama seperti di atas
  • count(1) - hanya mengimbas pepohon indeks, tiada proses menghuraikan baris data , secara teorinya lebih pantas, tetapi ia masih akan menentukan sama ada 1 adalah null
  • count(*) - MySQL telah mengoptimumkan fungsi count(*) secara khusus untuk mengembalikan terus bilangan data dalam pepohon indeks, optimum
• PESANAN OLEH
  • Minimumkan pengisihan tambahan, nyatakan di mana keadaan
  • di mana pernyataan dan ORDER BY kombinasi pernyataan memenuhi awalan paling kiri
  • untuk yang paling cekap - Liputan indeks ( lebih sedikit senario, peluang rendah untuk menemui)
    • Liputan indeks boleh melangkau penjanaan set hasil perantaraan dan secara langsung mengeluarkan hasil pertanyaan
    • Medan PESANAN perlu diindeks dan konsisten dengan keadaan WHERE dan output Kandungannya adalah semua dalam indeks yang sama
• Pertanyaan halaman
  • Mula-mula cari cara untuk menutup indeks
  • Ketahui perkara yang anda perlukan pertama Id data dikembalikan ke jadual untuk mendapatkan set keputusan akhir
• Tekan turun indeks
  • KUNCI store_id_guide_id (store_id,guide_id) MENGGUNAKAN BTREE
  • pilih * dari jadual di mana store_id dalam (1,2) dan guide_id = 3;
  • Sebelum MySQL5.6, anda perlu menggunakan indeks untuk membuat pertanyaan store_id dalam (1,2 ), dan kemudian tambah semua jadual untuk mengesahkan film_id = 3
  • Selepas MySQL 5.6, jika indeks boleh dibaca, terus gunakan penapisan indeks
• Imbasan indeks longgar
  • KUNCI store_id_guide_id (store_id,guide_id) MENGGUNAKAN BTREE
  • pilih film_id dari jadual di mana guide_id = 3
  • Ciri baharu MySQL8.0
  • Imbasan indeks yang longgar boleh memecahkan "prinsip kiri" , untuk menyelesaikan masalah kehilangan abang terkemuka
  • Kecekapan lebih rendah daripada indeks sendi
• Operasi fungsi
  • Jika anda melakukan operasi fungsi pada medan indeks, pengoptimum akan menyerahkan indeks
  • Situasi ini mungkin termasuk: fungsi masa, menukar rentetan kepada nombor, penukaran pengekodan aksara
  • Optimumkan penggunaan logik sisi pelayan untuk menggantikan fungsi mysql
• Saiz satu jadual terlalu besar
  • Naik taraf perisian mysql yang berbeza boleh membawa saiz yang berbeza satu jadual berdasarkan pengalaman semasa saya, versi kelompok polardb Alibaba Cloud bertanya apabila jadual tunggal adalah 200 juta Tiada masalah dengan mencapai indeks (keutamaan tinggi)
  • Penyelesaian data - Contohnya, data saluran paip. boleh diselesaikan mengikut masa tertentu untuk mendapatkan nilai terkini, dan saluran paip yang diselesaikan dipindahkan ke jadual sandaran (keutamaan sederhana)
  • Pemisahan data panas dan sejuk - data yang tidak dapat diselesaikan dibezakan mengikut kekerapan pertanyaan, data frekuensi rendah dipindahkan ke jadual lain untuk pertanyaan, dan pintu masuk pertanyaan dibezakan daripada perspektif perniagaan (keutamaan sederhana)
  • Pecahan jadual pangkalan data teragih - Dayakan pemisahan jadual fungsi pangkalan data yang diedarkan dengan pesanan Komponen pangkalan data yang diedarkan mengurus sisipan dan pertanyaan selepas membahagikan jadual (keutamaan sederhana)
  • Kod untuk melaksanakan pemisahan jadual - tekan Peraturan tertentu membahagikan satu jadual kepada beberapa jadual rangka kerja ORM PHP dan GO, pengubahsuaian tertentu perlu dibuat pada rangka kerja ORM selepas pemisahan ORM dalam JAVA adalah disyorkan untuk mempertimbangkannya pada peringkat awal projek , semakin sukar keutamaan)

Pengoptimuman lembut - tulis kemas kini padam

• Kunci

  • Mengikut butiran, kunci MySQL boleh dibahagikan kepada kunci global, kunci peringkat meja dan kunci baris

  • Kunci global

    • Auto google/baidu

  • Kunci peringkat meja dibahagikan kepada kunci meja (kunci data) dan kunci metadata

    • Kunci meja
      • self google/baidu
    • kunci metadata
      • self google/baidu

  • Kunci baris akan mengunci baris data, dibahagikan kepada kunci kongsi dan kunci eksklusif

    • Google/baidu sendiri

• Menyelesaikan kebuntuan

  • Konfigurasi parameter
    • Laraskan parameter innodb_lock_wait_timeout
      • Lalai ialah 50 saat, iaitu, jika kunci tidak diperoleh selepas menunggu selama 50 saat, penyata semasa akan melaporkan ralat
      • Jika masa menunggu tamat tempoh yang lama, anda boleh memendekkan parameter ini dengan sewajarnya
    • Pengesanan jalan buntu aktif: innodb_deadlock_detect
      • Kembali urus niaga yang kurang mahal apabila kebuntuan ditemui
      • Didayakan secara lalai
  • Jangan buka transaksi jika tidak perlu
  • Cuba letak pertanyaan di luar transaksi untuk mengurangkan bilangan baris terkunci
  • Elakkan Masa transaksi terlalu lama, jangan cetuskan permintaan http dalam transaksi
  • Semak status transaksi secara aktif

    show  processlist;SELECT * FROM information_schema.INNODB_TRX; //长事务SELECT * FROM information_schema.INNODB_LOCKs; //查看锁SELECT * FROM information_schema.INNODB_LOCK_waits; //查看阻塞事务

Perniagaan carian

• Bilangan baris carian kurang daripada 100,000 - mysql tahan lasak
  • Tingkatkan cpu, io dan perkakasan memori mysql
• Bilangan baris carian adalah lebih daripada 100,000 - Memperkenalkan Elasticsearch

Indeks terbalik Elasticsearch, yang sesuai untuk carian teks penuh, tetapi struktur data mempunyai fleksibiliti yang lemah.

• Penyegerakan data
  • Apabila kod perniagaan menukar data, ia disegerakkan ke Elasticsearch pada masa yang sama
  • Langganan canel ke log mysql mencetuskan penyegerakan
• Elasticsearch-index
  • terdiri daripada senarai dokumen dengan medan yang sama - serupa dengan jadual mysql
  • Setelah jenis medan ditetapkan, pengubahsuaian adalah dilarang dan baharu medan dibenarkan
  • Spesifik Kaedah ini adalah google/baidu sendiri
• Elasticsearch-Document
  • Dokumen data pengguna yang disimpan dalam es - analog dengan baris mysql
  • terdiri daripada metadata dan komposisi Objek Json
  • Perincian Metadata dan Objek Json tersedia di google/baidu
• Elasticsearch-Word Segmenter
  • oleh google/baidu
• Elasticsearch-Inverted Index (Key Points)
  • Cari google/baidu
• Analisis Elasticsearch-Agregation
  • Cari google/ baidu

Perniagaan statistik-OLAP

OLAP digunakan untuk analisis membuat keputusan data relatif kepada senario pemprosesan transaksi OLTP Ia adalah idea gudang data luar talian yang digunakan dalam analisis data besar, bukan susunan teknologi tertentu Jika penyelesaian anda boleh merangkumi idea analisis dan pemprosesan penyelesaiannya ialah OLAP.

Pembinaan gudang data awal terutamanya merujuk kepada pemodelan pangkalan data perniagaan perusahaan seperti ERP, CRM, SCM dan data lain mengikut keperluan analisis membuat keputusan dan meringkaskannya ke dalam enjin gudang data terutamanya untuk tujuan pelaporan Ia adalah untuk menyokong pembuatan keputusan kakitangan pengurusan dan perniagaan (keputusan strategik jangka sederhana dan panjang). Apabila teknologi IT bergerak ke arah Internet dan mobiliti, sumber data menjadi lebih banyak dan lebih banyak Data tidak berstruktur muncul berdasarkan pangkalan data perniagaan asal, seperti log tapak web, data peranti IoT, data terbenam APP, dll. Jumlah data ini. Ia adalah beberapa susunan magnitud yang lebih besar daripada data berstruktur sebelumnya.

Tidak kira bagaimana perniagaan yang dihadapi oleh OLAP berubah, ia tidak dapat dipisahkan daripada langkah berikut: Tentukan kawasan analisis -> Segerakkan data perniagaan ke pustaka pengkomputeran -> gudang data - >Terdedah kepada luar

Pangkalan data sumber pengiraan digunakan khas untuk pembersihan data, dan tujuannya adalah untuk mengelak daripada menjejaskan prestasi pangkalan data perniagaan semasa pembersihan data. Dengan membersihkan data dalam pangkalan data sumber pengiraan mengikut perniagaan dan dimensi, kebolehgunaan dan kebolehgunaan semula data meningkat, dan data terperinci masa nyata akhir diperoleh, yang kemudiannya dipindahkan ke gudang data, dan gudang data menyediakan data analisis keputusan akhir.

Pelan DEMO

Pelan pengeluaran

Fungsi yang sama tersedia untuk setiap pautan perisian Jika perisian digantikan dengan penyelesaian pelaksanaan perisian yang paling yakin pasukan, maka penyelesaiannya ialah OLAP.

Ringkasan

Pengoptimuman mestilah sederhana, dengan pengumpulan keupayaan langkah demi langkah, berbilang pusingan lelaran dan tidak boleh dicapai dalam sekelip mata. Jalankan berbilang pusingan lelaran berdasarkan asas anda sendiri, senario perniagaan dan jangkaan pembangunan masa hadapan.

Prinsip lelaran adalah untuk terlebih dahulu meningkatkan kecekapan perkhidmatan perisian tunggal melalui pengoptimuman lembut dan pengoptimuman keras Apabila kos pengoptimuman adalah lebih rendah daripada faedah, berdasarkan jangkaan pembangunan masa hadapan, rujuk kepada penyelesaian matang pada pasarkan dan ikuti penyelesaiannya. Perkenalkan perisian baharu seperti yang diperlukan untuk inovasi gabungan, dan elakkan penyalinan buta Hanya dengan menyepadukan secara organik anda boleh mencapai kesan 1 1>2, 2 1>3. Ulangi proses ini apabila perisian yang dirujuk menghadapi masalah .

Terima kasih kerana membaca ini di atas adalah semua kandungan artikel dan penyelesaian yang dicadangkan dalam kandungan tidak semestinya penyelesaian yang optimum pendapat yang berbeza, anda dialu-alukan untuk membincangkannya.                                                                                                                                                                                                                                                    

Atas ialah kandungan terperinci Perkongsian yang sangat disukai: Idea pengoptimuman MySQL yang selaras dengan pengeluaran. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!