bitsCN.com
网上有很多的文章教怎么配置MySQL服务器,但考虑到服务器硬件配置的不同,具体应用的差别,那些文章的做法只能作为初步设置参考,我们需要根据自己的情况进行配置优化,好的做法是MySQL服务器稳定运行了一段时间后运行,根据服务器的”状态”进行优化。
mysql> show global status;
可以列出MySQL服务器运行各种状态值,另外,查询MySQL服务器配置信息语句:
mysql> show variables;
一、慢查询
mysql> show variables like %slow%;
+------------------+-------+
| Variable_name | Value |
+------------------+-------+
| log_slow_queries | ON |
| slow_launch_time | 2 |
+------------------+-------+
mysql> show global status like %slow%;
+---------------------+-------+
| Variable_name | Value |
+---------------------+-------+
| Slow_launch_threads | 0 |
| Slow_queries | 4148 |
+---------------------+-------+
配置中打开了记录慢查询,执行时间超过2秒的即为慢查询,系统显示有4148个慢查询,你可以分析慢查询日志,找出有问题的SQL语句,慢查询时间不宜设置过长,否则意义不大,最好在5秒以内,如果你需要微秒级别的慢查询,可以考虑给MySQL打补丁:http://www.percona.com/docs/wiki/release:start,记得找对应的版本。
打开慢查询日志可能会对系统性能有一点点影响,如果你的MySQL是主-从结构,可以考虑打开其中一台从服务器的慢查询日志,这样既可以监控慢查询,对系统性能影响又小。
二、连接数
经常会遇见”MySQL: ERROR 1040: Too many connections”的情况,一种是访问量确实很高,MySQL服务器抗不住,这个时候就要考虑增加从服务器分散读压力,另外一种情况是MySQL配置文件中max_connections值过小:
mysql> show variables like max_connections;
+-----------------+-------+
| Variable_name | Value |
+-----------------+-------+
| max_connections | 256 |
+-----------------+-------+
这台MySQL服务器最大连接数是256,然后查询一下服务器响应的最大连接数:
mysql> show global status like Max_used_connections;
+----------------------+-------+
| Variable_name | Value |
+----------------------+-------+
| Max_used_connections | 245 |
+----------------------+-------+
MySQL服务器过去的最大连接数是245,没有达到服务器连接数上限256,应该没有出现1040错误,比较理想的设置是:
Max_used_connections / max_connections * 100% ≈ 85%
最大连接数占上限连接数的85%左右,如果发现比例在10%以下,MySQL服务器连接数上限设置的过高了。
三、Key_buffer_size
key_buffer_size是对MyISAM表性能影响最大的一个参数,下面一台以MyISAM为主要存储引擎服务器的配置:
mysql> show variables like key_buffer_size;
+-----------------+------------+
| Variable_name | Value |
+-----------------+------------+
| key_buffer_size | 536870912 |
+-----------------+------------+
分配了512MB内存给key_buffer_size,我们再看一下key_buffer_size的使用情况:
mysql> show global status like key_read%;
+------------------------+-------------+
| Variable_name | Value |
+------------------------+-------------+
| Key_read_requests | 27813678764 |
| Key_reads | 6798830 |
+------------------------+-------------+
一共有27813678764个索引读取请求,有6798830个请求在内存中没有找到直接从硬盘读取索引,计算索引未命中缓存的概率:
key_cache_miss_rate = Key_reads / Key_read_requests * 100%
比如上面的数据,key_cache_miss_rate为0.0244%,4000个索引读取请求才有一个直接读硬盘,已经很BT了,key_cache_miss_rate在0.1%以下都很好(每1000个请求有一个直接读硬盘),如果key_cache_miss_rate在0.01%以下的话,key_buffer_size分配的过多,可以适当减少。
MySQL服务器还提供了key_blocks_*参数:
mysql> show global status like key_blocks_u%;
+------------------------+-------------+
| Variable_name | Value |
+------------------------+-------------+
| Key_blocks_unused | 0 |
| Key_blocks_used | 413543 |
+------------------------+-------------+
Key_blocks_unused表示未使用的缓存簇(blocks)数,Key_blocks_used表示曾经用到的最大的blocks数,比如这台服务器,所有的缓存都用到了,要么增加key_buffer_size,要么就是过渡索引了,把缓存占满了。比较理想的设置:
Key_blocks_used / (Key_blocks_unused + Key_blocks_used) * 100% ≈ 80%
四、临时表
mysql> show global status like created_tmp%;
+-------------------------+---------+
| Variable_name | Value |
+-------------------------+---------+
| Created_tmp_disk_tables | 21197 |
| Created_tmp_files | 58 |
| Created_tmp_tables | 1771587 |
+-------------------------+---------+
每次创建临时表,Created_tmp_tables增加,如果是在磁盘上创建临时表,Created_tmp_disk_tables也增加,Created_tmp_files表示MySQL服务创建的临时文件文件数,比较理想的配置是:
Created_tmp_disk_tables / Created_tmp_tables * 100% 比如上面的服务器Created_tmp_disk_tables / Created_tmp_tables * 100% = 1.20%,应该相当好了。我们再看一下MySQL服务器对临时表的配置:
mysql> show variables where Variable_name in (tmp_table_size, max_heap_table_size);
+---------------------+-----------+
| Variable_name | Value |
+---------------------+-----------+
| max_heap_table_size | 268435456 |
| tmp_table_size | 536870912 |
+---------------------+-----------+
只有256MB以下的临时表才能全部放内存,超过的就会用到硬盘临时表。
五、Open Table情况
mysql> show global status like open%tables%;
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Open_tables | 919 |
| Opened_tables | 1951 |
+---------------+-------+
Open_tables表示打开表的数量,Opened_tables表示打开过的表数量,如果Opened_tables数量过大,说明配置中table_cache(5.1.3之后这个值叫做table_open_cache)值可能太小,我们查询一下服务器table_cache值:
mysql> show variables like table_cache;
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| table_cache | 2048 |
+---------------+-------+
比较合适的值为:
Open_tables / Opened_tables * 100% >= 85%
Open_tables / table_cache * 100% bitsCN.com

InnoDB menggunakan redolog dan undologs untuk memastikan konsistensi dan kebolehpercayaan data. 1. Pengubahsuaian halaman data rekod untuk memastikan pemulihan kemalangan dan kegigihan transaksi. 2.UNDOLOGS merekodkan nilai data asal dan menyokong penggantian transaksi dan MVCC.

Metrik utama untuk menjelaskan arahan termasuk jenis, kunci, baris, dan tambahan. 1) Jenis mencerminkan jenis akses pertanyaan. Semakin tinggi nilai, semakin tinggi kecekapan, seperti const adalah lebih baik daripada semua. 2) Kunci memaparkan indeks yang digunakan, dan null menunjukkan tiada indeks. 3) Baris menganggarkan bilangan baris yang diimbas, yang mempengaruhi prestasi pertanyaan. 4) Tambahan memberikan maklumat tambahan, seperti menggunakanFilesort meminta bahawa ia perlu dioptimumkan.

MenggunakanTemary menunjukkan bahawa keperluan untuk membuat jadual sementara dalam pertanyaan MySQL, yang biasanya dijumpai di Orderby menggunakan lajur yang berbeza, GroupBy, atau tidak diindeks. Anda boleh mengelakkan berlakunya indeks dan menulis semula pertanyaan dan meningkatkan prestasi pertanyaan. Khususnya, apabila menggunakan pembelian muncul dalam menjelaskan output, ini bermakna MySQL perlu membuat jadual sementara untuk mengendalikan pertanyaan. Ini biasanya berlaku apabila: 1) deduplikasi atau pengelompokan apabila menggunakan yang berbeza atau kumpulan; 2) Susun apabila Orderby mengandungi lajur bukan indeks; 3) Gunakan subquery kompleks atau menyertai operasi. Kaedah Pengoptimuman termasuk: 1) Orderby dan GroupB

MySQL/InnoDB menyokong empat tahap pengasingan transaksi: ReadUncommitted, ReadCommitted, RepeatableRead dan Serializable. 1. ReadoMuncommitted membolehkan membaca data yang tidak komited, yang boleh menyebabkan bacaan kotor. 2. 3.RepeatableRead adalah tahap lalai, mengelakkan bacaan kotor dan bacaan yang tidak boleh diulang, tetapi bacaan hantu mungkin berlaku. 4. Serializable mengelakkan semua masalah konkurensi tetapi mengurangkan kesesuaian. Memilih tahap pengasingan yang sesuai memerlukan keseimbangan data konsistensi dan keperluan prestasi.

MySQL sesuai untuk aplikasi web dan sistem pengurusan kandungan dan popular untuk sumber terbuka, prestasi tinggi dan kemudahan penggunaan. 1) Berbanding dengan PostgreSQL, MySQL melakukan lebih baik dalam pertanyaan mudah dan operasi membaca serentak yang tinggi. 2) Berbanding dengan Oracle, MySQL lebih popular di kalangan perusahaan kecil dan sederhana kerana sumber terbuka dan kos rendah. 3) Berbanding dengan Microsoft SQL Server, MySQL lebih sesuai untuk aplikasi silang platform. 4) Tidak seperti MongoDB, MySQL lebih sesuai untuk data berstruktur dan pemprosesan transaksi.

Cardinality Indeks MySQL mempunyai kesan yang signifikan terhadap prestasi pertanyaan: 1. Indeks kardinaliti yang tinggi dapat lebih berkesan menyempitkan julat data dan meningkatkan kecekapan pertanyaan; 2. Indeks kardinaliti yang rendah boleh membawa kepada pengimbasan jadual penuh dan mengurangkan prestasi pertanyaan; 3. Dalam indeks bersama, urutan kardinaliti yang tinggi harus diletakkan di depan untuk mengoptimumkan pertanyaan.

Laluan pembelajaran MySQL termasuk pengetahuan asas, konsep teras, contoh penggunaan, dan teknik pengoptimuman. 1) Memahami konsep asas seperti jadual, baris, lajur, dan pertanyaan SQL. 2) Ketahui definisi, prinsip kerja dan kelebihan MySQL. 3) menguasai operasi CRUD asas dan penggunaan lanjutan, seperti indeks dan prosedur yang disimpan. 4) Biasa dengan debugging kesilapan biasa dan cadangan pengoptimuman prestasi, seperti penggunaan rasional indeks dan pertanyaan pengoptimuman. Melalui langkah -langkah ini, anda akan memahami sepenuhnya penggunaan dan pengoptimuman MySQL.

Aplikasi dunia nyata MySQL termasuk reka bentuk pangkalan data asas dan pengoptimuman pertanyaan kompleks. 1) Penggunaan Asas: Digunakan untuk menyimpan dan mengurus data pengguna, seperti memasukkan, menanyakan, mengemas kini dan memadam maklumat pengguna. 2) Penggunaan lanjutan: Mengendalikan logik perniagaan yang kompleks, seperti perintah dan pengurusan inventori platform e-dagang. 3) Pengoptimuman Prestasi: Meningkatkan prestasi dengan menggunakan indeks, jadual partisi dan cache pertanyaan.


Alat AI Hot

Undresser.AI Undress
Apl berkuasa AI untuk mencipta foto bogel yang realistik

AI Clothes Remover
Alat AI dalam talian untuk mengeluarkan pakaian daripada foto.

Undress AI Tool
Gambar buka pakaian secara percuma

Clothoff.io
Penyingkiran pakaian AI

AI Hentai Generator
Menjana ai hentai secara percuma.

Artikel Panas

Alat panas

Dreamweaver CS6
Alat pembangunan web visual

Pelayar Peperiksaan Selamat
Pelayar Peperiksaan Selamat ialah persekitaran pelayar selamat untuk mengambil peperiksaan dalam talian dengan selamat. Perisian ini menukar mana-mana komputer menjadi stesen kerja yang selamat. Ia mengawal akses kepada mana-mana utiliti dan menghalang pelajar daripada menggunakan sumber yang tidak dibenarkan.

SublimeText3 Linux versi baharu
SublimeText3 Linux versi terkini

MantisBT
Mantis ialah alat pengesan kecacatan berasaskan web yang mudah digunakan yang direka untuk membantu dalam pengesanan kecacatan produk. Ia memerlukan PHP, MySQL dan pelayan web. Lihat perkhidmatan demo dan pengehosan kami.

Versi Mac WebStorm
Alat pembangunan JavaScript yang berguna