MySQL优化

最新推荐文章于 2025-03-26 09:28:18 发布

转载最新推荐文章于 2025-03-26 09:28:18 发布 · 265 阅读

2 ·

CC 4.0 BY-SA版权

原文链接：https://www.cnblogs.com/jian0110/p/9410981.html

常用的优化步骤

在开始博客之前，还是同样的给一个大概的目录结构，实则即为一般MySQL的优化步骤

1、查看SQL的执行频率---------------使用show status命令

2、定位哪些需要优化的SQL------------通过慢查询记录+show processlist命令查看当前线程

3、分析为什么SQL执行效率低------------使用explain/desc命令分析

相关列简单解释：type、table、select_type...

4、对症下药采取优化措施-----------举例采取index进行优化

如何使用索引？
使用索引应该注意的事项
查看索引使用情况

主要参考资料：《深入浅出MySQL》，https://dev.mysql.com/doc/refman/8.0/en/statement-optimization.html

一、查看SQL执行频率

　　使用show [session|gobal] status命令了解SQL执行频率、线程缓存内的线程的数量、当前打开的连接的数量、获得的表的锁的次数等。

比如执行show status like 'Com_%'查看每个语句执行的次数即频率，其中Com_xxx中xxx表示就是语句，比如Com_select：执行select操作的次数。

 1 mysql> use test;
 2 Database changed
 3 mysql> show status like 'Com_%';
 4 +-----------------------------+-------+
 5 | Variable_name               | Value |
 6 +-----------------------------+-------+
 7 | Com_admin_commands          | 0     |
 8 | Com_assign_to_keycache      | 0     |
 9 | Com_alter_db                | 0     |
10 | Com_alter_db_upgrade        | 0     |
11 | Com_alter_event             | 0     |
12 | Com_alter_function          | 0     |
13 | Com_alter_instance          | 0     |
14 | Com_alter_procedure         | 0     |
15 | Com_alter_server            | 0     |
16 | Com_alter_table             | 0     |
17 | Com_alter_tablespace        | 0     |
18 | Com_alter_user              | 0     |
19 | Com_analyze                 | 0     |
20 | Com_begin                   | 0     |
21 | Com_binlog                  | 0     |
22 | Com_call_procedure          | 0     |
23 | Com_change_db               | 2     |
24 | Com_change_master           | 0     |
25 | Com_change_repl_filter      | 0     |
26 | Com_check                   | 0     |
27 | Com_checksum                | 0     |
28 | Com_commit                  | 0     |
29 | Com_create_db               | 0     |
30 | Com_create_event            | 0     |
31 | Com_create_function         | 0     |
32 | Com_create_index            | 0     |
　　..............................

比如执行show status like 'slow_queries'查看慢查询次数（黑人问号？？什么是慢查询呢？就是通过设置查询时间阈值long_query_time（0-10s）并打开开关show_query_log（1=OFF/0=ON），当超过这个阈值的查询都称之为慢查询,通常用来划分执行SQL效率）

mysql> show status like 'slow_queries';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Slow_queries  | 0     |
+---------------+-------+
1 row in set

比如执行show status like 'uptime'查看服务工作时间（即运行时间）：

mysql> show status like 'uptime';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Uptime        | 21645 |
+---------------+-------+
1 row in set

比如执行show status like 'connections'查看MySQL连接数：

mysql> show status like 'connections';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Connections   | 6     |
+---------------+-------+
1 row in set

　　通过show [session|gobal] status命令很清楚地看到哪些SQL执行效率不如人意，但是具体是怎么个不如意法，还得继续往下看，使用EXPLAIN命令分析具体的SQL语句

二、定位效率低的SQL

　　上面也提到过慢查询这个概念主要是用来划分效率低的SQL，但是慢查询是在整个查询结束后才记录的，所以光是靠慢查询日志是跟踪不了效率低的SQL。一般有两种方式定位效率低的SQL：

　　1、通过慢查询日志查看效率低的SQL语句，慢查询日志是通过show_query_log_file指定存储路径的，里面记录所有超过long_query_time的SQL语句（关于日志的查看，日后再一步研究学习），但是需要慢查询日志的产生是在查询结束后才有的。

　　2、通过show processlist命令查看当前MySQL进行的线程，可以看到线程的状态信息

mysql> show processlist;
+----+------+-----------------+------+---------+------+----------+------------------+
| Id | User | Host            | db   | Command | Time | State    | Info             |
+----+------+-----------------+------+---------+------+----------+------------------+
|  2 | root | localhost:58377 | NULL | Sleep   | 2091 |          | NULL             |
|  3 | root | localhost:58382 | test | Sleep   | 2083 |          | NULL             |
|  4 | root | localhost:58386 | test | Sleep   | 2082 |          | NULL             |
|  5 | root | localhost:59092 | test | Query   |    0 | starting | show processlist |
+----+------+-----------------+------+---------+------+----------+------------------+
4 rows in set

　　其中主要的是state字段，表示当前SQL语句线程的状态，如Sleeping 表示正在等待客户端发送新请求，Sending data把查询到的data结果发送给客户端等等，具体请看https://dev.mysql.com/doc/refman/8.0/en/general-thread-states.html

三、查看分析效率低的SQL

　　MYSQL 5.6.3以前只能EXPLAIN SELECT; MYSQL5.6.3以后就可以EXPLAIN SELECT,UPDATE,DELETE，现在我们先创建一个user_table的表，之后分析select* from user where name=''语句

mysql> create table user(id int, name varchar(10),password varchar(32),primary key(id))engine=InnoDB;
Query OK, 0 rows affected

之后插入三条数据：

mysql> insert into user values(1,'Zhangsan',replace(UUID(),'-','')),(2,'Lisi',replace(UUID(),'-','')),(3,'Wangwu',replace(UUID(),'-',''));
Query OK, 3 rows affected
Records: 3  Duplicates: 0  Warnings: 0
mysql> select* from user;
+----+----------+----------------------------------+
| id | name     | password                         |
+----+----------+----------------------------------+
|  1 | Zhangsan | 2d7284808e5111e8af74201a060059ce |
|  2 | Lisi     | 2d73641c8e5111e8af74201a060059ce |
|  3 | Wangwu   | 2d73670c8e5111e8af74201a060059ce |
+----+----------+----------------------------------+
3 rows in set

下面以分析select*from user where name='Lisi'语句为例：

mysql> explain select*from user where name='Lisi';
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------------+
| id | select_type | table | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra       |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------------+
|  1 | SIMPLE      | user  | NULL       | ALL  | NULL          | NULL | NULL    | NULL |    3 |    33.33 | Using where |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------------+
1 row in set

下面讲解select_type等常见列的含义的：

（1）select_type：表示SELECT的类型，主要有：

SIMPLE：简单表，没有表连接或者子查询
PRIMARY：主查询，即最外城的查询
UNION：UNION中的第二个或者后面的语句
SUBQUERY：子查询中的第一个SELECT

（2）table：结果输出的表

（3）type：表示表的连接类型，性能由好到差为：

system：常量表
const：单表中最多有一行匹配，比如primary key，unique index
eq_ref：多表连接中使用primary key，unique index
ref：使用普通索引
ref_or_null：与ref类似，但是包含了NULL查询
index_merge：索引合并优化
unique_subquery：in后面是一个查询主键字段的子查询
index_subquery：in后面是非唯一索引字段的子查询
range：单表中范围查看，使用like模糊查询
index：对于后面每一行都通过查询索引得到数据
all：表示全表查询

（3）possible_key：查询时可能使用的索引

（4）key：表示实际使用的索引

（5）key_len：索引字段的长度

（6）rows：查询时实际扫描的行数

（7）Extra：执行情况的说明和描述

（8）partitions：分区数目

（9）filtered：查询过滤的表占的百分比，比如这里查询的记录是name=Lisi的记录，占三条记录的33.3%

四、关于索引的优化

1、使用索引优化的举例

　　上个例子我们看到到执行explain select*from user where name='Lisi'，扫描了3行（全部行数）使用了全表搜索all。如果实际业务中name是经常用到查询的字段（是指经常跟在where后的字段，不是select后的字段）并且数据量很大的情况呢？这时候就需要索引了（索引经常用到where后面的字段比select后面的字段效果更好，或者说就是要使用在where后面的字段上）

增加name前缀索引（这里只是举例，并没有选择最合适的前缀）：

mysql> create index index_name on user(name(2));
Query OK, 0 rows affected
Records: 0  Duplicates: 0  Warnings: 0

执行explain分析

mysql> explain select*from user where name = 'Lisi';
+----+-------------+-------+------------+------+---------------+------------+---------+-------+------+----------+-------------+
| id | select_type | table | partitions | type | possible_keys | key        | key_len | ref   | rows | filtered | Extra       |
+----+-------------+-------+------------+------+---------------+------------+---------+-------+------+----------+-------------+
|  1 | SIMPLE      | user  | NULL       | ref  | index_name    | index_name | 9       | const |    1 |      100 | Using where |
+----+-------------+-------+------------+------+---------------+------------+---------+-------+------+----------+-------------+
1 row in set

　　可以看到type变为ref、rows降为1（实际上只要使用了索引都是1），filtered过滤百分比为100%，实际用到的索引为index_name。如果数据量很大的话使用索引就是很好的优化措施，对于如何选择索引，什么时候用索引，我做出了如下总结：

2、如何高效使用索引？

　　(1) 创建多列索引时，只要查询条件中用到最左边的列，索引一般都会被用到

　　我们创建一张没有索引的表user_1:

mysql> show create table 
user_1;
+--------+--------------------------------------------------------------------------------------------------------------------------+
| Table  | Create Table                                                                                                             |
+--------+--------------------------------------------------------------------------------------------------------------------------+
| user_1 | CREATE TABLE `user_1` (
  `id` int(11) DEFAULT NULL,
  `name` varchar(10) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8 |
+--------+--------------------------------------------------------------------------------------------------------------------------+
　1 row in set

　之后同样插入数据：

mysql> select *from user_1;
+----+----------+
| id | name     |
+----+----------+
|  1 | Zhangsan |
|  2 | Lisi     |
+----+----------+
2 rows in set

创建多列索引index_id_name

mysql> create index index_id_name on user_1(id,name);
Query OK, 0 rows affected
Records: 0  Duplicates: 0  Warnings: 0

　实验查询explain分析name与id

mysql> explain select * from user_1 where id=1;
+----+-------------+--------+------------+------+---------------+---------------+---------+-------+------+----------+-------------+
| id | select_type | table  | partitions | type | possible_keys | key           | key_len | ref   | rows | filtered | Extra       |
+----+-------------+--------+------------+------+---------------+---------------+---------+-------+------+----------+-------------+
|  1 | SIMPLE      | user_1 | NULL       | ref  | index_id_name | index_id_name | 5       | const |    1 |      100 | Using index |
+----+-------------+--------+------------+------+---------------+---------------+---------+-------+------+----------+-------------+
1 row in set

mysql> explain select * from user_1 where name='Lisi';
+----+-------------+--------+------------+-------+---------------+---------------+---------+------+------+----------+--------------------------+
| id | select_type | table  | partitions | type  | possible_keys | key           | key_len | ref  | rows | filtered | Extra                    |
+----+-------------+--------+------------+-------+---------------+---------------+---------+------+------+----------+--------------------------+
|  1 | SIMPLE      | user_1 | NULL       | index | NULL          | index_id_name | 38      | NULL |    2 |       50 | Using where; Using index |
+----+-------------+--------+------------+-------+---------------+---------------+---------+------+------+----------+--------------------------+
1 row in set

　　可以看到使用最左列id的时候，rows为1，并且Extra明确使用了index，key的值为id_name_index，type的值为ref，而where不用到id，而是name的话，rows的值为2。filtered为50%，虽然key是index_id_name，但是表明是索引（个人理解，应该不太准确）

　　(2) 使用like的查询，只有%不是第一个字符并且%后面是常量的情况下，索引才可能会被使用。

　　执行explain select *from user where name like ‘%Li’后type为ALL且key的值为NULL，执行explain select *from user where name like ‘Li%’后key值不为空为index_name。

mysql> explain select*from user where name like '%Li';
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------------+
| id | select_type | table | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra       |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------------+
|  1 | SIMPLE      | user  | NULL       | ALL  | NULL          | NULL | NULL    | NULL |    3 |    33.33 | Using where |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------------+
1 row in set
mysql> explain select*from user where name like 'Li%';
+----+-------------+-------+------------+-------+---------------+------------+---------+------+------+----------+-------------+
| id | select_type | table | partitions | type  | possible_keys | key        | key_len | ref  | rows | filtered | Extra       |
+----+-------------+-------+------------+-------+---------------+------------+---------+------+------+----------+-------------+
|  1 | SIMPLE      | user  | NULL       | range | index_name    | index_name | 9       | NULL |    1 |      100 | Using where |
+----+-------------+-------+------------+-------+---------------+------------+---------+------+------+----------+-------------+
1 row in set

　　(3) 如果对打的文本进行搜索，使用全文索引而不是用like ‘%...%’（只有MyISAM支持全文索引）。

　　(4) 如果列名是索引，使用column_name is null将使用索引。

mysql> explain select*from user where name is null;
+----+-------------+-------+------------+------+---------------+------------+---------+-------+------+----------+-------------+
| id | select_type | table | partitions | type | possible_keys | key        | key_len | ref   | rows | filtered | Extra       |
+----+-------------+-------+------------+------+---------------+------------+---------+-------+------+----------+-------------+
|  1 | SIMPLE      | user  | NULL       | ref  | index_name    | index_name | 9       | const |    1 |      100 | Using where |
+----+-------------+-------+------------+------+---------------+------------+---------+-------+------+----------+-------------+
1 row in set

mysql> explain select*from user where password
 is null;
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------------+
| id | select_type | table | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra       |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------------+
|  1 | SIMPLE      | user  | NULL       | ALL  | NULL          | NULL | NULL    | NULL |    3 |    33.33 | Using where |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------------+
1 row in set

3、哪些情况下即使有索引也用不到？

　　(1) MySQL使用MEMORY/HEAP引擎（使用的HASH索引），并且WHERE条件中不会使用”=”,in等进行索引列，那么不会用到索引（这是关于引擎部分特点，之后会介绍）。

　　(2) 用OR分隔开的条件，如果OR前面的条件中的列有索引，而后面的列没有索引，那么涉及到的列索引不会被使用。

　　执行命令show index from user可以看出password字段并没有使用任何索引，而id使用了两个索引，但是where id=1 or password='2d7284808e5111e8af74201a060059ce' 导致没有使用id列的primary索引与id_name_index索引

mysql> show index from user;
+-------+------------+---------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| Table | Non_unique | Key_name      | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment |
+-------+------------+---------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| user  |          0 | PRIMARY       |            1 | id          | A         |           3 | NULL     | NULL   |      | BTREE      |         |               |
| user  |          1 | index_name    |            1 | name        | A         |           3 |        2 | NULL   | YES  | BTREE      |         |               |
| user  |          1 | id_name_index |            1 | id          | A         |           3 | NULL     | NULL   |      | BTREE      |         |               |
| user  |          1 | id_name_index |            2 | name        | A         |           3 | NULL     | NULL   | YES  | BTREE      |         |               |
+-------+------------+---------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
4 rows in set

mysql> explain select*from user where id=1 or password='2d7284808e5111e8af74201a060059ce';
+----+-------------+-------+------------+------+-----------------------+------+---------+------+------+----------+-------------+
| id | select_type | table | partitions | type | possible_keys         | key  | key_len | ref  | rows | filtered | Extra       |
+----+-------------+-------+------------+------+-----------------------+------+---------+------+------+----------+-------------+
|  1 | SIMPLE      | user  | NULL       | ALL  | PRIMARY,id_name_index | NULL | NULL    | NULL |    3 |    55.56 | Using where |
+----+-------------+-------+------------+------+-----------------------+------+---------+------+------+----------+-------------+
1 row in set

　　(3) 不是用到复合索引中的第一列即最左边的列的话，索引就不起作用（上面已经介绍）。

　　(4) 如果like是以%开头的(上面已经介绍)

　　(5) 如果列类型是字符串，那么where条件中字符常量值不用’’引号引起来的话，那就不会失去索引效果，这是因为MySQL会把输入的常量值进行转换再使用索引。

　　select * from user_1 where name =250，其中name的索引为name_index，并且是varchar字符串类型，但是并没有将250用引号变成’250’，那么explain之后的ref仍然为NULL,rows为3

mysql> show index from user_1;
+--------+------------+---------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| Table  | Non_unique | Key_name      | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment |
+--------+------------+---------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| user_1 |          1 | index_id_name |            1 | id          | A         |           2 | NULL     | NULL   | YES  | BTREE      |         |               |
| user_1 |          1 | index_id_name |            2 | name        | A         |           2 | NULL     | NULL   | YES  | BTREE      |         |               |
| user_1 |          1 | name_index    |            1 | name        | A         |           3 |        5 | NULL   | YES  | BTREE      |         |               |
+--------+------------+---------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
3 rows in set

mysql> explain select*from user_1 where name=250;
+----+-------------+--------+------------+-------+---------------+---------------+---------+------+------+----------+--------------------------+
| id | select_type | table  | partitions | type  | possible_keys | key           | key_len | ref  | rows | filtered | Extra                    |
+----+-------------+--------+------------+-------+---------------+---------------+---------+------+------+----------+--------------------------+
|  1 | SIMPLE      | user_1 | NULL       | index | name_index    | index_id_name | 38      | NULL |    3 |    33.33 | Using where; Using index |
+----+-------------+--------+------------+-------+---------------+---------------+---------+------+------+----------+--------------------------+
1 row in set

mysql> explain select*from user_1 where name='250';
+----+-------------+--------+------------+------+---------------+------------+---------+-------+------+----------+-------------+
| id | select_type | table  | partitions | type | possible_keys | key        | key_len | ref   | rows | filtered | Extra       |
+----+-------------+--------+------------+------+---------------+------------+---------+-------+------+----------+-------------+
|  1 | SIMPLE      | user_1 | NULL       | ref  | name_index    | name_index | 18      | const |    1 |      100 | Using where |
+----+-------------+--------+------------+------+---------------+------------+---------+-------+------+----------+-------------+
1 row in set

4、查看索引的使用情况

执行show status like ‘Handler_read%’可以看到一个值Handler_read_key，它代表一行被索引值读的次数，如果值很低说明增加索引得到的性能改善不高，因为索引并不经常使用。

mysql> show status like 'Handler_read%' ;
+-----------------------+-------+
| Variable_name         | Value |
+-----------------------+-------+
| Handler_read_first    | 3     |
| Handler_read_key      | 5     |
| Handler_read_last     | 0     |
| Handler_read_next     | 0     |
| Handler_read_prev     | 0     |
| Handler_read_rnd      | 0     |
| Handler_read_rnd_next | 20    |
+-----------------------+-------+
7 rows in set

（1）Handler_read_first：索引中第一条被读的次数。如果较高，它表示服务器正执行大量全索引扫描；

（2）Handler_read_key：如果索引正在工作，这个值代表一个行被索引值读的次数，如果值越低，表示索引得到的性能改善不高，因为索引不经常使用。

（3）Handler_read_next ：按照键顺序读下一行的请求数。如果你用范围约束或如果执行索引扫描来查询索引列，该值增加。

（4）Handler_read_prev：按照键顺序读前一行的请求数。该读方法主要用于优化ORDER BY ... DESC。

（5）Handler_read_rnd ：根据固定位置读一行的请求数。如果你正执行大量查询并需要对结果进行排序该值较高。你可能使用了大量需要MySQL扫描整个表的查询或你的连接没有正确使用键。这个值较高，意味着运行效率低，应该建立索引来补救。

（6）Handler_read_rnd_next：在数据文件中读下一行的请求数。如果你正进行大量的表扫描，该值较高。通常说明你的表索引不正确或写入的查询没有利用索引。

　　　注：以上6点来自于网络总结，其中比较重要的两个参数是Handler_read_key与Handler_read_rnd_next。

常用优化

前言

　　之前已经简单介绍了MySQL的优化步骤，那么接下来自然而是就是常用的SQL优化，比如inseer、group by等常用SQL的优化，会涉及SQL语句内部细节（这正是我缺乏的）。最后希望自己能记录完成的一套MySQL优化博文！

　　注：其中部分我并没有全部实验（并不代表是错的），这里只相当于记录下，接下来会慢慢补充！

　　参考资料：《深入浅出MySQL》（有需要PDF电子书的伙伴可以评论或者私信我）

1、大批量插入数据优化

（1）对于MyISAM存储引擎的表，可以使用：DISABLE KEYS 和 ENABLE KEYS 用来打开或者关闭 MyISAM 表非唯一索引的更新。

ALTER TABLE tbl_name DISABLE KEYS;
loading the data
ALTER TABLE tbl_name ENABLE KEYS;

（2）对于InnoDB引擎，有以下几种优化措施：

　　① 导入的数据按照主键的顺序保存：这是因为InnoDB引擎表示按照主键顺序保存的，如果能将插入的数据提前按照排序好自然能省去很多时间。

　　比如bulk_insert.txt文件是以表user主键的顺序存储的，导入的时间为15.23秒

mysql> load data infile 'mysql/bulk_insert.txt' into table user;
Query OK, 126732 rows affected (15.23 sec)
Records: 126732 Deleted: 0 Skipped: 0 Warnings: 0

　　没有按照主键排序的话，时间为：26.54秒

mysql> load data infile 'mysql/bulk_insert.txt' into table user;
Query OK, 126732 rows affected (26.54 sec)
Records: 126732 Deleted: 0 Skipped: 0 Warnings: 0

　　② 导入数据前执行SET UNIQUE_CHECKS=0，关闭唯一性校验，带导入之后再打开设置为1：校验会消耗时间，在数据量大的情况下需要考虑。

　　③ 导入前设置SET AUTOCOMMIT=0，关闭自动提交，导入后结束再设置为1：这是因为自动提交会消耗部分时间与资源，虽然消耗不是很大，但是在数据量大的情况下还是得考虑。

2、INSERT的优化

（1）尽量使用多个值表的 INSERT 语句，这种方式将大大缩减客户端与数据库之间的连接、关闭等消耗。（同一客户的情况下），即：

　INSERT INTO tablename values(1,2),(1,3),(1,4)

实验：插入8条数据到user表中（使用navicat客户端工具）

insert into user values(1,'test',replace(uuid(),'-',''));
insert into user values(2,'test',replace(uuid(),'-',''));
insert into user values(3,'test',replace(uuid(),'-',''));
insert into user values(4,'test',replace(uuid(),'-',''));
insert into user values(5,'test',replace(uuid(),'-',''));
insert into user values(6,'test',replace(uuid(),'-',''));
insert into user values(7,'test',replace(uuid(),'-',''));
insert into user values(8,'test',replace(uuid(),'-',''));

得到反馈：

[SQL] insert into user values(1,'test',replace(uuid(),'-',''));
受影响的行: 1
时间: 0.033s
[SQL] 
insert into user values(2,'test',replace(uuid(),'-',''));
受影响的行: 1
时间: 0.034s
[SQL] 
insert into user values(3,'test',replace(uuid(),'-',''));
受影响的行: 1
时间: 0.056s
[SQL] 
insert into user values(4,'test',replace(uuid(),'-',''));
受影响的行: 1
时间: 0.008s
[SQL] 
insert into user values(5,'test',replace(uuid(),'-',''));
受影响的行: 1
时间: 0.008s
[SQL] 
insert into user values(6,'test',replace(uuid(),'-',''));
受影响的行: 1
时间: 0.024s
[SQL] 
insert into user values(7,'test',replace(uuid(),'-',''));
受影响的行: 1
时间: 0.004s
[SQL] 
insert into user values(8,'test',replace(uuid(),'-',''));
受影响的行: 1
时间: 0.004s

总共的时间为0.171秒，接下来使用多值表形式：

insert into user values
(9,'test',replace(uuid(),'-','')),
(10,'test',replace(uuid(),'-','')),
(11,'test',replace(uuid(),'-','')),
(12,'test',replace(uuid(),'-','')),
(13,'test',replace(uuid(),'-','')),
(14,'test',replace(uuid(),'-','')),
(15,'test',replace(uuid(),'-','')),
(16,'test',replace(uuid(),'-',''));

得到反馈：

[SQL] insert into user values
(9,'test',replace(uuid(),'-','')),
(10,'test',replace(uuid(),'-','')),
(11,'test',replace(uuid(),'-','')),
(12,'test',replace(uuid(),'-','')),
(13,'test',replace(uuid(),'-','')),
(14,'test',replace(uuid(),'-','')),
(15,'test',replace(uuid(),'-','')),
(16,'test',replace(uuid(),'-',''));
受影响的行: 8
时间: 0.038s

得到时间为0.038，这样一来可以很明显节约时间优化SQL

（2）如果在不同客户端插入很多行，可使用INSERT DELAYED语句得到更高的速度，DELLAYED含义是让INSERT语句马上执行，其实数据都被放在内存的队列中。并没有真正写入磁盘。LOW_PRIORITY刚好相反。

（3）将索引文件和数据文件分在不同的磁盘上存放（InnoDB引擎是在同一个表空间的）。

（4）如果批量插入，则可以增加bluk_insert_buffer_size变量值提供速度（只对MyISAM有用）

（5）当从一个文本文件装载一个表时，使用LOAD DATA INFILE，通常比INSERT语句快20倍。

3、GROUP BY的优化

　　在默认情况下，MySQL中的GROUP BY语句会对其后出现的字段进行默认排序（非主键情况），就好比我们使用ORDER BY col1,col2,col3...所以我们在后面跟上具有相同列（与GROUP BY后出现的col1,col2,col3...相同）ORDER BY子句并没有影响该SQL的实际执行性能。

　　那么就会有这样的情况出现，我们对查询到的结果是否已经排序不在乎时，可以使用ORDER BY NULL禁止排序达到优化目的。下面使用EXPLAIN命令分析SQL。

　　在user_1中执行select id, sum(money) form user_1 group by name时，会默认排序（注意group by后的column是非index才会体现group by的排序，如果是primary key，那之前说过了InnoDB默认是按照主键index排好序的）

mysql> select*from user_1;
+----+----------+-------+
| id | name     | money |
+----+----------+-------+
|  1 | Zhangsan |    32 |
|  2 | Lisi     |    65 |
|  3 | Wangwu   |    44 |
|  4 | Lijian   |   100 |
+----+----------+-------+
4 rows in set

不禁止排序，即不使用ORDER BY NULL时：有明显的Using filesort。

当使用ORDER BY NULL禁止排序后，Using filesort不存在

4、ORDER BY 的优化　　

MySQL可以使用一个索引来满足ORDER BY 子句的排序，而不需要额外的排序，但是需要满足以下几个条件：

（1）WHERE 条件和OREDR BY 使用相同的索引：即key_part1与key_part2是复合索引，where中使用复合索引中的key_part1

SELECT*FROM user WHERE key_part1=1 ORDER BY key_part1 DESC, key_part2 DESC;

（2）而且ORDER BY顺序和索引顺序相同：

SELECT*FROM user ORDER BY key_part1, key_part2;

（3）并且要么都是升序要么都是降序：

SELECT*FROM user ORDER BY key_part1 DESC, key_part2 DESC;

但以下几种情况则不使用索引：

（1）ORDER BY中混合ASC和DESC：

SELECT*FROM user ORDER BY key_part1 DESC, key_part2 ASC;

（2）查询行的关键字与ORDER BY所使用的不相同，即WHERE 后的字段与ORDER BY 后的字段是不一样的

SELECT*FROM user WHERE key2 = ‘xxx’ ORDER BY key1;

（3）ORDER BY对不同的关键字使用，即ORDER BY后的关键字不相同

SELECT*FROM user ORDER BY key1, key2;

5、OR的优化

当MySQL使用OR查询时，如果要利用索引的话，必须每个条件列都使独立索引，而不是复合索引（多列索引），才能保证使用到查询的时候使用到索引。

比如我们新建一张用户信息表user_info

mysql> select*from user_info;
+---------+--------+----------+-----------+
| user_id | idcard | name     | address    |
+---------+--------+----------+-----------+
|       1 | 111111 | Zhangsan | Kunming   |
|       2 | 222222 | Lisi     | Beijing   |
|       3 | 333333 | Wangwu   | Shanghai  |
|       4 | 444444 | Lijian   | Guangzhou |
+---------+--------+----------+-----------+
4 rows in set

之后创建ind_name_id(user_id, name)复合索引、id_index(id_index)独立索引，idcard主键索引三个索引。

mysql> show index from user_info;
+-----------+------------+-------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| Table     | Non_unique | Key_name    | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment |
+-----------+------------+-------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| user_info |          0 | PRIMARY     |            1 | idcard      | A         |           4 | NULL     | NULL   |      | BTREE      |         |               |
| user_info |          1 | ind_name_id |            1 | user_id     | A         |           4 | NULL     | NULL   |      | BTREE      |         |               |
| user_info |          1 | ind_name_id |            2 | name        | A         |           4 | NULL     | NULL   | YES  | BTREE      |         |               |
| user_info |          1 | id_index    |            1 | user_id     | A         |           4 | NULL     | NULL   |      | BTREE      |         |               |
+-----------+------------+-------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
4 rows in set

测试一：OR连接两个有单独索引的字段，整个SQL查询才会用到索引(index_merge)，并且我们知道OR实际上是把每个结果最后UNION一起的。

mysql> explain select*from user_info where user_id=1 or idcard='222222';
+----+-------------+-----------+------------+-------------+------------------------------+---------------------+---------+------+------+----------+----------------------------------------------------+
| id | select_type | table     | partitions | type        | possible_keys                | key                 | key_len | ref  | rows | filtered | Extra                                              |
+----+-------------+-----------+------------+-------------+------------------------------+---------------------+---------+------+------+----------+----------------------------------------------------+
|  1 | SIMPLE      | user_info | NULL       | index_merge | PRIMARY,ind_name_id,id_index | ind_name_id,PRIMARY | 4,62    | NULL |    2 |      100 | Using sort_union(ind_name_id,PRIMARY); Using where |
+----+-------------+-----------+------------+-------------+------------------------------+---------------------+---------+------+------+----------+----------------------------------------------------+
1 row in set

测试二：OR使用复合索引的字段name，与没有索引的address，整个SQL都是ALL全表扫描的

mysql> explain select*from user_info where name='Zhangsan' or address='Beijing';
+----+-------------+-----------+------------+------+---------------+------+---------+------+------+----------+-------------+
| id | select_type | table     | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra       |
+----+-------------+-----------+------------+------+---------------+------+---------+------+------+----------+-------------+
|  1 | SIMPLE      | user_info | NULL       | ALL  | NULL          | NULL | NULL    | NULL |    4 |    43.75 | Using where |
+----+-------------+-----------+------------+------+---------------+------+---------+------+------+----------+-------------+
1 row in set

交换OR位置并且使用另外的复合索引的列，也是ALL全表扫描：

mysql> explain select*from user_info where address='Beijing' or user_id=1;
+----+-------------+-----------+------------+------+----------------------+------+---------+------+------+----------+-------------+
| id | select_type | table     | partitions | type | possible_keys        | key  | key_len | ref  | rows | filtered | Extra       |
+----+-------------+-----------+------------+------+----------------------+------+---------+------+------+----------+-------------+
|  1 | SIMPLE      | user_info | NULL       | ALL  | ind_name_id,id_index | NULL | NULL    | NULL |    4 |    43.75 | Using where |
+----+-------------+-----------+------------+------+----------------------+------+---------+------+------+----------+-------------+
1 row in set

6、优化嵌套查询

使用嵌套查询有时候可以使用更有效的JOIN连接代替，这是因为MySQL中不需要在内存中创建临时表完成SELECT子查询与主查询两部分查询工作。但是并不是所有的时候都成立，最好是在on关键字后面的列有索引的话，效果会更好！

比如在表major中major_id是有索引的：

select * from student u left join major m on u.major_id=m.major_id where m.major_id is null;

而通过嵌套查询时，在内存中创建临时表完成SELECT子查询与主查询两部分查询工作，会有一定的消耗

select * from student u where major_id not in (select major_id from major);

7、使用SQL提示

SQL提示（SQL HINT）是优化数据库的一个重要手段，就是往SQL语句中加入一些人为的提示来达到优化目的。下面是一些常用的SQL提示：

（1）USE INDEX：使用USE INDEX是希望MySQL去参考索引列表，就可以让MySQL不需要考虑其他可用索引，其实也就是possible_keys属性下参考的索引值

mysql> explain select* from user_info use index(id_index,ind_name_id) where user_id>0;
+----+-------------+-----------+------------+------+----------------------+------+---------+------+------+----------+-------------+
| id | select_type | table     | partitions | type | possible_keys        | key  | key_len | ref  | rows | filtered | Extra       |
+----+-------------+-----------+------------+------+----------------------+------+---------+------+------+----------+-------------+
|  1 | SIMPLE      | user_info | NULL       | ALL  | ind_name_id,id_index | NULL | NULL    | NULL |    4 |      100 | Using where |
+----+-------------+-----------+------------+------+----------------------+------+---------+------+------+----------+-------------+
1 row in set

mysql> explain select* from user_info use index(id_index) where user_id>0;
+----+-------------+-----------+------------+------+---------------+------+---------+------+------+----------+-------------+
| id | select_type | table     | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra       |
+----+-------------+-----------+------------+------+---------------+------+---------+------+------+----------+-------------+
|  1 | SIMPLE      | user_info | NULL       | ALL  | id_index      | NULL | NULL    | NULL |    4 |      100 | Using where |
+----+-------------+-----------+------------+------+---------------+------+---------+------+------+----------+-------------+
1 row in set

（2）IGNORE INDEX忽略索引

我们使用user_id判断，用不到其他索引时，可以忽略索引。即与USE INDEX相反，从possible_keys中减去不需要的索引，但是实际环境中很少使用。

mysql> explain select* from user_info ignore index(primary,ind_name_id,id_index) where user_id>0;
+----+-------------+-----------+------------+------+---------------+------+---------+------+------+----------+-------------+
| id | select_type | table     | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra       |
+----+-------------+-----------+------------+------+---------------+------+---------+------+------+----------+-------------+
|  1 | SIMPLE      | user_info | NULL       | ALL  | NULL          | NULL | NULL    | NULL |    4 |    33.33 | Using where |
+----+-------------+-----------+------------+------+---------------+------+---------+------+------+----------+-------------+
1 row in set

（3）FORCE INDEX强制索引

比如where user_id > 0，但是user_id在表中都是大于0的，自然就会进行ALL全表搜索，但是使用FORCE INDEX虽然执行效率不是最高（where user_id > 0条件决定的）但MySQL还是使用索引。

mysql> explain select* from user_info where user_id>0;
+----+-------------+-----------+------------+------+----------------------+------+---------+------+------+----------+-------------+
| id | select_type | table     | partitions | type | possible_keys        | key  | key_len | ref  | rows | filtered | Extra       |
+----+-------------+-----------+------------+------+----------------------+------+---------+------+------+----------+-------------+
|  1 | SIMPLE      | user_info | NULL       | ALL  | ind_name_id,id_index | NULL | NULL    | NULL |    4 |      100 | Using where |
+----+-------------+-----------+------------+------+----------------------+------+---------+------+------+----------+-------------+
1 row in set

之后强制使用独立索引id_index(user_id)：

mysql> explain select* from user_info force index(id_index) where user_id>0;
+----+-------------+-----------+------------+-------+---------------+----------+---------+------+------+----------+-----------------------+
| id | select_type | table     | partitions | type  | possible_keys | key      | key_len | ref  | rows | filtered | Extra                 |
+----+-------------+-----------+------------+-------+---------------+----------+---------+------+------+----------+-----------------------+
|  1 | SIMPLE      | user_info | NULL       | range | id_index      | id_index | 4       | NULL |    4 |      100 | Using index condition |
+----+-------------+-----------+------------+-------+---------------+----------+---------+------+------+----------+-----------------------+
1 row in set

总结

　　（1）很多时候数据库的性能是由于不合适（是指效率不高，可能会导致锁表等）的SQL语句造成，本篇博文只是介绍简单的SQL优化

　　（2）其中有些优化在真正开发中是用不到的，但是一旦出问题性能下降的时候需要去一一分析。

转自：https://www.cnblogs.com/jian0110/p/9410981.html

MySQL优化

常用的优化步骤

一、查看SQL执行频率

二、定位效率低的SQL

三、 查看分析效率低的SQL

四、 关于索引的优化

1、使用索引优化的举例

2、如何高效使用索引？

3、哪些情况下即使有索引也用不到？

4、查看索引的使用情况

常用优化

前言

1、大批量插入数据优化

2、INSERT的优化

3、GROUP BY的优化

4、ORDER BY 的优化

5、OR的优化

6、优化嵌套查询

7、使用SQL提示

总结

三、查看分析效率低的SQL

四、关于索引的优化

4、ORDER BY 的优化　　