在进行库表结构设计时，我们要考虑到以后的查询要如何的使用这些表，同样，编写 SQL 语句的时候也要考虑到如何使用到目前已经存在的索引，或是如何增加新的索引才能提高查询的性能。
想要对存在性能问题的查询进行优化，需要能够找到这些查询，下面先看下如何获取有性能问题的SQL。
如何设计最优的数据库表结构，如何建立最好的索引，以及如何扩展数据库的查询，这些对于高性能来说都是必不可少的。但是只有这些还不够，要获得良好的数据库性能，我们还要设计合理的数据库查询，如果查询设计的很糟糕，即使增加再多的只读从库，表结构设计的再合理，索引再合适，只要查询不能使用到这些东西，也无法实现高性能的查询。所以说查询优化，索引优化，库表结构优化需要齐头并进。
1.获取有性能问题的SQL
获取有性能问题的 SQL 的三种方法：
通过用户反馈获取存在性能问题的 SQL;
通过慢查日志获取存在性能问题的 SQL;
实时获取存在性能问题的 SQL;
1.慢查询日志获取性能问题SQL
MySQL 慢查询日志是一种性能开销比较低的获取存在性能问题 SQL 的解决方案，其主要的性能开销在磁盘 IO 和存储日志所需要的磁盘空间。对于磁盘 IO 来说，由于写日志是顺序存储，开销基本上忽略不计，所以主要需要关注的还是磁盘空间。
MySQL 提供了以下参数用于控制慢查询日志：
slow_query_log：是否启动慢查询日志，默认不启动，on 启动;
slow_query_log_file：指定慢查询日志的存储路径及文件，默认情况下保存在 MySQL 的数据目录中;
long_query_time：指定记录慢查询日志 SQL 执行时间的阈值，单位秒，默认 10 秒，通常对于一个繁忙的系统来说，改为0.001秒比较合适;
log_queries_not_using_indexes：是否记录未使用索引的 SQL;
和二进制日志不同，慢查询日志会记录所有符合条件的 SQL，包括查询语句、数据修改语句、已经回滚的 SQL。
慢查询日志中记录的内容：
# Query_time: 0.000220 //执行时间，可以精确到毫秒，220毫秒
# Lock_time: 0.000120 //所使用锁的时间，可以精确到毫秒
# Rows_sent: 1 //返回的数据行数
# Rows_examined: 1 //扫描的数据行数
SET timestamp=1538323200; //执行sql的时间戳
SELECT c FROM test1 WHERE id =100; //sql
通常情况下，在一个繁忙的系统中，短时间内就可以产生几个 G 的慢查询日志，人工检查几乎是不可能的，为了快速分析慢查询日志，必须借助相关的工具。
常用的慢查询日志工具：
1、mysqldumpslow：一个常用的，MySQL 官方提供的慢查询日志分析工具，随着 MySQL 服务器的安装而被安装。可以汇总除查询条件外其他完全相同的 SQL，并将分析结果按照参数中所指定的顺序输出。
2、pt-query-digest：用于分析 MySQL 慢查询的一个工具。
2.实时获取性能问题SQL
为了更加及时的发现当前的性能问题，我们还可以通过实时的方法来获取有性能问题的 SQL。最方便的一种方法就是利用 MySQL information_schema 数据库下的 PROCESSLIST 表来实现实时的发现性能问题 SQL。例如下面这条 SQL 表示查询出当前服务器中执行时间超过 1 秒的 SQL：
SELECT id,user,host,db,command,time,state,info FROM information_schema.PROCESSLIST WHERE TIME>=1
然后我们可以通过脚本周期性的来执行这条 SQL，实时的发现哪些 SQL 执行的是比较慢的。
2.SQL的解析预处理及生成执行计划
找到了那些查询存在性能问题的 SQL，那么下面我们就看下，为什么这些 SQL 会存在性能问题?
为了搞清楚这个问题，我们先来看下 MySQL 服务器处理一条 SQL 请求所需要经历的步骤都有哪些：
客户端通过 MySQL 的接口发送 SQL 请求给服务器，这一步通常不会影响查询性能;
MySQL 服务器检查是否可以在查询缓存中命中该 SQL，如果命中，则立即返回存储在缓存中的结果，否则进入下一阶段;
MySQL 服务器进行 SQL 解析，预处理，再由 SQL 优化器生成对应的执行计划;
根据执行计划，调用存储引擎 API 来查询数据;
将结果返回给客户端。
这就是 MySQL 服务器处理查询请求的整个过程。在第二到第五步，都有可能对查询的响应速度造成影响，下面来分别看下这些过程可能对查询的响应速度有影响的因素都有些什么：
在解析查询语句前，如果查询缓存是打开的，那么 MySQL 优先检查这个查询是否命中查询缓存中的数据，这个检查是通过一个对大小写敏感的 Hash 查找实现的。由于 Hash 查找只能进行全值匹配，所以请求的查询和缓存中的查询就算只有一个字节的不同，那么也不会匹配到缓存中的结果，这种情况下，查询就会进入到下一阶段处理。如果正好命中查询缓存，在返回查询结果之前，MySQL 就会检查用户权限，也是无需解析 SQL 语句的，因为在查询缓存中，已经存放了当前查询所需要访问的表的信息，如果权限没有问题，MySQL 会跳过所有的其他阶段，直接从缓存中拿到结果，并返回给客户端，这种情况下查询是不会被解析的，也不会生成查询计划，不会被执行。
可以发现，从查询缓存中直接返回结果并不容易。
查询缓存对 SQL 性能的影响：
如果查询缓存，一旦数据更新，都要对缓存中数据进行刷新，影响性能;
每次在查询缓存中检查 SQL 是否被命中，都要对缓存加锁，影响性能;
对于一个读写频繁的系统来说，查询缓存很可能会降低查询处理的效率。所以在这种情况下建议大家不要使用查询缓存。
对查询缓存影响的一些系统参数：
query_cache_type: 设置查询缓存是否可用，可以设置为ON、OFF、DEMAND，DEMAND表示只有在查询语句中使用 SQL_CACHE 和 SQL_NO_CACHE 来控制是否需要缓存。
query_cache_size: 设置查询缓存的内存大小，必须是1024字节的整数倍。
query_cache_limit: 设置查询缓存可用存储的最大值，如果知道很大不会被缓存，可以在查询上加上 SQL_NO_CACHE 提高效率。
query_cache_wlock_invalidate: 设置数据表被锁后是否返回缓存中的数据，默认关闭。
query_cache_min_res_unit: 设置查询缓存分配的内存块最小单位。
对于一个读写频繁的系统来说，可以把 query_cache_type 设置为 OFF，并且把 query_cache_size 设置为 0。
当查询缓存未启用或者未命中则会进入下一阶段，也就是需要将一个 SQL 转换成一个执行计划，MySQL 再依据这个执行计划和存储引擎进行交互，这个阶段包括了多个子过程：解析 SQL，预处理，优化 SQL 执行计划。在这个过程中，出现任何错误，比如语法错误等，都有可能中止查询的过程。
在语法解析阶段，主要是通过关键字对 MySQL 语句进行解析，并生成一棵对应的 “解析树”。这一阶段，MySQL 解析器将使用 MySQL 语法规则验证和解析查询，包括检查语法是否使用了正确的关键字、关键字的顺序是否正确等。
预处理阶段则是根据 MySQL 规则进一步检查解析树是否合法，比如检查查询中所涉及的表和数据列是否存在、检查名字或别名是否存在歧义等。
如果语法检查全部都通过了，查询优化器就可以生成查询计划了。
会造成 MySQL 生成错误的执行计划的原因：
统计信息不准确;
执行计划中的成本估算不等同于实际的执行计划的成本;
MySQL 查询优化器所认为的最优可能与你所认为的最优不一样;
MySQL 从不考虑其他并发的查询，这可能会影响当前查询的速度;
MySQL 有时候也会基于一些固定的规则来生成执行计划;
MySQL 不会考虑不受其控制的成本，例如存储过程、用户自定义的函数等。
MySQL 的查询优化器可以优化的 SQL 类型：
重新定义表的关联顺序，优化器会根据统计信息来决定表的关联顺序;
将外连接转化为内连接，比如 where 条件和库表结构都可能让一个外连接等价于内连接;
使用等价变换规则，比如 (5=5 and a>5) 将被改写为 a>5;
利用索引和列是否为空来优化 count()、min() 和 max() 等聚合函数;
将一个表达式转换为常数表达式;
使用等价变换规则，比如覆盖索引，当 MySQL 查询优化器发现索引中的列包含所有查询中所需要的信息的时候，MySQL 就能使用索引返回需要的数据;
子查询优化，比如把子查询转换为关联查询，减少表的查询次数;
提前终止查询;
对 in() 条件进行优化。
以上这些就是 MySQL 查询优化器可以自动对查询所做的一些优化。经过查询优化器改写后的 SQL，查询优化器会对其生成一个 SQL 执行计划，然后 MySQL 服务器就可以根据执行计划调用存储引擎的 API，通过存储引擎获取数据了。
3.确定查询处理各个阶段的耗时
SQL 查询优化的主要目的就是减少查询所消耗的时间，加快查询的响应速度。下面来介绍如何度量查询处理各个阶段所消耗的时间。
对于一个存在性能问题的 SQL 来说，必须知道在查询的哪一阶段消耗的时间最多，然后才能有针对性的进行优化。度量查询处理各个阶段所消耗的时间，常用的方法有两种：
使用 profile;
使用 performance_schema;
4.特定SQL的查询优化
前面介绍的方法，已经可以获取一个存在性能问题的 SQL 和获取一个 SQL 在执行的各个阶段所消耗的时间了。得到这些信息后，我们就可以针对性的对 SQL 进行优化了，下面举几个对特定 SQL 优化的案例：
1.大表的更新和删除
对于大表的数据修改最好要分批处理，比如我们要在一个 1000 万行记录的表中删除/更新 100 万行记录，那么我们最好分多个批次进行删除/更新，一次只删除/更新 5000 行记录，避免长时间的阻塞，并且为了减少对主从复制带来的压力，每次删除/修改数据后需要暂停几秒。这里提供一个可以完成这样工作的 MySQL 存储过程的实例：
DELIMITER $$
USE 'db_name'$$
DROP PROCEDURE IF EXISTS 'p_delete_rows'$$
CREATE DEFINER='mysql'@'127.0.0.1' PROCEDURE 'p_delete_rows'()
BEGIN
DECLARE v_rows INT;
SET v_rows = 1;
WHERE v_rows > 0
DO
DELETE FROM table_name WHERE id >= 9000 AND id <= 290000 LIMIT 5000;
SELECT ROW_COUNT() INTO v_rows;
SELECT SLEEP(5);
END WHERE;
END$$
DELIMITER;
大家可以根据自己的情况来修改这个存储过程，或者使用自己熟悉的开发语言实现这个处理过程，使用这个存储过程只需要修改 DELETE FROM table_name WHERE id >= 9000 AND id <= 290000 LIMIT 5000; 部分的内容即可。
2.如何修改大表的表结构
对于 InnoDB 存储引擎来说，对表中的列的字段类型进行修改或者改变字段的宽度时还是会锁表，同时也无法解决主从数据库延迟的问题。
pt-online-schema-change \\
--alter="MODIFY c VARCHAR(150) NOT NULL DEFAULT ''" \\
--user=root --password=password D=db_name,t=table_name \\
--charset=utf8 --execute
这个命令就是把 db_name 数据库下的 table_name 表中 c 列的宽度改为 VARCHAR(150)。
3.如何优化not in和<>查询
MySQL 查询优化器可以自动的把一些子查询优化为关联查询，但是对于存在not in和<>这样的子查询语句来说，就无法进行自动优化了，这就造成了会循环多次来查找子表来确认是否满足过滤条件，如果子查询恰好是一个很大的表的话，这样做的效率会非常低，所以我们在进行 SQL 开发时，最好把这类查询自行改写成关联查询。
改写前：
SELECT id,name,email
FROM customer
WHERE id
NOT IN(SELECT id FROM payment)
优化改写后：
SELECT a.id,a.name,a.email
FROM customer a
LEFT JOIN payment b ON a.id=b.id
WHERE b.id IS NULL
使用 LEFT JOIN 关联替代了 NOT IN 过滤，这样避免了对 payment 表进行多次查询，这是一种非常常用的对 NOT IN 的优化方式。
4.使用汇总表优化查询
最常见的就是商品的评论数，如果我们在用户访问页面时，实时的访问商品的评论数，通常来说，查询的 SQL 会类似于下面这个样子：
SELECT COUNT(*) FROM product_comment WHERE product_id = 10001;
这个 SQL 就是统计出所有 product_id = 10001 的评论，假设评论表中有上亿条记录，那么这个 SQL 执行起来是非常的慢的，如果有大量的并发访问，则会对数据库带来很大的压力。对于这么情况，我们通常使用汇总表的方式进行优化。所谓的汇总表就是提前把要统计的数据进行汇总并记录到表中已备后续的查询使用。针对这个查询，我们可以使用下面的方式进行优化：
CREATE TABLE product_comment_cnt(product_id INT, cnt INT); //建立汇总表
//查询评论数
SELECT SUM(cnt) FROM(
SELECT cnt FROM product_comment_cnt WHERE product_id = 10001
UNION ALL
SELECT COUNT(*) FROM product_comment WHERE product_id = 10001
AND timestr > DATE(NOW())
);
解决方案：
在主服务器上建立新表，新表的结构就是修改之后的结构，再把老表的数据导入到新表中，并且在老表上建立一系列的触发器，把老表数据的修改同步更新到新表中，当老表和新表的数据同步后，再对老表加一个排它锁，然后重新命名新表为老表的名字，最好删除重命名的老表，这样就完成了大表表结构修改的工作。这样处理的好处是可以尽量减少主从延迟，以及在重命名之前不需要加任何的锁，只需要在重命名的时候加一个短暂的锁，这对应用通常是无影响的，缺点就是操作比较复杂。好在有工具可以帮我们实行这个过程，这个工具同样是 percona 公司 MySQL 工具集中的一个，叫做 pt-online-schema-change。
