bitsCN.com
MySQL SQL分析 - 参数化查询vs query cache功能
query cache, mysql 5 开始附带的一个功能, 与引擎无关, 只与数据查询语法相关。
测试描述: 当前使用中是 MySQL-5.6.14 Linux RHEL6 64 位系统产生环境, 使用 INNODB 引擎, 分配 innodb 2g 内存空间
[root@TiYanPlat ~]# uname -aLinux TiYanPlat 2.6.32-358.el6.x86_64 #1 SMP Tue Jan 29 11:47:41 EST 2013 x86_64 x86_64x86_64 GNU/Linuxmysql> select version();+-----------+| version() |+-----------+| 5.6.14 |+-----------+1 row in set (0.00 sec)mysql> show variables like 'innodb_buffer_pool_size';+-------------------------+------------+| Variable_name | Value |+-------------------------+------------+| innodb_buffer_pool_size | 2147483648 |+-------------------------+------------+1 row in set (0.01 sec)
Query cache 功能:
利用 qeury_cache_size 定义内存大小, 内存用于把用户 SQL 放入内存中, 包括 SQL 语句, 包括SQL 语句执行的结果
假如下一次查询时使用相同的 SQL 语句, 则直接从内存中获得结果, 不再进行 SQL 分析, 不在进行磁盘 I/O 读数据。加速数据查询返回结果。
实现目标,开启 QCACHE 功能, 如 my.cnf 定义
query-cache-size=16777216
query-cache-type=ON
查询数据库中是否使用当前功能
mysql> show status like '%qcache%';+-------------------------+----------+| Variable_name | Value |+-------------------------+----------+| Qcache_free_blocks | 440 || Qcache_free_memory | 12306960 || Qcache_hits | 13176 || Qcache_inserts | 29777 || Qcache_lowmem_prunes | 0 || Qcache_not_cached | 45862 || Qcache_queries_in_cache | 2098 || Qcache_total_blocks | 4701 |+-------------------------+----------+8 rows in set (0.02 sec)
参数返回结果不再一一详细描述, 自行参考官方文档, 从上返回结果可以看到,使用中的数据库 SQL 命中率 (Qcache_hits) 并不理想,原因与业务有关。
SQL 分析一, 使用了 QUERY CACHE 的好处
原理, 利用 EXPLAIN 分析当前 SQL 执行计划, 利用 PROFILE 功能分析当前 SQL 执行计划,过程
执行下面语句进行分析
mysql> explain select tbcrbtnumb0_.id as id41_, tbcrbtnumb0_.business_ring_id as business2_41_, tbcrbtnumb0_.application_no as applicat3_41_, tbcrbtnumb0_.mobile as mobile41_ from tb_crbt_numbers_load tbcrbtnumb0_ where 1=1 and tbcrbtnumb0_.business_ring_id=11024;+----+-------------+--------------+------+---------------+------+---------+------+--------+-------------+| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |+----+-------------+--------------+------+---------------+------+---------+------+--------+-------------+| 1 | SIMPLE | tbcrbtnumb0_ | ALL | NULL | NULL | NULL | NULL |180182 | Using where |+----+-------------+--------------+------+---------------+------+---------+------+--------+-------------+1 row in set (0.00 sec)当前语法执行的是全表扫描,另外,需要从 180182 行中扫描相关结果SQL 分析二, 判断第一次执行该 SQL 时候的执行过程mysql> set profiling=1;mysql> select tbcrbtnumb0_.id as id41_, tbcrbtnumb0_.business_ring_id as business2_41_, tbcrbtnumb0_.application_no as applicat3_41_, tbcrbtnumb0_.mobile as mobile41_ from tb_crbt_numbers_load tbcrbtnumb0_ where 1=1 and tbcrbtnumb0_.business_ring_id=11024;+-------+---------------+---------------+-------------+| id41_ | business2_41_ | applicat3_41_ | mobile41_ |+-------+---------------+---------------+-------------+| 30838 | 11024 | TH20121127229 | 02038688592 |+-------+---------------+---------------+-------------+1 row in set (0.30 sec)mysql> show profile; +--------------------------------+----------+| Status | Duration |+--------------------------------+----------+| starting | 0.000191 || Waiting for query cache lock | 0.000023 || init | 0.000090 || checking query cache for query | 0.000499 || checking permissions | 0.000030 || Opening tables | 0.000131 || init | 0.000277 || System lock | 0.000042 || Waiting for query cache lock | 0.000005 || System lock | 0.000443 || optimizing | 0.000364 || statistics | 0.000107 || preparing | 0.000059 || executing | 0.000019 || Sending data | 0.290067 || end | 0.000483 || query end | 0.000169 || closing tables | 0.000158 || freeing items | 0.000252 || Waiting for query cache lock | 0.000063 || freeing items | 0.000305 || Waiting for query cache lock | 0.000015 || freeing items | 0.000095 || storing result in query cache | 0.000145 || cleaning up | 0.000330 |+--------------------------------+----------+25 rows in set, 1 warning (0.01 sec)
从上面看出, 第一次执行该 SQL, MySQL 需要对 SQL 进行锁缓存,初始化,从缓存中查询是否具备之前缓存过的 SQL,检查用户权限, 表权限,打开表,锁定内存,定制执行计划,执行语句,把数据从磁盘中放入内存中操作,关闭表,锁定数据, 缓存数据等操作, 工作原理与 ORACLE 类似
按照 QUERY CACHE 原则, 假如 SQL 语句改变 (tbcrbtnumb0_.business_ring_id=11024) 替换该变量值, 那么该 SQL 会被看作为一个新的 SQL, 这个时候, MySQL 将会对整个 SQL 做一次全新的操作, 如上(黄线标注描述)
分析 SQL 三
mysql> select tbcrbtnumb0_.id as id41_, tbcrbtnumb0_.business_ring_id as business2_41_, tbcrbtnumb0_.application_no as applicat3_41_, tbcrbtnumb0_.mobile as mobile41_ from tb_crbt_numbers_load tbcrbtnumb0_ where 1=1 and tbcrbtnumb0_.business_ring_id=11021;+-------+---------------+---------------+-------------+| id41_ | business2_41_ | applicat3_41_ | mobile41_ |+-------+---------------+---------------+-------------+| 30835 | 11021 | TH20121127259 | 02038688592 |+-------+---------------+---------------+-------------+1 row in set (0.34 sec)mysql> show profile;+--------------------------------+----------+| Status | Duration |+--------------------------------+----------+| starting | 0.000795 || Waiting for query cache lock | 0.000077 || init | 0.000045 || checking query cache for query | 0.000337 || checking permissions | 0.000040 || Opening tables | 0.000113 || init | 0.000488 || System lock | 0.000050 || Waiting for query cache lock | 0.000030 || System lock | 0.000289 || optimizing | 0.000512 || statistics | 0.000278 || preparing | 0.000078 || executing | 0.000028 || Sending data | 0.322662 || end | 0.004777 || query end | 0.001703 || closing tables | 0.000526 || freeing items | 0.000874 || Waiting for query cache lock | 0.000311 || freeing items | 0.001809 || Waiting for query cache lock | 0.000105 || freeing items | 0.000184 || storing result in query cache | 0.000966 || cleaning up | 0.000678 |+--------------------------------+----------+25 rows in set, 1 warning (0.00 sec)
上 SQL二,三结果可以看到, 当 WHERE 条件改变, MySQL 会把这两个 SQL 识别为一个新的 SQL, 需要重新操作。
SQL 分析四, 假如我们重新执行 SQL 三操作,看看结果如何?(注意,这个时候 QUERY CACHE 真正发挥作用)
mysql> select tbcrbtnumb0_.id as id41_, tbcrbtnumb0_.business_ring_id as business2_41_, tbcrbtnumb0_.application_no as applicat3_41_, tbcrbtnumb0_.mobile as mobile41_ from tb_crbt_numbers_load tbcrbtnumb0_ where 1=1 and tbcrbtnumb0_.business_ring_id=11021;+-------+---------------+---------------+-------------+| id41_ | business2_41_ | applicat3_41_ | mobile41_ |+-------+---------------+---------------+-------------+| 30835 | 11021 | TH20121127259 | 02038688592 |+-------+---------------+---------------+-------------+1 row in set (0.00 sec)mysql> show profile; +--------------------------------+----------+| Status | Duration |+--------------------------------+----------+| starting | 0.001367 || Waiting for query cache lock | 0.000071 || init | 0.000027 || checking query cache for query | 0.000163 || checking privileges on cached | 0.000129 || checking permissions | 0.000386 || sending cached result to clien | 0.000164|| cleaning up | 0.000079 |+--------------------------------+----------+8 rows in set, 1 warning (0.01 sec)
参考 SQL 分析三,四,数据查询需要使用的时间(绿色标注部分)很明显, SQL 分析四返回速度块了很多,另外,从系统返回的 SQL 分析看出来,系统直接从缓存中返回数据给客户, 没有重复进行 SQL 分析及磁盘 I/O 操作。(蓝色标注部分) 因此, QEURY CACHE 明显加速了 SQL 返回结果。
但必须注意,只有两个 SQL 相同的情况下,才能够获得 QUERY CACHE 的优点。
参数化查询
参数化查询能够在一定情况下避免了 SQL 注入, 而 ORACLE 也比较推荐使用参数化查询, ORACLE 每次执行 SQL (无论 SQL 是否语法一致)都存在 SQL 分析,
假如SQL语法不一样,则进行硬解析,需要重新定制执行计划
假如SQL语法不一致则进行软解析,避免重复定制执行计划,减少 CPU 消耗,增加 SQL 语句返回时间。
MySQL 官方文档中并没有提出到这点。
对 MySQL 进行参数化查询分析
SQL 参数化分析一
mysql> set @num=11204;mysql> select tbcrbtnumb0_.id as id41_, tbcrbtnumb0_.business_ring_id as business2_41_, tbcrbtnumb0_.application_no as applicat3_41_, tbcrbtnumb0_.mobile as mobile41_ from tb_crbt_numbers_load tbcrbtnumb0_ where 1=1 and tbcrbtnumb0_.business_ring_id=@num;+-------+---------------+---------------+-----------+| id41_ | business2_41_ | applicat3_41_ | mobile41_ |+-------+---------------+---------------+-----------+| 31051 | 11204 | 1222570 | 85237810 || 31052 | 11204 | 1222570 | 82685386 || 31053 | 11204 | 1222570 | 82783689 || 31054 | 11204 | 1222570 | 82685106 || 31055 | 11204 | 1222570 | 38880051 |+-------+---------------+---------------+-----------+5 rows in set (0.37 sec)mysql> show profile; +--------------------------------+----------+| Status | Duration |+--------------------------------+----------+| starting | 0.001858 || Waiting for query cache lock | 0.000089 || init | 0.000150 || checking query cache for query | 0.001143 || checking permissions | 0.000970 || Opening tables | 0.000544 || init | 0.000743 || System lock | 0.000170 || optimizing | 0.000332 || statistics | 0.000293 || preparing | 0.000134 || executing | 0.000057 || Sending data | 0.438626 || end | 0.000694 || query end | 0.000221 || closing tables | 0.000300 || freeing items | 0.000521 || cleaning up | 0.000360 |+--------------------------------+----------+18 rows in set, 1 warning (0.01 sec)
变量值不变情况下,重复执行该 SQL 语句
mysql> select tbcrbtnumb0_.id as id41_, tbcrbtnumb0_.business_ring_id as business2_41_, tbcrbtnumb0_.application_no as applicat3_41_, tbcrbtnumb0_.mobile as mobile41_ from tb_crbt_numbers_load tbcrbtnumb0_ where 1=1 and tbcrbtnumb0_.business_ring_id=@num;+-------+---------------+---------------+-----------+| id41_ | business2_41_ | applicat3_41_ | mobile41_ |+-------+---------------+---------------+-----------+| 31051 | 11204 | 1222570 | 85237810 || 31052 | 11204 | 1222570 | 82685386 || 31053 | 11204 | 1222570 | 82783689 || 31054 | 11204 | 1222570 | 82685106 || 31055 | 11204 | 1222570 | 38880051 |+-------+---------------+---------------+-----------+5 rows in set (0.34 sec)mysql> show profile; +--------------------------------+----------+| Status | Duration |+--------------------------------+----------+| starting | 0.001188 || Waiting for query cache lock | 0.000052 || init | 0.000030 || checking query cache for query | 0.001791 || checking permissions | 0.000172 || Opening tables | 0.000614 || init | 0.001346 || System lock | 0.000268 || optimizing | 0.000626 || statistics | 0.000674 || preparing | 0.000439 || executing | 0.000028 || Sending data | 0.327278 || end | 0.000649 || query end | 0.000217 || closing tables | 0.000408 || freeing items | 0.000692 || cleaning up | 0.000570 |+--------------------------------+----------+18 rows in set, 1 warning (0.01 sec)
分析结果
从数据返回时间上看来(蓝色标注), 使用参数化查询,并没有在时间返回上获得优势。
从SQL执行计划上看来(紫色标注), 相同 SQL 语句使用参数化查询,系统同样会重新定制执行计划,产生磁盘I/O, 并没有想 ORACLE 一样获得性能上的优化。
另外,参数化查询是不会在 query cache 内存块中取结果的。
可以看做每次使用参数化查询都会被认为是一个全新的 SQL 进行分析, (没有学习到 ORACLE 的精髓,比较失望)
注意,使用参数化查询时, 即时使用 SQL_cache 语法, 也无法使用 query cache 功能。
常见开发下有几种选择
1. 直接把 SQL 变量值提交至 MySQL API 执行,(可利用 QUERY CACHE 功能,有部分 SQL 能够进行数据加速)但可能会遇到 SQL 注入, 升级程序麻烦。
2. 利用 procudure, function 等功能先吧 SQL 进行打包然后再调用执行, 类似参数化查询, 无法获得 QUERY CACHE 功能, 令程序清晰, 程序升级,修改比较方便, 并且有效防止了 SQL 注入。
bitsCN.com

MySQL adalah sistem pengurusan pangkalan data relasi sumber terbuka, terutamanya digunakan untuk menyimpan dan mengambil data dengan cepat dan boleh dipercayai. Prinsip kerjanya termasuk permintaan pelanggan, resolusi pertanyaan, pelaksanaan pertanyaan dan hasil pulangan. Contoh penggunaan termasuk membuat jadual, memasukkan dan menanyakan data, dan ciri -ciri canggih seperti Operasi Join. Kesalahan umum melibatkan sintaks SQL, jenis data, dan keizinan, dan cadangan pengoptimuman termasuk penggunaan indeks, pertanyaan yang dioptimumkan, dan pembahagian jadual.

MySQL adalah sistem pengurusan pangkalan data sumber terbuka yang sesuai untuk penyimpanan data, pengurusan, pertanyaan dan keselamatan. 1. Ia menyokong pelbagai sistem operasi dan digunakan secara meluas dalam aplikasi web dan bidang lain. 2. Melalui seni bina pelanggan-pelayan dan enjin penyimpanan yang berbeza, MySQL memproses data dengan cekap. 3. Penggunaan asas termasuk membuat pangkalan data dan jadual, memasukkan, menanyakan dan mengemas kini data. 4. Penggunaan lanjutan melibatkan pertanyaan kompleks dan prosedur yang disimpan. 5. Kesilapan umum boleh disahpepijat melalui pernyataan yang dijelaskan. 6. Pengoptimuman Prestasi termasuk penggunaan indeks rasional dan pernyataan pertanyaan yang dioptimumkan.

MySQL dipilih untuk prestasi, kebolehpercayaan, kemudahan penggunaan, dan sokongan komuniti. 1.MYSQL Menyediakan fungsi penyimpanan dan pengambilan data yang cekap, menyokong pelbagai jenis data dan operasi pertanyaan lanjutan. 2. Mengamalkan seni bina pelanggan-pelayan dan enjin penyimpanan berganda untuk menyokong urus niaga dan pengoptimuman pertanyaan. 3. Mudah digunakan, menyokong pelbagai sistem operasi dan bahasa pengaturcaraan. 4. Mempunyai sokongan komuniti yang kuat dan menyediakan sumber dan penyelesaian yang kaya.

Mekanisme kunci InnoDB termasuk kunci bersama, kunci eksklusif, kunci niat, kunci rekod, kunci jurang dan kunci utama seterusnya. 1. Kunci dikongsi membolehkan urus niaga membaca data tanpa menghalang urus niaga lain dari membaca. 2. Kunci eksklusif menghalang urus niaga lain daripada membaca dan mengubah suai data. 3. Niat Kunci mengoptimumkan kecekapan kunci. 4. Rekod Rekod Kunci Kunci Rekod. 5. Gap Lock Locks Index Rakaman Gap. 6. Kunci kunci seterusnya adalah gabungan kunci rekod dan kunci jurang untuk memastikan konsistensi data.

Sebab -sebab utama prestasi pertanyaan MySQL yang lemah termasuk tidak menggunakan indeks, pemilihan pelan pelaksanaan yang salah oleh pengoptimasi pertanyaan, reka bentuk jadual yang tidak munasabah, jumlah data yang berlebihan dan persaingan kunci. 1. Tiada indeks menyebabkan pertanyaan perlahan, dan menambah indeks dapat meningkatkan prestasi dengan ketara. 2. Gunakan perintah Jelaskan untuk menganalisis pelan pertanyaan dan cari ralat pengoptimuman. 3. Membina semula struktur meja dan mengoptimumkan keadaan gabungan dapat meningkatkan masalah reka bentuk jadual. 4. Apabila jumlah data adalah besar, pembahagian dan strategi bahagian meja diterima pakai. 5. Dalam persekitaran konkurensi yang tinggi, mengoptimumkan urus niaga dan strategi mengunci dapat mengurangkan persaingan kunci.

Dalam pengoptimuman pangkalan data, strategi pengindeksan hendaklah dipilih mengikut keperluan pertanyaan: 1. Apabila pertanyaan melibatkan pelbagai lajur dan urutan syarat ditetapkan, gunakan indeks komposit; 2. Apabila pertanyaan melibatkan pelbagai lajur tetapi urutan syarat tidak ditetapkan, gunakan pelbagai indeks lajur tunggal. Indeks komposit sesuai untuk mengoptimumkan pertanyaan berbilang lajur, manakala indeks lajur tunggal sesuai untuk pertanyaan tunggal lajur.

Untuk mengoptimumkan pertanyaan perlahan MySQL, SlowQuerylog dan Performance_Schema perlu digunakan: 1. Dayakan SlowQueryLog dan tetapkan ambang untuk merakam pertanyaan perlahan; 2. Gunakan Performance_Schema untuk menganalisis butiran pelaksanaan pertanyaan, cari kesesakan prestasi dan mengoptimumkan.

MySQL dan SQL adalah kemahiran penting untuk pemaju. 1.MYSQL adalah sistem pengurusan pangkalan data sumber terbuka, dan SQL adalah bahasa standard yang digunakan untuk mengurus dan mengendalikan pangkalan data. 2.MYSQL menyokong pelbagai enjin penyimpanan melalui penyimpanan data yang cekap dan fungsi pengambilan semula, dan SQL melengkapkan operasi data yang kompleks melalui pernyataan mudah. 3. Contoh penggunaan termasuk pertanyaan asas dan pertanyaan lanjutan, seperti penapisan dan penyortiran mengikut keadaan. 4. Kesilapan umum termasuk kesilapan sintaks dan isu -isu prestasi, yang boleh dioptimumkan dengan memeriksa penyataan SQL dan menggunakan perintah menjelaskan. 5. Teknik pengoptimuman prestasi termasuk menggunakan indeks, mengelakkan pengimbasan jadual penuh, mengoptimumkan operasi menyertai dan meningkatkan kebolehbacaan kod.


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

Muat turun versi mac editor Atom
Editor sumber terbuka yang paling popular

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.

ZendStudio 13.5.1 Mac
Persekitaran pembangunan bersepadu PHP yang berkuasa

EditPlus versi Cina retak
Saiz kecil, penyerlahan sintaks, tidak menyokong fungsi gesaan kod

SecLists
SecLists ialah rakan penguji keselamatan muktamad. Ia ialah koleksi pelbagai jenis senarai yang kerap digunakan semasa penilaian keselamatan, semuanya di satu tempat. SecLists membantu menjadikan ujian keselamatan lebih cekap dan produktif dengan menyediakan semua senarai yang mungkin diperlukan oleh penguji keselamatan dengan mudah. Jenis senarai termasuk nama pengguna, kata laluan, URL, muatan kabur, corak data sensitif, cangkerang web dan banyak lagi. Penguji hanya boleh menarik repositori ini ke mesin ujian baharu dan dia akan mempunyai akses kepada setiap jenis senarai yang dia perlukan.