MySQL数据库性能优化由浅入深（表设计慢查询SQL索引优化Explain分析Show Profile分析配置优化）

Posted 袁袁袁袁满

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了MySQL数据库性能优化由浅入深（表设计慢查询SQL索引优化Explain分析Show Profile分析配置优化）相关的知识，希望对你有一定的参考价值。

文章目录

0 SQL性能分析

SQL性能下降原因：

  • 1、查询语句写的烂
  • 2、索引失效（数据变更）
  • 3、关联查询太多join（设计缺陷或不得已的需求）
  • 4、服务器调优及各个参数设置（缓冲、线程数等）

通常SQL调优过程：

  • 观察，至少跑1天，看看生产的慢SQL情况。
  • 开启慢查询日志，设置阙值，比如超过5秒钟的就是慢SQL，并将它抓取出来。
  • explain + 慢SQL分析。
  • show profile。
  • 运维经理 or DBA，进行SQL数据库服务器的参数调优。

总结：

  • 1、慢查询的开启并捕获
  • 2、explain + 慢SQL分析（没索引的先建索引）
  • 3、show profile查询SQL在mysql服务器里面的执行细节和生命周期情况
  • 4、SQL数据库服务器的参数调优

数据库的分类

  • 关系型数据库：mysq/oracle/db2/informix/sysbase/sql server
  • 非关系型数据库：(特点:面向对象或者集合)
  • NoSql数据库：MongoDB(特点是面向文档)

1 表的设计合理化

1.1 为什么需要范式

一个软件项目基本都会用到数据库，项目开发前期分析客户的业务和数据处理需求，然后设计数据库的E-R模型图，确认需求信息的正确和完整。再就要将E-R图转换为多张表，表设计后，很可能结构不合理，出现数据重复保存，简称数据的冗余，这对数据的增删改查带来很多后患，所以我们需要审核是否合理，就像施工图设计后，还需要其他机构进行审核图纸是否设计合理一样。

如何审核呢？需要一些有关数据库设计的理论指导规则，这些规则业界简称数据库的范式。数据库范式为数据库的设计、开发提供了一个可参考的典范。

1.2 三范式原理

通俗地理解三个范式，对于数据库设计大有好处。在数据库设计中，为了更好地应用三个范式，就必须通俗地理解三个范式(通俗地理解是够用的理解，并不是最科学最准确的理解

第一范式: 1NF是对属性的原子性约束，要求属性(列)具有原子性，不可再分解; (只要是关系型数据库都满足1NF)

第二范式: 2NF是对记录的惟一性约束，要求记录有惟一标识，即实体的惟一性;

第三范式: 3NF是对字段冗余性的约束，它要求字段没有冗余。没有冗余的数据库设计可以做到。

但是，没有冗余的数据库未必是最好的数据库，有时为了提高运行效率，就必须降低范式标准，适当保留冗余数据。具体做法是:在概念数据模型设计时遵守第三范式，降低范式标准的工作放到物理数据模型设计时考虑。降低范式就是增加字段，允许冗余。

1.3 什么样的表才满足三范式

表的范式，是首先符合1NF, 才能满足2NF,进一步满足3NF

1NF：即表的列的具有原子性，不可再分解，即列的信息，不能分解,只有数据库是关系型数据库

2NF：表中的记录是唯一的，就满足2NF,通常我们设计一个主键来实现

3NF：即表中不要有冗余数据，就是说，表的信息，如果能够被推导出来，就不应该单独的设计一个字段来存放

反3NF：在表1->n的情况下，为了提高效率可能会在1这张表设计字段提速

2 慢查询

2.1 慢查询介绍

  • MySQL的慢查询日志是MySQL提供的一种日志记录，它用来记录在MySQL中响应时间超过阀值的语句，具体指运行时间超过long_query_time值的SQL，则会被记录到慢查询日志中。
  • 具体指运行时间超过long_query_time值的SQL，则会被记录到慢查询日志中。long_query_time的默认值为10，意思是运行10秒以上的语句。
  • 由他来查看哪些SQL超出了我们的最大忍耐时间值，比如一条sql执行超过5秒钟，我们就算慢SQL，希望能收集超过5秒的sql，结合之前explain进行全面分析

2.2 慢查询步骤

问题：如何从一个大项目中，迅速的定位执行速度慢的语句.(定位慢查询)

1）首先我们了解mysql数据库的一些运行状态如何查询(比如想知道当前mysql运行的时间一共执行了多少次selecthupdate/delete,当前连接)

  • 当前时间：show status like 'uptime';
  • 共执行多少次select：show stauts like 'com_select';
  • 共执行多少次update：show stauts like 'com_update';
  • 共执行多少次delete：show stauts like 'com_delete';

show [session/global] status like ... 如果你不写 [session/global] 默认是session会话，指取出当前窗口的执行，如果你想看所有(从mysql启动到现在，则应该global)

  • 当前MySQL连接数：show status like 'connections';
  • 显示慢查询次数：show status like 'slow_queries';

2）开启慢查询日志

操作说明：

默认情况下，MySQL数据库没有开启慢查询日志，需要我们手动来设置这个参数。

当然，如果不是调优需要的话，一般不建议启动该参数，因为开启慢查询日志会或多或少带来一定的性能影响。慢查询日志支持将日志记录写入文件。

查看是否开启及如何开启：

  • 默认： SHOW VARIABLES LIKE '%slow_query_log%'; [ˈveəriəbls]
  • 开启：set global slow_query_log=1;，只对当前数据库生效，如果MySQL重启后则会失效

如果要永久生效，就必须修改配置文件my.cnf(其它系统变量也是如此)

修改my.cnf文件，[mysqld] 下增加或修改参数slow_query_log和slow_query_log_file后，然后重启MySQL服务器。也即将如下两行配置进my.cnf文件

slow_query_log =1
slow_query_log_file=/var/lib/mysqatguigu-slow.log

关于慢查询的参数slow_query_log_file，它指定慢查询日志文件的存放路径，系统默认会给一个缺省的文件host_name-slow.log（如果没有指定参数slow_query_log_file的话）

3）开启了慢查询日志后，什么样的SQL才会记录到慢查询日志里面呢？

这个是由参数long_query_time控制，默认情况下long_query_time的值为10秒，命令：SHOW VARIABLES LIKE 'long_query_time%';

可以使用命令修改，也可以在my.cnf参数里面修改。

假如运行时间正好等于long_query_time的情况，并不会被记录下来。也就是说，在mysql源码里是判断大于long_query_time，而非大于等于。

命名修改慢SQL阈值时间：set global long_query_time=3; [ˈɡləʊbl]

看不到修改情况的话，重开连接，或者换一个语句：show global variables like 'long_query_time';

4）记录慢SQL并后续分析

假设我们成功设置慢SQL阈值时间为3秒（set global long_query_time=3;）。

模拟超时SQL：select sleep(4);

查询当前系统中有多少条慢查询记录：show global status like '%Slow_queries%'; [ˈsteɪtəs]

在配置文件中设置慢SQL阈值时间（永久生效）：

#[mysqld]下配置:
slow_query_log=1;
slow_query_log_file=/var/lib/mysql/atguigu-slow.log
long_query_time=3;
log_output=FILE;

3 添加适当索引

3.1 索引是什么

MySQL官方对索引的定义为：索引（Index）是帮助MySQL高效获取数据的数据结构（索引的本质是数据结构，排序+查询两种功能）。

索引可以理解为：排好序的快速查找数据结构

下图就是一种可能的索引方式示例：

假如：找4号这本书，扫码得到对应的编号为91，91比34大往右边找，91比89大往右边找，然后找到（比较三次后就可以找到，然后检索出对应的物理地址）

为了加快Col2的查找，可以维护一个右边所示的二叉查找树，每个节点分别包含索引键值和一个指向对应数据记录物理地址的指针，这样就可以运用二叉查找在一定的复杂度内获取到相应数据，从而快速的检索出符合条件的记录

结论：在数据之外，数据库系统还维护着满足特定查找算法的数据结构，这些数据结构以某种方式引用(指向）数据，这样就可以在这些数据结构上实现高级查找算法。这种数据结构就是索引

一般来说索引本身也很大，不可能全部存储在内存中，因此索引往往以索引文件的形式存储的磁盘上。

我们平常所说的索引，如果没有特别指明，都是指B树（多路搜索树，并不一定是二叉的）结构组织的索引。其中聚集索引，次要索引，覆盖索引，复合索引，前缀索引，唯一索引默认都是使用B+树索引，统称索引。当然，除了B+树这种类型的索引之外，还有哈稀索引(hash index)等

3.2 索引优劣势

优势：

  • 类似大学图书馆建书目索引，提高数据检索的效率，降低数据库的IO成本。
  • 通过索引列对数据进行排序，降低数据排序的成本，降低了CPU的消耗。

劣势：

  • 实际上索引也是一张表，该表保存了主键与索引字段，并指向实体表的记录，所以索引列也是要占用空间的（占空间）
  • 虽然索引大大提高了查询速度，同时却会降低更新表的速度，如对表进行INSERT、UPDATE和DELETE。因为更新表时，MySQL不仅要保存数据，还要保存一下索引文件每次更新添加了索引列的字段，都会调整因为更新所带来的键值变化后的索引信息。
  • 索引只是提高效率的一个因素，如果你的MysQL有大数据量的表，就需要花时间研究建立最优秀的索引，或优化查询

3.3 索引分类和建索引命令语句

主键索引：索引值必须是唯一的，且不能为NULL

  • 第一种：CREATE TABLE table_name(id int PRIMARY KEY auto_increment,name varchar(10));
  • 第二种： ALTER TABLE table_name ADD PRIMARY KEY (columnName);

普通索引：索引值可出现多次

  • 第一种：CREATE INDEX index_name on table_name(columnName);
  • 第二种：ALTER TABLE table_name ADD INDEX index_name (columnName);

全文索引：主要是针对文本的检索，如：文章，全文索引只针对MyISAM引擎有效，并且只针对英文内容生效

  • 建表时创建

    #建表
CREATE TABLE articles(
	id INT UNSIGNED ATUO_INCREMENT NOT NULL PRIMARY KEY,
	title VARCHAR(200),
	body TEXT,
	FULLTEXT(title,body)
)engine=myisam charset utf8;	#指定存储引擎
#使用
select * from articles where match(title,body) against('英文内容'); #只针对英语内容生效

#说明
#1、在mysql中fultext索引只针对 myisam 生效
#2、mysq1自己提供的flltext只针对英文生效->sphinx (coreseek)技术处理中文工
#3、使用方法是match(字段名...) against(‘关键字')
#4、全文索引一个叫停止词，因为在一个文本中创建索引是一个无穷大的数，因此对一些常用词和字符就不会创建，这些词称为停止词

  • ALTER TABLE table_name ADD FULLTEXT index_name (columnName);

唯一索引：索引列的值必须唯一，但允许有空值NULL，并可以有多个。

  • 第一种： CREATE UNIQUE INDEX index_name ON table_name(columnName);
  • 第二种：ALTER TABLE table_name ADD UNIQUE INDEX index_name ON (columnName);

单值索引：即一个索引只包含单个列，一个表可以有多个单列索引。

  • 第一种： CREATE INDEX index_name ON table_name(columnName);
  • 第二种：ALTER TABLE table_name ADD INDEX index_name ON (columnName);
select * from user where name='';
//经常查name字段，为其建索引
create index idx_user_name on user(name);

复合索引：即一个索引包含多个列

  • 第一种： CREATE INDEX index_name ON table_name(columnName1，columnName2...);
  • 第二种：ALTER TABLE table_name ADD INDEX index_name ON (columnName1，columnName2...);
select * from user where name='' and email='';
//经常查name和email字段，为其建索引
create index idx_user_name on user(name, email);

查询索引

  • 第一种：SHOW INDEX FROM table_name;
  • 第二种：SHOW KEYS FROM table_name;

删除索引

  • 第一种： DROP INDEX index_name ON table_name;
  • 第二种：ALTER TABLE table_name DROP INDEX index_name;
  • 删除主键索引：ALTER TBALE table_name DROP PRIMARY KEY;

查看索引的使用情况：show status like 'Handler_ read%';

  • handler_ read_ key:这个值越高越好，越高表示使用索引查询到的次数。
  • handler_ read_ rnd_next:这 个值越高，说明查询低效。

修改索引通常是先删除再重新建

3.4 创建索引情况分析

哪些情况适合建索引：

  • 主键自动建立唯一索引
  • 频繁作为查询条件（where）的字段应该创建索引
  • 查询中与其它表关联的字段，外键关系建立索引
  • 单键/组合索引的选择问题，who?(在高并发下倾向创建组合索引)
  • 查询中排序的字段，排序字段若通过索引去访问将大大提高排序速度
  • 查询中统计或者分组字段

哪些情况不适合建索引：

  • Where条件里用不到的字段不创建索引
  • 表记录太少（300w以上建）
  • 经常增删改的表（提高了查询速度，同时却会降低更新表的速度，如对表进行INSERT、UPDATE和DELETE。因为更新表时，MySQL不仅要保存数据，还要保存一下索引文件）
  • 数据重复且分布平均的表字段，因此应该只为最经常查询和最经常排序的数据列建立索引。注意，如果某个数据列包含许多重复的内容，为它建立索引就没有太大的实际效果。（比如：国籍、性别）

假如一个表有10万行记录，有一个字段A只有T和F两种值，且每个值的分布概率天约为50%，那么对这种表A字段建索引一般不会提高数据库的查询速度。

索引的选择性：是指索引列中不同值的数目与表中记录数的比。

如果一个表中有2000条记录，表索引列有1980个不同的值，那么这个索引的选择性就是1980/2000=0.99。一个索引的选择性越接近于1，这个索引的效率就越高

4 Explain分析（重点）

4.1 Explain介绍

使用EXPLAIN关键字可以模拟优化器执行SQL语句，分析你的查询语句或是结构的性能瓶颈 在 select 语句之前增加 explain 关键字，MySQL 会在查询上设置一个标记，执行查询会返回执行计划的信息， 而不是执行这条SQL 注意：如果 from 中包含子查询，仍会执行该子查询，将结果放入临时表中

Explain官方文档：官网地址

Explain的作用：

  • 表的读取顺序
  • 数据读取操作的操作类型
  • 哪些索引可以使用
  • 哪些索引被实际使用
  • 表之间的引用
  • 每张表有多少行被优化器查询

使用Explain：

  • explain + sql语句
  • 执行计划包含的信息（重点） ：| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
  • 面试重点：id、type、key、rows、Extra
mysql> select * from tbl_emp;
+----+------+--------+
| id | NAME | deptId |
+----+------+--------+
|  1 | z3   |      1 |
|  2 | z4   |      1 |
|  3 | z5   |      1 |
|  4 | w5   |      2 |
|  5 | w6   |      2 |
|  6 | s7   |      3 |
|  7 | s8   |      4 |
|  8 | s9   |     51 |
+----+------+--------+
8 rows in set (0.00 sec)

mysql> explain select * from tbl_emp;
+----+-------------+---------+------------+------+---------------+------+---------+------+------+----------+-------+
| id | select_type | table   | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra |
+----+-------------+---------+------------+------+---------------+------+---------+------+------+----------+-------+
|  1 | SIMPLE      | tbl_emp | NULL       | ALL  | NULL          | NULL | NULL    | NULL |    8 |   100.00 | NULL  |
+----+-------------+---------+------------+------+---------------+------+---------+------+------+----------+-------+
1 row in set, 1 warning (0.00 sec)

4.2 id（表的读取顺序）

select查询的序列号，包含一组数字，表示查询中执行select子句或操作表的顺序

三种情况：

  • 1、id相同，执行顺序由上至下（t1、t3、t2）

  • 2、id不同，如果是子查询，id的序号会递增，id值越大优先级越高，越先被执行（t3、t1、t2）

  • 3、id相同不同，同时存在。先走数字大的，数字相同的由上至下（t3、s1、t2）

4.3 select_type（ 数据读取操作的操作类型）

查询的类型，主要是用于区别普通查询、联合查询、子查询等的复杂查询。

  • SIMPLE [ˈsɪnpl] ：简单的select查询,查询中不包含子查询或者UNION
  • PRIMARY：查询中若包含任何复杂的子部分，最外层查询则被标记为（最后加载的那个）
  • SUBQUERY [ˈkwɪəri] ：在SELECT或WHERE列表中包含了子查询
  • DERIVED [dɪˈraɪvd]：在FROM列表中包含的子查询被标记为DERIVED（衍生）MySQL会递归执行这些子查询，把结果放在临时表里
  • UNION [ˈjuːniən]：若第二个SELECT出现在UNION之后，则被标记为UNION；若UNION包含在FROM子句的子查询中外层SELECT将被标记为：DERIVED
  • UNION RESULT [rɪˈzʌlt] ：从UNION表获取结果的SELECT（两个select语句用UNION合并）

4.4 table（显示执行的表名）

这一列表示 explain 的一行正在访问哪个表。

当 from 子句中有子查询时，table列是 格式，表示当前查询依赖 id=N 的查询，于是先执行 id=N 的查询。 当有 union 时，UNION RESULT 的 table 列的值为<union1,2>，1和2表示参与 union 的 select 行id。

4.5 type（访问类型排列）

显示查询使用了何种类型

访问类型排列：system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index >ALL

type常用八种类型：

结果值从最好到最坏依次是（重点）：：system > const > eq_ref > ref > range > index > ALL

一般来说，得保证查询至少达到range级别，最好能达到ref

详细说明

  • system：表只有一行记录（等于系统表），这是const类型的特列，平时不会出现，这个也可以忽略不计。

  • const：表示通过索引一次就找到了，const用于比较primary key或者unique索引。因为只匹配一行数据，所以很快如将主键置于where列表中，MySQL就能将该查询转换为一个常量。

  • eq_ref：唯一性索引扫描，对于每个索引键，表中只有一条记录与之匹配。常见于主键或唯一索引扫描。

  • ref：非唯一性索引扫描，返回匹配某个单独值的所有行，本质上也是一种索引访问，它返回所有匹配某个单独值的行，然而，它可能会找到多个符合条件的行，所以他应该属于查找和扫描的混合体

  • range：只检索给定范围的行,使用一个索引来选择行。key列显示使用了哪个索引一般就是在你的where语句中出现了between、<、>、in等的查询。这种范围扫描索引扫描比全表扫描要好，因为它只需要开始于索引的某一点，而结束语另一点，不用扫描全部索引

  • index：Full Index Scan，index与ALL区别为index类型只遍历索引列。这通常比ALL快，因为索引文件通常比数据文件小（也就是说虽然all和Index都是读全表，但index是从索引中读取的，而all是从硬盘中读的）

  • all：Full Table Scan，将遍历全表以找到匹配的行

    工作案例：经理这条SQL我跑了一下Explain分析，在系统上可能会有ALL全表扫描的情况，建议尝试一下优化。我把这条SQL改了改，我优化后是这么写，这个效果已经从ALL变成了…

4.6 possible_keys（哪些索引可以使用）

显示可能应用在这张表中的索引，一个或多个。查询涉及到的字段火若存在索引，则该索引将被列出，但不一定被查询实际使用（系统认为理论上会使用某些索引）

4.7 key（哪些索引被实际使用）

实际使用的索引。如果为NULL，则没有使用索引（要么没建，要么建了失效）

查询中若使用了覆盖索引，则该索引仅出现在key列表中

覆盖索引：建的索引字段和查询的字段一致，如下图

4.8 key_len（消耗的字节数）

表示索引中使用的字节数，可通过该列计算查询中使用的索引的长度。在不损失精确性的情况下，长度越短越好

key_len显示的值为索引字段的最大可能长度，并非实际使用长度，即key_len是根据表定义计算而得，不是通过表内检索出的

4.9 ref（表之间的引用）

显示索引的哪一列被使用了，如果可能的话，是一个常数。哪些列或常量被用于查找索引列上的值。

4.10 rows（每张表有多少行被优化器查询）

根据表统计信息及索引选用情况，大致估算出找到所需的记录所需要读取的行数（越小越好）

未建索引时：

建索引后：扫描行数减少

4.11 Extra [ˈekstrə]

包含不适合在其他列中显示但十分重要的额外信息

信息种类：Using filesort 、Using temporary 、Using index 、Using where 、Using join buffer 、impossible where 、select tables optimized away 、distinct

Using filesort（需要优化）

说明mysql会对数据使用一个外部的索引排序，而不是按照表内的索引顺序进行读取。MySQL中无法利用索引完成的排序操作称为"文件排序"

Using temporary（需要优化）

使了用临时表保存中间结果，MysQL在对查询结果排序时使用临时表。常见于排序order by和分组查询group by

Using index（good）

表示相应的select操作中使用了覆盖索引（Covering Index），避免访问了表的数据行，效率不错！

  • 情况一：

  • 情况二：

覆盖索引 / 索引覆盖（Covering Index）。

  • 理解方式一：就是select的数据列只用从索引中就能够取得，不必读取数据行，MySQL可以利用索引返回select列表中的字段，而不必根据索引再次读取数据文件,换句话说查询列要被所建的索引覆盖。
  • 理解方式二：索引是高效找到行的一个方法，但是一般数据库也能使用索引找到一个列的数据，因此它不必读取整个行。毕竟索引叶子节点存储了它们索引的数据；当能通过读取索引就可以得到想要的数据，那就不需要读取行了。一个索引包含了（或覆盖了）满足查询结果的数据就叫做覆盖索引。

注意：

  • 如果要使用覆盖索引，一定要注意select列表中只取出需要的列，不可select*
  • 因为如果将所有字段一起做索引会导致索引文件过大，查询性能下降

Using where：表明使用了where过滤。

Using join buffer：使用了连接缓存

impossible where：where子句的值总是false，不能用来获取任何元组

select tables optimized away

在没有GROUPBY子句的情况下，基于索引优化MIN/MAX操作，或者对于MyISAM存储引擎优化COUNT(*)操作，不必等到执行阶段再进行计算，查询执行计划生成的阶段即完成优化。

distinct

优化distinct操作，在找到第一匹配的元组后即停止找同样值的动作。

4.12 练习

写出下图的表的执行顺序

第一行（执行顺序4）：id列为1，表示是union里的第一个select，select_type列的primary表示该查询为外层查询，table列被标记为，表示查询结果来自一个衍生表，其中derived3中3代表该查询衍生自第三个select查询，即id为3的select。【select d1.name… 】

第二行（执行顺序2）：id为3，是整个查询中第三个select的一部分。因查询包含在from中，所以为derived。【select id,namefrom t1 where other_column=’’】

第三行（执行顺序3）：select列表中的子查询select_type为subquery，为整个查询中的第二个select。【select id from t3】

第四行（执行顺序1）：select_type为union，说明第四个select是union里的第二个select，最先执行【select name,id from t2】

第五行（执行顺序5）：代表从union的临时表中读取行的阶段，table列的<union1,4>表示用第一个和第四个select的结果进行union操作。【两个结果union操作】

5 索引优化

5.1 索引单表优化案例

建表：

CREATE TABLE IF NOT EXISTS article(
	id INT(10) UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT,
	author_id INT(10) UNSIGNED NOT NULL,
	category_id INT(10) UNSIGNED NOT NULL,
	views INT(10) UNSIGNED NOT NULL,
	comments INT(10) UNSIGNED NOT NULL,
	title VARCHAR(255) NOT NULL,
	content TEXT NOT NULL
);

INSERT INTO article(author_id,category_id,views,comments,title,content)
VALUES
(1,1,1,1,'1','1'),
(2,2,2,2,'2','2'),
(1,1,3,3,'3','3');

//查询
mysql> select * from article;
+----+-----------+-------------+-------+----------+-------+---------+
| id | author_id | category_id | views | comments | title | content |
+----+-----------+-------------+-------+----------+-------+---------+
|  1 |         1 |           1 |     1 |        1 | 1     | 1       |
|  2 |         2 |           2 |     2 |        2 | 2     | 2       |
|  3 |         1 |           1 |     3 |        3 | 3     | 3       |
+----+-----------+-------------+-------+----------+-------+---------+
3 rows in set (0.00 sec)

案例

要求：查询 category_id 为 1 且 comments 大于1 的情况下，views 最多的 article_id

//功能实现
mysql> SELECT id, author_id FROM article WHERE category_id = 1 AND comments > 1 ORDER BY views DESC LIMIT 1;
+----+-----------+
| id | author_id |
+----+-----------+
|  3 |         1 |
+----+-----------+
1 row in set (0.00 sec)

//explain分析
mysql> explain SELECT id, author_id FROM article WHERE category_id = 1 AND comments > 1 ORDER BY views DESC LIMIT 1;
+----+-------------+---------+------------+------+---------------+------+---------+------+------+----------+-----------------------------+
| id | select_type | table   | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra                       |
+----+-------------+---------+------------+------+---------------+------+---------+------+------+----------+-----------------------------+
|  1 | SIMPLE      | article | NULL       | ALL  | NULL          | NULL | NULL    | NULL |    3 |    33.33 | Using where; Using filesort |
+----+-------------+---------+------------+------+---------------+------+---------+------+------+----------+-----------------------------+
1 row in set, 1 warning (<
以上是关于MySQL数据库性能优化由浅入深（表设计慢查询SQL索引优化Explain分析Show Profile分析配置优化）的主要内容，如果未能解决你的问题，请参考以下文章
 

 #yyds干货盘点# MySQL性能优化：为什么查询速度这么慢


 mysql数据库优化之表的设计和慢查询定位


 mysql性能优化-慢查询分析,优化索引最佳实践


 《高性能MySQL》读书笔记


 性能调优之MYSQL高并发优化


 170727MySQL查询性能优化