MySQL性能分析与性能优化篇

1 性能分析的思路

首先需要使用慢查询日志功能去获取所有查询时间比较长的SQL语句。
其次查看执行计划，查看有问题的SQL的执行计划。
最后使用show profile分析SQL语句性能消耗情况。

2 慢查询日志

MySQL的慢查询日志是MySQL提供的一种日志记录，它用来记录在MySQL中响应时间超过阈值的语句，具体指运行时间超过long_query_time值的SQL会被记录到慢查询日志中。

默认情况下，Mysql数据库并不启动慢查询日志，需要我们手动来设置这个参数，当然，如果不是调优需要的话，一般不建议启动该参数，因为开启慢查询日志会或多或少带来一定的性能影响。慢查询日志支持将日志记录写入文件，也支持将日志记录写入数据库表。

2.1 慢查询日志功能的开启

2.1.1 当前数据库的临时开启

可以通过设置slow_query_log的值来开启。默认情况下slow_query_log的值为OFF，表示慢查询日志是禁用的。

mysql> show variables like '%slow_query_log%';
+---------------------+------------------------------------------+
| Variable_name       | Value                                    |
+---------------------+------------------------------------------+
| slow_query_log      | OFF                                      |
| slow_query_log_file | /usr/local/mysql/data/localhost-slow.log |
+---------------------+------------------------------------------+
2 rows in set (0.00 sec)
mysql> set global slow_query_log=1;
Query OK, 0 rows affected (0.00 sec)
mysql> show variables like '%slow_query_log%';
+---------------------+------------------------------------------+
| Variable_name       | Value                                    |
+---------------------+------------------------------------------+
| slow_query_log      | ON                                       |
| slow_query_log_file | /usr/local/mysql/data/localhost-slow.log |
+---------------------+------------------------------------------+
2 rows in set (0.00 sec)

使用set global slow_query_log=1开启的慢查询日志只对当前数据库生效，MySQL重启后则会失效。

2.1.2 所有数据库的永久开启

如果要永久生效，就必须修改配置文件my.cnf（其它系统变量也是如此）。修改my.cnf文件，增加或修改参数slow_query_log 和slow_query_log_file后，然后重启MySQL服务器。

slow_query_log =1
slow_query_log_file=/usr/local/mysql/data/localhost-slow.log

mysql> show variables like 'slow_query%';
+---------------------+---------------------+
| Variable_name       | Value               |
+---------------------+---------------------+
| slow_query_log      | ON                  |
| slow_query_log_file | /usr/local/mysql/data/localhost-slow.log |
+---------------------+---------------------+
2 rows in set (0.00 sec)

2.2 慢查询日志功能相关参数

  • slow_query_log：是否开启慢查询日志，1表示开启，0表示关闭。
  • log_slow_queries：旧版（5.6以下版本）MySQL数据库慢查询日志存储路径。可以不设置该参数，系统则会默认给一个缺省的文件host_name_slow.log
  • slow_query_log_file：新版（5.6及以上版本）MySQL数据库慢查询日志存储路径。可以不设置该参数，系统则会默认给一个缺省的文件host_name_slow.log
  • long_query_time：慢查询阈值。当查询时间大于设定的阈值时记录日志。long_query_time的默认值为10，意思是记录运行10S以上的语句。从MySQL 5.1开始，long_query_time开始以微秒记录SQL语句运行时间，之前仅用秒为单位记录。如果记录到表里面，只会记录整数部分，不会记录微秒部分。
mysql> show variables like 'long_query_time';
+-----------------+-----------+
| Variable_name   | Value     |
+-----------------+-----------+
| long_query_time | 10.000000 |
+-----------------+-----------+
1 row in set (0.00 sec)

mysql> set global long_query_time=4;
Query OK, 0 rows affected (0.00 sec)

mysql> show variables like 'long_query_time';
+-----------------+-----------+
| Variable_name   | Value     |
+-----------------+-----------+
| long_query_time | 10.000000 |
+-----------------+-----------+
1 row in set (0.00 sec)

如上所示，我修改了变量long_query_time，但是查询变量long_query_time的值还是10，难道没有修改到呢？使用命令 set global long_query_time=4修改后，需要重新连接或新开一个会话才能看到修改值。你用show variables like 'long_query_time'查看是当前会话的变量值。你也可以不用重新连接会话，而是用show global variables like 'long_query_time'。

mysql> show variables like 'long_query_time';
+-----------------+-----------+
| Variable_name   | Value     |
+-----------------+-----------+
| long_query_time | 10.000000 |
+-----------------+-----------+
1 row in set (0.00 sec)

mysql> show global variables like 'long_query_time';
+-----------------+----------+
| Variable_name   | Value    |
+-----------------+----------+
| long_query_time | 4.000000 |
+-----------------+----------+
1 row in set (0.00 sec)
  • log_output：日志存储方式。log_output=FILE表示将日志存入文件。log_output=TABLE表示将日志存入数据库，这样日志信息就会被写入到mysql.slow_log表中。默认值是FILE。MySQL数据库支持同时两种日志存储方式，配置的时候以逗号隔开即可，如：log_output=FILE,TABLE。日志记录到系统的专用日志表中比记录到文件耗费更多的系统资源，因此对于需要启用慢查询日志，又需要能够获得更高的系统性能，那么建议优先记录到文件。
mysql> show variables like '%log_output%';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| log_output    | TABLE |
+---------------+-------+
1 row in set (0.00 sec)
  • log_queries_not_using_indexes：未使用索引的查询也被记录到慢查询日志中（可选项）。如果调优的话，建议开启这个选项。另外，开启了这个参数，其实使用full index scan的sql也会被记录到慢查询日志。
mysql> show variables like 'log_queries_not_using_indexes';
+-------------------------------+-------+
| Variable_name                 | Value |
+-------------------------------+-------+
| log_queries_not_using_indexes | OFF   |
+-------------------------------+-------+
1 row in set (0.00 sec)

mysql> set global log_queries_not_using_indexes=1;
Query OK, 0 rows affected (0.00 sec)
mysql> show variables like 'log_queries_not_using_indexes';
+-------------------------------+-------+
| Variable_name                 | Value |
+-------------------------------+-------+
| log_queries_not_using_indexes | ON    |
+-------------------------------+-------+
1 row in set (0.00 sec)

另外，如果你想查询有多少条慢查询记录，可以使用以下语句。

mysql> show global status like '%slow_queries%';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Slow_queries  | 4     |
+---------------+-------+
1 row in set (0.00 sec)

2.3 慢查询日志格式

063.png

2.4 分析慢查询日志的工具

在实际生产环境中，如果要手工分析日志，查找、分析SQL，显然是个体力活。我们可以使用工具。

2.4.1 使用mysqldumpslow工具

mysqldumpslow是MySQL自带的慢查询日志工具。 可以使用mysqldumpslow工具搜索慢查询日志中的SQL语句。

常用参数说明：
-s：是表示按照何种方式排序。
c：访问计数
l：锁定时间
r：返回记录数
t：查询时间
al：平均锁定时间
ar：平均返回记录数
at：平均查询时间
-t：是top的意思。-t n，即为返回前面n条的数据。
-g：后边可以写一个正则匹配模式，大小写不敏感的。

比如:

#得到访问次数最多的10个SQL
mysqldumpslow -s c -t 10 /database/mysql/mysql06_slow.log

#得到返回记录集最多的10个SQL。
mysqldumpslow -s r -t 10 /database/mysql/mysql06_slow.log

#得到按照时间排序的前10条里面含有左连接的查询语句。
mysqldumpslow -s t -t 10 -g "left join" /database/mysql/mysql06_slow.log

#另外建议在使用这些命令时结合 | 和more 使用 ，否则有可能出现刷屏的情况。
mysqldumpslow -s r -t 20 /mysqldata/mysql/mysql06-slow.log | more

2.4.2 使用percona-toolkit工具

percona-toolkit是一组高级命令行工具的集合，可以查看当前服务的摘要信息，磁盘检测，分析慢查询
日志，查找重复索引，实现表同步等等。

2.4.2.1 下载
wget https://www.percona.com/downloads/percona-toolkit/3.0.11/binary/tarball/percona-toolkit-3.0.11_x86_64.tar.gz
2.4.2.2 解压安装
tar -zxvf percona-toolkit-3.0.11_x86_64.tar.gz 
cd percona-toolkit-3.0.11 
perl Makefile.PL 
make make install
2.4.2.3 调错（先执行再安装）
#Can't locate ExtUtils/MakeMaker.pm in @INC
yum install -y perl-ExtUtils-CBuilder perl-ExtUtils-MakeMaker

#Can't locate Time/HiRes.pm in @INC
yum install -y perl-Time-HiRes

#Can't locate Digest/MD5.pm in @INC
yum install perl-Digest-MD5.x86_64
2.4.2.4 查看慢查询日志
pt-query-digest /var/lib/mysql/localhost-slow.log
2.4.2.5 pt-query-digest语法及重要选项

pt-query-digest [OPTIONS] [FILES] [DSN]

--create-review-table 
    当使用--review参数把分析结果输出到表中时，如果没有表就自动创建。 
--create-history-table 
    当使用--history参数把分析结果输出到表中时，如果没有表就自动创建。 
--filter 
    对输入的慢查询按指定的字符串进行匹配过滤后再进行分析 
--limit 
    限制输出结果百分比或数量，默认值是20,即将最慢的20条语句输出，
    如果是50%则按总响应时间占比从大到小排序，输 出到总和达到50%位置截止。 
--host mysql服务器地址 
--user mysql用户名 
--password mysql用户密码 
--history 
    将分析结果保存到表中，分析结果比较详细，下次再使用--history时，
    如果存在相同的语句，且查询所在的时间区间和历史表中的不同，则会记录到数据表中，
    可以通过查询同一CHECKSUM来比较某类型查询的历史变化。 
--review 
    将分析结果保存到表中，这个分析只是对查询条件进行参数化，一个类型的查询一条记录，比较简单。
    当下次使用-- review时，如果存在相同的语句分析，就不会记录到数据表中。 
--output 
    分析结果输出类型，值可以是report(标准分析报告)、slowlog(Mysql slow log)、json、json-anon。
    一般使用report，以便于阅读。 
--since 
    从什么时间开始分析，值为字符串，可以是指定的某个”yyyy-mm-dd [hh:mm:ss]”格式的时间点，
    也可以是简单的一个时间值：s(秒)、h(小时)、m(分钟)、d(天)，如12h就表示从12小时前开始统计。 
--until 
    截止时间，配合—-since可以分析一段时间内的慢查询。
2.4.2.6 分析pt-query-digest输出结果
第一部分：总体统计结果

Overall：总共有多少条查询
Time range：查询执行的时间范围
unique：唯一查询数量，即对查询条件进行参数化以后，总共有多少个不同的查询
total：总计
min：最小
max：最大
avg：平均
95%：把所有值从小到大排列，位置位于95%的那个数，这个数一般最具有参考价值
median：中位数，把所有值从小到大排列，位置位于中间那个数

#该工具执行日志分析的用户时间，系统时间，物理内存占用大小，虚拟内存占用大小 
340ms user time, 140ms system time, 23.99M rss, 203.11M vsz 
#工具执行时间 
Current date: Fri Nov 25 02:37:18 2016 
#运行分析工具的主机名 
Hostname: localhost.localdomain
#被分析的文件名 
Files: slow.log 
#语句总数量，唯一的语句数量，QPS，并发数 
Overall: 2 total, 2 unique, 0.01 QPS, 0.01x concurrency ________________ 
#日志记录的时间范围 
Time range: 2016-11-22 06:06:18 to 06:11:40 
#属性 总计 最小 最大 平均 95% 标准 中等 
Attribute    total   min     max     avg     95%     stddev  median 
============ ======= ======= ======= ======= ======= ======= ======= 
#语句执行时间 
Exec time    3s      640ms   2s      1s      2s      999ms   1s 
#锁占用时间 
Lock time    1ms     0       1ms     723us   1ms     1ms     723us 
#发送到客户端的行数 
Rows sent    5       1       4       2.50    4       2.12    2.50 
#select语句扫描行数 
Rows examine 186.17k 0       186.17k 93.09k  186.17k 131.64k 93.09k 
#查询的字符数 
Query size   455     15      440     227.50  440     300.52  227.50
第二部分：查询分组统计结果

Rank：所有语句的排名，默认按查询时间降序排列，通过--order by指定
Query ID：语句的ID（去掉多余空格和文本字符，计算hash值）
Response：总的响应时间
time：该查询在本次分析中总的时间占比
calls：执行次数，即本次分析总共有多少条这种类型的查询语句
R/Call：平均每次执行的响应时间
V/M：响应时间Variance-to-mean的比率
Item：查询对象

Profile 
Rank Query ID           Response time  Calls R/Call V/M   Item 
==== ================== ======== ===== ===== ====== ===== =============== 
1    0xF9A57DD5A41825CA 2.0529   76.2% 1     2.0529 0.00  SELECT 
2    0x4194D8F83F4F9365 0.6401   23.8% 1     0.6401 0.00  SELECT wx_member_base
第三部分：每一种查询的详细统计结果

由下面查询的详细统计结果，最上面的表格列出了执行次数、最大、最小、平均、95%等各项目的统计。
ID：查询的ID号，和上图的Query ID对应
Databases：数据库名
Users：各个用户执行的次数（占比）
Query_time distribution ：查询时间分布, 长短体现区间占比，本例中1s-10s之间查询数量是10s以上的两倍。
Tables：查询中涉及到的表
Explain：SQL语句

Query 1: 0 QPS, 0x concurrency, ID 0xF9A57DD5A41825CA at byte 802 ______ 
This item is included in the report because it matches --limit. 
Scores: V/M = 0.00 # Time range: all events occurred at 2016-11-22 06:11:40 
Attribute    pct total   min     max     avg     95%     stddev  median 
============ === ======= ======= ======= ======= ======= ======= ======= 
Count        50  1 
Exec time    76  2s      2s      2s      2s      2s      0       2s 
Lock time    0   0       0       0       0       0       0       0 
Rows sent    20  1       1       1       1       1       0       1 
Rows examine 0   0       0       0       0       0       0       0 
Query size   3   15      15      15      15      15      0       15 
String: 
Databases    test 
Hosts        192.168.8.1 
Users        mysql 
Query_time   distribution
1us 
10us 
100us 
1ms 
10ms 
100ms 
1s
10s+ 
EXPLAIN /*!50100 PARTITIONS*/ 
select sleep(2)\G
2.4.2.7 用法示例

1.直接分析慢查询文件:

pt-query-digest slow.log > slow_report.log

2.分析最近12小时内的查询：

pt-query-digest --since=12h slow.log > slow_report2.log

3.分析指定时间范围内的查询：

pt-query-digest slow.log --since '2017-01-07 09:30:00' --until '2017-01-07 10:00:00' > slow_report3.log

4.分析指含有select语句的慢查询

pt-query-digest --filter '$event->{fingerprint} =~ m/^select/i' slow.log> slow_report4.log

5.针对某个用户的慢查询

pt-query-digest --filter '($event->{user} || "") =~ m/^root/i' slow.log> slow_report5.log

6.查询所有所有的全表扫描或full join的慢查询

pt-query-digest --filter '(($event->{Full_scan} || "") eq "yes") ||(($event-> {Full_join} || "") eq "yes")' slow.log> slow_report6.log

7.把查询保存到query_review表

pt-query-digest --user=root –password=abc123 --review h=localhost,D=test,t=query_review--create-review-table slow.log

8.把查询保存到query_history表

pt-query-digest --user=root –password=abc123 --review h=localhost,D=test,t=query_history--create-review-table slow.log_0001 pt-query-digest --user=root –password=abc123 --review h=localhost,D=test,t=query_history--create-review-table slow.log_0002

9.通过tcpdump抓取mysql的tcp协议数据，然后再分析

tcpdump -s 65535 -x -nn -q -tttt -i any -c 1000 port 3306 > mysql.tcp.txt pt-query-digest --type tcpdump mysql.tcp.txt> slow_report9.log

10.分析binlog

mysqlbinlog mysql-bin.000093 > mysql-bin000093.sql pt-query-digest --type=binlog mysql-bin000093.sql > slow_report10.log

11.分析general log

pt-query-digest --type=genlog localhost.log > slow_report11.log

3 profile分析SQL语句性能消耗情况

Query Profiler是MySQL自带的一种query诊断分析工具，通过它可以分析出一条SQL语句的硬件性能瓶颈在什么地方。比如CPU，IO等，以及该SQL执行所耗费的时间等。不过该工具只有在MySQL 5.0.37以及以上版本中才有实现。默认的情况下，MYSQL的该功能没有打开，需要自己手动启动。

3.1 开启profile功能

Profile 功能由MySQL会话变量 profiling 控制，默认是OFF关闭状态。

3.1.1 查看是否开启了profile功能:

select @@profiling; 
show variables like ‘%profil%’;
064.png

3.1.2 开启profile功能

mysql> select @@profiling; 
+-------------+ 
| @@profiling | 
+-------------+ 
| 0           | 
+-------------+ 
1 row in set, 1 warning (0.00 sec) 

mysql> set profiling=1; 
Query OK, 0 rows affected, 1 warning (0.00 sec) 
mysql> select @@profiling; 
+-------------+ 
| @@profiling | 
+-------------+ 
| 1           | 
+-------------+ 
1 row in set, 1 warning (0.00 sec)

3.2 应用示例

mysql> select count(id) from tuser; 
ERROR 1046 (3D000): No database selected 
mysql> use test; 
Reading table information for completion of table and column names 
You can turn off this feature to get a quicker startup with -A 
Database changed 
mysql> select count(id) from tuser; 
+-----------+ 
| count(id) | 
+-----------+ 
| 10000000  | 
+-----------+ 
1 row in set (4.62 sec) 

mysql> show profiles; 
+-----------+------------+------------------------------+ 
| Query_ID  | Duration   | Query                        | 
+-----------+------------+------------------------------+ 
| 1         | 0.00016275 | select @@profiling           | 
| 2         | 0.00009200 | select count(id) from tuser  | 
| 3         | 0.00014875 | SELECT DATABASE()            | 
| 4         | 0.00066875 | show databases               | 
| 5         | 0.00021050 | show tables                  | 
| 6         | 4.61513875 | select count(id) from tuser  | 
+-----------+------------+------------------------------+ 
6 rows in set, 1 warning (0.13 sec) 

mysql> show profile for query 6; 
+----------------------+----------+ 
| Status | Duration | 
+----------------------+----------+ 
| starting | 0.000228 | 
| checking permissions | 0.000018 | 
| Opening tables | 0.000035 | 
| init | 0.000204 | 
| System lock | 0.000071 | 
| optimizing | 0.000013 | 
| statistics | 0.000067 |
| preparing | 0.000027 | 
| executing | 0.000004 | 
| Sending data | 4.614239 | 
| end | 0.000045 | 
| query end | 0.000009 | 
| closing tables | 0.000026 | 
| freeing items | 0.000019 | 
| logging slow query | 0.000124 | 
| cleaning up | 0.000011 | 
+----------------------+----------+ 
16 rows in set, 1 warning (0.00 sec) 

#查看CPU、I/O及swaps的消耗情况
mysql> show profile cpu,block io,swaps for query 6; 
+-------------+----------+----------+------------+--------------+---------------+-------+ 
| Status | Duration | CPU_user | CPU_system | Block_ops_in | Block_ops_out | Swaps | 
+-------------+----------+----------+------------+--------------+---------------+-------+ 
| starting | 0.000228 | 0.000361 | 0.000000 | 0 | 0 | 0 | 
| checking permissions | 0.000018 | 0.000000 | 0.000000 | 0 | 0 | 0 | 
| Opening tables | 0.000035 | 0.000000 | 0.000000 | 0 | 0 | 0 | 
| init | 0.000204 | 0.000224 | 0.000000 | 0 | 0 | 0 | 
| System lock | 0.000071 | 0.000000 | 0.000000 | 0 | 0 | 0 | 
| optimizing | 0.000013 | 0.000000 | 0.000000 | 0 | 0 | 0 | 
| statistics | 0.000067 | 0.000131 | 0.000000 | 0 | 0 | 0 | 
| preparing | 0.000027 | 0.000000 | 0.000000 | 0 | 0 | 0 | 
| executing | 0.000004 | 0.000000 | 0.000000 | 0 | 0 | 0 | 
| Sending data | 4.614239 | 3.648639 | 0.543410 | 55280 | 0 | 0 | 
| end | 0.000045 | 0.000202 | 0.000000 | 0 | 0 | 0 | 
| query end | 0.000009 | 0.000000 | 0.000000 | 0 | 0 | 0 | 
| closing tables | 0.000026 | 0.000000 | 0.000000 | 0 | 0 | 0 | 
| freeing items | 0.000019 | 0.000000 | 0.000000 | 0 | 0 | 0 | 
| logging slow query | 0.000124 | 0.000155 | 0.000000 | 0 | 8 | 0 |
| cleaning up | 0.000011 | 0.000000 | 0.000000 | 0 | 0 | 0 | 
+-------------+----------+----------+------------+--------------+---------------+-------+

4 性能优化

4.1 服务器层面优化

4.1.1 将数据保存在内存中，保证从内存中读取数据

4.1.1.1 足够大的buffer pool

推荐将数据完全保存在buffer pool中，即按存储量规划 buffer pool的容量。这样你能够完全从内存中读取数据，最大限度降低磁盘操作。buffer pool 默认大小是128M，可以通过修改innodb_buffer_pool_size 参数来调整buffer pool 的大小，理论上将其设置为内存的3/4或4/5。
怎样确定 innodb_buffer_pool_size 足够大，数据是从内存中读取而不是从硬盘中读取？

mysql> show global status like 'innodb_buffer_pool_pages_%'; 
+-----------------------------------+-------+ 
| Variable_name                     | Value |
+-----------------------------------+-------+ 
| Innodb_buffer_pool_pages_data     | 8190  | 
| Innodb_buffer_pool_pages_dirty    | 0     |
| Innodb_buffer_pool_pages_flushed  | 12646 | 
| Innodb_buffer_pool_pages_free     | 0     |   
| Innodb_buffer_pool_pages_misc     | 1     | 
| Innodb_buffer_pool_pages_total    | 8191  |

发现Innodb_buffer_pool_pages_free为0，则说明 buffer pool 已经被用光，须要增innodb_buffer_pool_size。

在配置文件my.cnf中修改 innodb_buffer_pool_size的大小。

innodb_buffer_pool_size = 750M
4.1.1.2 内存预热

默认情况，仅仅有某条数据被读取一次，才会缓存在 innodb_buffer_pool。所以，数据库刚刚启动，须要进行数据预热，将磁盘上的全部数据缓存到内存中。数据预热能够防止磁盘读增加I/O提高读取速度。可以配置如下参数，在关闭实例时dump一个 ib_buffer_pool 文件来存放上次关闭时的内存数据，当再次启动实例时加载进去。

-- 启动MySQL服务时，MySQL将本地热数据加载到InnoDB缓冲池中预热
innodb_buffer_pool_load_at_startup = 1
 
-- 停止MySQL服务时，InnoDB将InnoDB缓冲池中的热数据保存到本地硬盘
innodb_buffer_pool_dump_at_shutdown = 1
 
-- 关闭mysql服务时，转储活跃使用的innodb buffer pages的比例，默认25%；
-- 配合innodb_buffer_pool_load_at_startup和innodb_buffer_pool_dump_at_shutdown两个参数同时使用
-- 如果启用新的参数，比如40 ，每个innodb buffer pool instance中有100个pages ，每次转储每个innodb buffer实例中的40个pages#
innodb_buffer_pool_dump_pct = 40
演示

第一次进入mysql服务

-- 第一次查询数据为0.11秒
mysql> select count(1) from test_conver_table where b='1111';
+----------+
| count(1) |
+----------+
|        1 |
+----------+
1 row in set (0.11 sec)
 
-- 第二次查询数据为0秒，因为数据已加载到innodb_buffer_pool缓冲池中
mysql> select count(1) from test_conver_table where b='1111';
+----------+
| count(1) |
+----------+
|        1 |
+----------+
1 row in set (0.00 sec)
mysql> exit
Bye

kill -9 强制杀掉mysqld服务（此时不生产ib_buffer_pool）

[root@hostmysql-m ~]#  kill -9 4540
[root@hostmysql-m ~]# service mysqld start
Starting mysqld:                                           [  OK  ]

第二次进入mysql服务

-- 第一次查询时用了0.05秒，说明数据没有加载到缓冲池中
mysql> select count(1) from test_conver_table where b='1111';
+----------+
| count(1) |
+----------+
|        1 |
+----------+
1 row in set (0.05 sec) 
mysql> exit
Bye

service mysqld restart 正常的重启或者关闭mysqld 服务（可产生ib_buffer_pool文件，存放关闭时实例的内存数据）

[root@hostmysql-m ~]# service mysqld restart
Stopping mysqld:                                           [  OK  ]
Starting mysqld:                                           [  OK  ]
 
[root@hostmysql-m ~]# ll /var/lib/mysql/ib_buffer_pool
-rw-r----- 1 mysql mysql 1122 Dec 29 17:00 /var/lib/mysql/ib_buffer_pool

第三次进入mysql服务

-- 第一次查询时 用了0秒，说明数据已经通过预热方式 加载到了缓冲池中
mysql> select count(1) from test_conver_table where b='1111';
+----------+
| count(1) |
+----------+
|        1 |
+----------+
1 row in set (0.00 sec)

4.1.2 降低磁盘写入次数

①合理设置redo log的大小
redo log较大，则落盘次数就较少（innodb_log_file_size设置成innodb_buffer_pool_size的0.25倍）
②合理设置redolog的落盘策略
innodb_flush_log_at_trx_commit和写磁盘操作密切相关。
③避免双写入缓冲
innodb_flush_method=O_DIRECT
④关闭某些日志
关闭通用查询日志、慢查询日志，只开启二进制日志。

4.1.3 提高磁盘读写速度

采用固态硬盘（SSD）

4.2 SQL设计层面优化

① 选择合适的存储引擎: InnoDB
除非你的数据表使用来做仅仅读或者全文检索 (相信如今提到全文检索，没人会用MYSQL了)，否则你应该默认选择 InnoDB 。你自己在测试的时候可能会发现 MyISAM 比 InnoDB 速度快。这是由于MyISAM 仅仅缓存索引，而 InnoDB 缓存数据和索引，MyISAM 不支持事务。可是假设你使用 innodb_flush_log_at_trx_commit = 2 能够获得接近的读取性能 (相差百倍) 。
a.将现有的 MyISAM 数据库转换为 InnoDB

mysql -u [USER_NAME] -p -e "SHOW TABLES IN [DATABASE_NAME];" | tail -n +2 | xargs -I '{}' echo "ALTER TABLE {} ENGINE=InnoDB;" > alter_table.sql
perl -p -i -e 's/(search_[a-z_]+ ENGINE=)InnoDB//1MyISAM/g' alter_table.sql
mysql -u [USER_NAME] -p [DATABASE_NAME] < alter_table.sql

b.为每一个表分别创建InnoDB FILE。这样能够保证 ibdata1 文件不会过大，失去控制。尤其是在运行 mysqlcheck -o –all-databases 的时候。

innodb_file_per_table=1

② 设计中间表，一般针对于统计分析功能，或者实时性不高的需求（OLTP、OLAP）。

③ 为减少关联查询，创建合理的冗余字段（考虑数据库的三范式和查询性能的取舍，创建冗余字段还需要注意数据一致性问题）

065.png

④ 对于字段太多的大表，考虑拆表（比如一个表有100多个字段） 人和身份证

⑤ 对于表中经常不被使用的字段或者存储数据比较多的字段，考虑拆表（比如商品表中会存储商品介绍，此时可以将商品介绍字段单独拆解到另一个表中，使用商品ID关联）

⑥ 建议每张表都要有一个主键（主键索引），而且主键类型最好是int类型，建议自增主键（不考虑分布式系统的情况下）。

4.3 SQL语句优化

4.3.1 充分使用索引

where字段 、组合索引（最左前缀） 、 索引下推（非选择行，不加锁）、索引覆盖（不回表）、on两边排序、分组统计不要用星。

4.3.2 LIMIT优化

单条查询最后添加 LIMIT 1，停止全表扫描

4.3.3 其他优化

count （星） ：找普通索引 ,找到最小的那棵树来遍历（包含空值）
count（字段）：走缓存（不包含空值）
count（1）： 忽略字段（包含空值）

066.png

不用 MySQL 内置的函数，因为内置函数不会建立查询缓存。

SELECT * FROM user where birthday = now();
最后编辑于 ：
©著作权归作者所有,转载或内容合作请联系作者
  • 人面猴
    序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
    沈念sama阅读 202,980评论 5赞 476
  • 死咒
    序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
    沈念sama阅读 85,178评论 2赞 380
  • 救了他两次的神仙让他今天三更去死
    文/潘晓璐 我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
    开封第一讲书人阅读 149,868评论 0赞 336
  • 道士缉凶录：失踪的卖姜人
    文/不坏的土叔 我叫张陵，是天一观的道长。 经常有香客问我，道长，这世上最难降的妖魔是什么？ 我笑而不...
    开封第一讲书人阅读 54,498评论 1赞 273
  • 港岛之恋（遗憾婚礼）
    正文 为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
    茶点故事阅读 63,492评论 5赞 364
  • 恶毒庶女顶嫁案：这布局不是一般人想出来的
    文/花漫 我一把揭开白布。 她就那样静静地躺着，像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上，一...
    开封第一讲书人阅读 48,521评论 1赞 281
  • 城市分裂传说
    那天，我揣着相机与录音，去河边找鬼。 笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。 我是一名探鬼主播，决...
    沈念sama阅读 37,910评论 3赞 395
  • 双鸳鸯连环套：你想象不到人心有多黑
    文/苍兰香墨 我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
    开封第一讲书人阅读 36,569评论 0赞 256
  • 万荣杀人案实录
    序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
    沈念sama阅读 40,793评论 1赞 296
  • 护林员之死
    正文 独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,559评论 2赞 319
  • 白月光启示录
    正文 我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,639评论 1赞 329
  • 活死人
    序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
    沈念sama阅读 33,342评论 4赞 318
  • 日本核电站爆炸内幕
    正文 年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
    茶点故事阅读 38,931评论 3赞 307
  • 男人毒药：我在死后第九天来索命
    文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,904评论 0赞 19
  • 一桩弑父案，背后竟有这般阴谋
    文/苍兰香墨 我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,144评论 1赞 259
  • 情欲美人皮
    我被黑心中介骗来泰国打工， 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。 一个月前我还...
    沈念sama阅读 42,833评论 2赞 349
  • 代替公主和亲
    正文 我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
    茶点故事阅读 42,350评论 2赞 342