MySQL 优化 —— SQL优化概述（优化专题开篇词）

引言

最近为了研究索引的知识，特地去MySQL 官网研读了一番，发现MySQL官网有比较全面的MySQL优化方案和知识背景，所以希望通过一系列文章，将官网的知识翻译总结一下，避免日后去网上胡乱搜索产生不必要的知识勘误风险。

本系列文章标题都会以 “MySQL 优化” 前缀开头，有些可能是翻译，也会有少量自己的总结和试验，针对 MySQL 5.7 版本进行。当然也并不会全部将官网的优化专题翻译完，可能会挑选我自己认为比较重点的部分进行翻译和总结。

我的翻译文章大多数都没有精推细敲的进行翻译，可能有人会比较失望，但考虑到我的工作状态和时间不允许我过度的专注于翻译工作，不过我依然会秉承最质朴的求真精神，把翻译工作做好。同时，为了避免个人英语水平对原文知识的误读，我会在每篇翻译文章的引言部分贴出原文的 URL 方便他人去查阅和对比阅读增加知识的准确性，同时我更希望能有人站出来指正我的错别字和翻译问题。

再次强调一下我的翻译风格，并不是精推细敲型，会以一种比较松散但并不丢失原意的方式来翻译MySQL官方文档。如下是我的翻译示例：

原文：To make a slow SELECT ... WHERE query faster, the first thing to check is whether you can add an index.

我的翻译：为了让一个 SELECT ... WHERE 执行的更快，第一件需要考虑的事情就是——我们是否可以为其建立索引。

这就是——“比较松散，但无伤原意”，希望大家多多指正。

以下部分翻译自MySQL官网：https://dev.mysql.com/doc/refman/5.7/en/select-optimization.html

SQL优化需要考虑的方面

查询，以 SELECT 子句的形式，执行着对数据库的全部查找操作。调试这些语句是优先级最高的，不论是在动态web页面实现次秒级别的响应，还是缩短生成大量夜间报告的时间，都是如此。

除了 SELECT 语句，这些用于查询性能优化的调试技术同样会应用于构建诸如 CREATE TABLE... AS SELECT, INSERT INTO ...SELECT, 和 DELETE 语句中的 WHERE 子句等。这些语句需要额外的性能考虑，这是因为他们结合了写和读的操作。

最主要的性能优化考虑有如下这些：

1、为了让一个 SELECT ... WHERE 执行的更快，第一件需要考虑的事情就是——我们是否可以为其建立索引。给 WHERE 子句中的字段建立索引，以此来加速求值、过滤以及对结果集进行的最终检索。为了避免浪费磁盘空间，构建一个“小集合”式的复合索引来加速许多相关的查询。（博主：意思是复合索引不仅可以减少对磁盘空间的过度占用，同时也可以支持许多相关的查询，因此，不要创建太多的单一索引，可以用复合索引的地方，要优先考虑复合索引）

索引在涉及使用诸如 join 和外键等的多表查询时尤其重要。你可以使用 EXPLAIN 语句来判断在 SELECT 中究竟用到了哪种索引。

2、单独调试非常耗时的查询的每一个部分，如MySQL函数调用等。一个函数可以被结果集中的每条记录执行一遍，也可以被表表中的每条记录执行一遍，这取决于查询的结构，即我们如何构建我们的查询语句。

3、尽量减少查询中全表扫描的次数，特别是大表。

4、定期使用 ANALYZE TABLE 语句来进行表统计，这样SQL优化器才可以有更多的信息来构建有效的执行计划。

5、学习调试技术，索引技术，和配置参数，它们都是特定于每张表的存储引擎的。InnoDB和MyISAM 都有一系列的教程来使我们的查询保持更高的性能。

6、调整MySQL用于缓存的内存区域大小和配置。以有效的方式使用 InnoDB buffer pool，MyISAM key cache，和 MySQL 查询缓存，重复的查询之所以会运行的更快，是因为第二次之后都是从内存中获取数据的。

7、即便是使用内存作为缓存的查询，你可能依然需要更深入的优化以便使它们需要更少的缓存内存，让你的应用程序具备更好的可扩展性。可扩展性意味着你的应用程序可以处理更多同时访问的用户，更大的请求量，而不会产生比较大的性能落差。

8、处理锁的相关问题。在你的查询速度可能会被其他同时访问表的 session 影响到的地方处理锁的问题。