MySQL相关面试题

MySQL相关

（1）MySQL 索引使用有哪些注意事项呢？

可以从三个维度回答这个问题：索引哪些情况会失效，索引不适合哪些场景，索引规则

索引哪些情况会失效

• 查询条件包含or，可能导致索引失效
• 如何字段类型是字符串，where时一定用引号括起来，否则索引失效，mysql做类型转换用不到索引
• like通配符可能导致索引失效。
• 联合索引，查询时的条件列不是联合索引中的第一个列，索引失效。
• 在索引列上使用mysql的内置函数，索引失效。
• 对索引列运算（如，+、-、*、/），索引失效。
• 索引字段上使用（！= 或者 < >，not in）时，可能会导致索引失效。
• 索引字段上使用is null， is not null，可能导致索引失效。
• 左连接查询或者右连接查询查询关联的字段编码格式不一样，可能导致索引失效。
• mysql估计使用全表扫描要比使用索引快,则不使用索引。

索引不适合哪些场景

• 数据量少的不适合加索引
• 更新比较频繁的也不适合加索引
• 区分度低的字段不适合加索引（如性别）

索引的一些潜规则

• 覆盖索引
• 回表
• 索引数据结构（B+树）
• 最左前缀原则
• 索引下推

参考：https://www.jianshu.com/p/d0d3de6832b9

（2） MySQL 遇到过死锁问题吗，你是如何解决的？

我排查死锁的一般步骤是酱紫的：

• 查看死锁日志show engine innodb status;
• 找出死锁Sql
• 分析sql加锁情况
• 模拟死锁案发
• 分析死锁日志
• 分析死锁结果

（3） 日常工作中你是怎么优化SQL的？

可以从这几个维度回答这个问题：

• 加索引
• 避免返回不必要的数据
• 适当分批量进行
• 优化sql结构
• 分库分表
• 读写分离

（4）说说分库与分表的设计

分库分表方案，分库分表中间件，分库分表可能遇到的问题

分库分表方案:

• 水平分库：以字段为依据，按照一定策略（hash、range等），将一个库中的数据 拆分到多个库中。
• 水平分表：以字段为依据，按照一定策略（hash、range等），将一个表中的数据 拆分到多个表中。
• 垂直分库：以表为依据，按照业务归属不同，将不同的表拆分到不同的库中。
• 垂直分表：以字段为依据，按照字段的活跃性，将表中字段拆到不同的表（主表和 扩展表）中。

常用的分库分表中间件：

• sharding-jdbc（当当）
• Mycat
• TDDL（淘宝）
• Oceanus(58同城数据库中间件)
• vitess（谷歌开发的数据库中间件）
• Atlas(Qihoo 360)

分库分表可能遇到的问题

事务问题：需要用分布式事务啦

• 跨节点Join的问题：解决这一问题可以分两次查询实现
• 跨节点的count,order by,group by以及聚合函数问题：分别在各个节点上得到结果后在应用程序端进行合并。
• 数据迁移，容量规划，扩容等问题
• ID问题：数据库被切分后，不能再依赖数据库自身的主键生成机制啦，最简单可以考虑UUID
• 跨分片的排序分页问题（后台加大pagesize处理？）

（5） InnoDB与MyISAM的区别

• InnoDB支持事务，MyISAM不支持事务
• InnoDB支持外键，MyISAM不支持外键
• InnoDB 支持 MVCC(多版本并发控制)，MyISAM 不支持
• select count(*) from table 时，MyISAM更快，因为它有一个变量保存了整个表的总 行数，可以直接读取，InnoDB就需要全表扫描。
• Innodb不支持全文索引，而MyISAM支持全文索引（5.7以后的InnoDB也支持全文索 引）
• InnoDB支持表、行级锁，而MyISAM支持表级锁。
• InnoDB表必须有主键，而MyISAM可以没有主键
• Innodb表需要更多的内存和存储，而MyISAM可被压缩，存储空间较小，。
• Innodb按主键大小有序插入，MyISAM记录插入顺序是，按记录插入顺序保存。
• InnoDB 存储引擎提供了具有提交、回滚、崩溃恢复能力的事务安全，与 MyISAM 比 InnoDB 写的效率差一些，并且会占用更多的磁盘空间以保留数据和索引
• InnoDB 属于索引组织表，使用共享表空间和多表空间储存数据。MyISAM用.frm 、 .MYD 、.MTI 来储存表定义，数据和索引。

（6） 数据库索引的原理，为什么要用 B+树，为什么不用二叉树？

可以从几个维度去看这个问题，查询是否够快，效率是否稳定，存储数据多少，以及查找磁盘次数，为什么不是二叉树，为什么不是平衡二叉树，为什么不是B树，而偏偏是B+树呢？

为什么不是一般二叉树？

如果二叉树特殊化为一个链表，相当于全表扫描。平衡二叉树相比于二叉查找树来说，查找效率更稳定，总体的查找速度也更快。

为什么不是平衡二叉树呢？

我们知道，在内存比在磁盘的数据，查询效率快得多。如果树这种数据结构作为索引，那我们每查找一次数据就需要从磁盘中读取一个节点，也就是我们说的一个磁盘块，但是平衡二叉树可是每个节点只存储一个键值和数据的，如果是B树，可以存储更多的节点数据，树的高度也会降低，因此读取磁盘的次数就降下来啦，查询效率就快啦。

那为什么不是B树而是B+树呢？

1. B+树非叶子节点上是不存储数据的，仅存储键值，而B树节点中不仅存储键值，也会存储数据。innodb中页的默认大小是16KB，如果不存储数据，那么就会存储更多的键值，相应的树的阶数（节点的子节点树）就会更大，树就会更矮更胖，如此一来我们查找数据进行磁盘的IO次数有会再次减少，数据查询的效率也会更快。
2. B+树索引的所有数据均存储在叶子节点，而且数据是按照顺序排列的，链表连着的。那么B+树使得范围查找，排序查找，分组查找以及去重查找变得异常简单。

（7）聚集索引与非聚集索引的区别

• 一个表中只能拥有一个聚集索引，而非聚集索引一个表可以存在多个。
• 聚集索引，索引中键值的逻辑顺序决定了表中相应行的物理顺序；非聚集索引，索引中索引的逻辑顺序与磁盘上行的物理存储顺序不同。
• 索引是通过二叉树的数据结构来描述的，我们可以这么理解聚簇索引：索引的叶节点就是数据节点。而非聚簇索引的叶节点仍然是索引节点，只不过有一个指针指向对应的数据块。
• 聚集索引：物理存储按照索引排序；非聚集索引：物理存储不按照索引排序；

何时使用聚集索引或非聚集索引？

动作描述	使用聚簇索引	使用非聚簇索引
列经常被分组排序	应	应
返回某个范围的数据	应	不应
一个或极少的不同值	不应	不应
小数目的不同值	应	不应
大数目的不同值	不应	应
频繁更新的列	不应	应
主键列	应	应
频繁修改的索引列	不应	应

（8）limit 1000000 加载很慢的话，你是怎么解决的呢？

方案一：如果id是连续的，可以这样，返回上次查询的最大记录(偏移量)，再往下limit

select id，name from employee where id>1000000 limit 10.

方案二：在业务允许的情况下限制页数：

建议跟业务讨论，有没有必要查这么后的分⻚啦。因为绝大多数用户都不会往后翻太多页。

方案三：order by + 索引（id为索引）

select id，name from employee order by id limit 1000000，10
SELECT a.* FROM employee a, (select id from employee where 条件 LIMIT
1000000,10 ) b where a.id=b.id

方案四：利用延迟关联或者子查询优化超多分页场景。（先快速定位需要获取的id段，

然后再关联）

（9）如何选择合适的分布式主键方案呢？

• 数据库自增长序列或字段。
• UUID。
• Redis生成ID
• Twitter的snowflake算法
• 利用zookeeper生成唯一ID
• MongoDB的ObjectId

（10）事务的隔离级别有哪些？MySQL的默认隔离级别是什么？

• 读未提交（Read Uncommitted）

• 读已提交（Read Committed）

• 可重复读（Repeatable Read）

• 串行化（Serializable）

  Mysql默认的事务隔离级别是可重复读(Repeatable Read)

（11）什么是幻读，脏读，不可重复读呢？

• 事务A、B交替执行，事务A被事务B干扰到了，因为事务A读取到事务B未提交的数据,这就是脏读
• 在一个事务范围内，两个相同的查询，读取同一条记录，却返回了不同的数据，这就是不可重复读。
• 事务A查询一个范围的结果集，另一个并发事务B往这个范围中插入/删除了数据，并静悄悄地提交，然后事务A再次查询相同的范围，两次读取得到的结果集不一样了，这就是幻读。

（12） 在高并发情况下，如何做到安全的修改同一行数据？

要安全的修改同一行数据，就要保证一个线程在修改时其它线程无法更新这行记录。一般有悲观锁和乐观锁两种方案~

使用悲观锁

悲观锁思想就是，当前线程要进来修改数据时，别的线程都得拒之⻔外~ 比如，可以使用select...for update~

select * from User where name=‘1 jay’ for update

以上这条sql语句会锁定了User表中所有符合检索条件（name=‘jay’）的记录。本次事 务提交之前，别的线程都无法修改这些记录。

使用乐观锁

乐观锁思想就是，有线程过来，先放过去修改，如果看到别的线程没修改过，就可以修改成功，如果别的线程修改过，就修改失败或者重试。实现方式：乐观锁一般会使用版本号机制或CAS算法实现。

（13）数据库的乐观锁和悲观锁。

悲观锁：

悲观锁她专一且缺乏安全感了，她的心只属于当前事务，每时每刻都担心着它心爱的数据可能被别的事务修改，所以一个事务拥有（获得）悲观锁后，其他任何事务都不能对数据进行修改啦，只能等待锁被释放才可以执行。

乐观锁：

乐观锁的“乐观情绪”体现在，它认为数据的变动不会太频繁。因此，它允许多个事务同

时对数据进行变动。实现方式：乐观锁一般会使用版本号机制或CAS算法实现。

（14）SQL优化的一般步骤是什么，怎么看执行计划（explain），如何理解其中各个字段的含义。

• show status  命令了解各种 sql 的执行频率
• 通过慢查询日志定位那些执行效率较低的 sql 语句
• explain  分析低效 sql 的执行计划（这点非常重要，日常开发中用它分析Sql，会大大降低Sql导致的线上事故）

（15）select for update有什么含义，会锁表还是锁行还是其他。

select for update 含义

select查询语句是不会加锁的，但是select for update除了有查询的作用外，还会加锁 呢，而且它是悲观锁哦。至于加了是行锁还是表锁，这就要看是不是用了索引/主键啦。 没用索引/主键的话就是表锁，否则就是是行锁。

(16) MySQL事务得四大特性以及实现原理

• 原子性： 事务作为一个整体被执行，包含在其中的对数据库的操作要么全部被执行，要么都不执行。
• 一致性： 指在事务开始之前和事务结束以后，数据不会被破坏，假如A账户给B账户转10块钱，不管成功与否，A和B的总金额是不变的。
• 隔离性： 多个事务并发访问时，事务之间是相互隔离的，即一个事务不影响其它事务运行效果。简言之，就是事务之间是进水不犯河水的。
• 持久性： 表示事务完成以后，该事务对数据库所作的操作更改，将持久地保存在数据库之中。

事务ACID特性的实现思想

• 原子性：是使用 undo log来实现的，如果事务执行过程中出错或者用户执行了rollback，系统通过undo log日志返回事务开始的状态。
• 持久性：使用 redo log来实现，只要redo log日志持久化了，当系统崩溃，即可通过redo log把数据恢复。
• 隔离性：通过锁以及MVCC,使事务相互隔离开。
• 一致性：通过回滚、恢复，以及并发情况下的隔离性，从而实现一致性。

(17) 如果某个表有近千万数据，CRUD比较慢，如何优化。

分库分表

某个表有近千万数据，可以考虑优化表结构，分表（水平分表，垂直分表），当然，你这样回答，需要准备好面试官问你的分库分表相关问题呀，如

• 分表方案（水平分表，垂直分表，切分规则hash等）
• 分库分表中间件（Mycat，sharding-jdbc等）
• 分库分表一些问题（事务问题？跨节点Join的问题）
• 解决方案（分布式事务等）

索引优化

除了分库分表，优化表结构，当然还有所以索引优化等方案~

(18) 如何写sql能够有效的使用到复合索引。

复合索引，也叫组合索引，用户可以在多个列上建立索引,这种索引叫做复合索引。当我们创建一个组合索引的时候，如(k1,k2,k3)，相当于创建了（k1）、(k1,k2)和(k1,k2,k3)三个索引，这就是最左匹配原则。

 select * from table where k1=A AND k2=B AND k3=D

有关于复合索引，我们需要关注查询Sql条件的顺序，确保最左匹配原则有效，同时可以删除不必要的冗余索引。

（19） mysql中in 和exists的区别。

这个，跟一下demo来看更刺激吧，啊哈哈 假设表A表示某企业的员工表，表B表示部⻔表，查询所有部⻔的所有员工，很容易有以下SQL:

select * from A where deptId in (select 1 deptId from B);

这样写等价于：

先查询部门表B select deptId from B 再由部门deptId，查询A的员工 select * from A where A.deptId = B.deptId 可以抽象成这样的一个循环：

List<> resultSet ;
    for(int i=0;i<B.length;i++) {
        for(int j=0;j<A.length;j++) {
        if(A[i].id==B[j].id) {
            resultSet.add(A[i]);
            break;
        }
    }
}

显然，除了使用in，我们也可以用exists实现一样的查询功能，如下：

select * from A where exists (select 1 from B where A.deptId = B.deptId);

因为exists查询的理解就是，先执行主查询，获得数据后，再放到子查询中做条件验证，根据验证结果（true或者false），来决定主查询的数据结果是否得意保留。 那么，这样写就等价于：

select * from A,先从A表做循环 select * from B where A.deptId = B.deptId,再从B
表做循环.

同理，可以抽象成这样一个循环：

List<> resultSet ;
    for(int i=0;i<A.length;i++) {
        for(int j=0;j<B.length;j++) {
        if(A[i].deptId==B[j].deptId) {
            resultSet.add(A[i]);
            break;
        }
    }
}

数据库最费劲的就是跟程序链接释放。假设链接了两次，每次做上百万次的数据集查询，查完就走，这样就只做了两次；相反建立了上百万次链接，申请链接释放反复重复，这样系统就受不了了。即mysql优化原则，就是小表驱动大表，小的数据集驱动大的数据集，从而让性能更优。 因此，我们要选择最外层循环小的，也就是，如果B的数据量小于A，适合使用in，如果B的数据量大于A，即适合选择exists，这就是in和exists的区别。

(20) 数据库自增主键可能遇到什么问题。

使用自增主键对数据库做分库分表，可能出现诸如主键重复等的问题。解决方案的话，简单点的话可以考虑使用UUID哈 自增主键会产生表锁，从而引发问题 自增主键可能用完问题。

(21) MVCC熟悉吗，它的底层原理？

MVCC,多版本并发控制,它是通过读取历史版本的数据，来降低并发事务冲突，从而提高并发性能的一种机制。

MVCC需要关注这几个知识点：

事务版本号

表的隐藏列

undo log

read view

参考：https://blog.csdn.net/SnailMann/article/details/94724197

（22） 数据库中间件了解过吗，sharding jdbc，mycat？

sharding-jdbc目前是基于jdbc驱动，无需额外的proxy，因此也无需关注proxy本身的高可用。 Mycat 是基于 Proxy，它复写了 MySQL 协议，将 Mycat Server 伪装成一个MySQL 数据库，而 Sharding-JDBC 是基于 JDBC 接口的扩展，是以 jar 包的形式提供轻量级服务的。

（23） MYSQL的主从延迟，你怎么解决？

嘻嘻，先复习一下主从复制原理吧，如图：

主从复制分了五个步骤进行：

• 步骤一：主库的更新事件(update、insert、delete)被写到binlog
• 步骤二：从库发起连接，连接到主库。
• 步骤三：此时主库创建一个binlog dump thread，把binlog的内容发送到从库。
• 步骤四：从库启动之后，创建一个I/O线程，读取主库传过来的binlog内容并写入到relay log
• 步骤五：还会创建一个SQL线程，从relay log里面读取内容，从Exec_Master_Log_Pos位置开始执行读取到的更新事件，将更新内容写入到slave的db

主从同步延迟的原因

一个服务器开放Ｎ个链接给客户端来连接的，这样有会有大并发的更新操作, 但是从服务器的里面读取binlog的线程仅有一个，当某个SQL在从服务器上执行的时间稍长或者由于某个SQL要进行锁表就会导致，主服务器的SQL大量积压，未被同步到从服务器里。这就导致了主从不一致， 也就是主从延迟。

主从同步延迟的解决办法

• 主服务器要负责更新操作，对安全性的要求比从服务器要高，所以有些设置参数可以修改，比如sync_binlog=1，innodb_flush_log_at_trx_commit = 1 之类的设置等。
• 选择更好的硬件设备作为slave。把一台从服务器当度作为备份使用， 而不提供查询， 那边他的负载下来了， 执行relay log 里面的SQL效率自然就高了。
• 增加从服务器喽，这个目的还是分散读的压力，从而降低服务器负载。

（24）说一下大表查询的优化方案

• 优化shema、sql语句+索引；

• 可以考虑加缓存，memcached, redis，或者JVM本地缓存；

• 主从复制，读写分离；
• 分库分表；

（25）什么是数据库连接池?为什么需要数据库连接池呢?

连接池基本原理：

数据库连接池原理：在内部对象池中，维护一定数量的数据库连接，并对外暴露数据库连接的获取和返回方法。

应用程序和数据库建立连接的过程：

• 通过TCP协议的三次握手和数据库服务器建立连接
• 发送数据库用户账号密码，等待数据库验证用户身份
• 完成身份验证后，系统可以提交SQL语句到数据库执行
• 把连接关闭，TCP四次挥手告别。

数据库连接池好处：

• 资源重用 (连接复用)
• 更快的系统响应速度
• 新的资源分配手段 统一的连接管理，避免数据库连接泄漏

（26） 一条SQL语句在MySQL中如何执行的？

先看一下Mysql的逻辑架构图吧~

查询语句过程：

• 先检查该语句是否有权限

• 如果没有权限，直接返回错误信息

• 如果有权限，在 MySQL8.0 版本以前，会先查询缓存。

• 如果没有缓存，分析器进行词法分析，提取 sql 语句select等的关键元素。然后判断sql 语句是否有语法错误，比如关键词是否正确等等。

• 优化器进行确定执行方案

• 执行器执行

（27）InnoDB引擎中的索引策略，了解过吗？

• 覆盖索引
• 最左前缀原则
• 索引下推
• 索引下推优化是 MySQL 5.6 引入的， 可以在索引遍历过程中，对索引中包含的字 段先做判断，直接过滤掉不满足条件的记录，减少回表次数。

（28）数据库存储日期格式时，如何考虑时区转换问题？

datetime类型适合用来记录数据的原始的创建时间，修改记录中其他字段的值，datetime字段的值不会改变，除非手动修改它。

timestamp类型适合用来记录数据的最后修改时间，只要修改了记录中其他字段的 值，timestamp字段的值都会被自动更新。

（29） 一条sql执行过长的时间，你如何优化，从哪些方面入手？

• 查看是否涉及多表和子查询，优化Sql结构，如去除冗余字段，是否可拆表等
• 优化索引结构，看是否可以适当添加索引
• 数量大的表，可以考虑进行分离/分表（如交易流水表）
• 数据库主从分离，读写分离
• explain分析sql语句，查看执行计划，优化sql
• 查看mysql执行日志，分析是否有其他方面的问题

（30）MYSQL数据库服务器性能分析的方法命令有哪些?

 Show status, 一些值得监控的变量值：

Bytes_received和Bytes_sent 和服务器之间来往的流量。 Com_*服务器正在执行
的命令。 Created_*在查询执行期限间创建的临时表和文件。 Handler_*存储引擎操
作。 Select_*不同类型的联接执行计划。 Sort_*几种排序信息。

 Show profiles 是MySql用来分析当前会话SQL语句执行的资源消耗情况

（31）Blob和text有什么区别？

• Blob用于存储二进制数据，而Text用于存储大字符串。
• Blob值被视为二进制字符串（字节字符串）,它们没有字符集，并且排序和比较基于列值中的字节的数值。
• text值被视为非二进制字符串（字符字符串）。它们有一个字符集，并根据字符集的排序规则对值进行排序和比较。

（32） Mysql中有哪几种锁，列举一下？

参考：http://blog.xiaot123.com/mysql-innodb-tuzpc

如果按锁粒度划分，有以下3种：

• 表锁： 开销小，加锁快；锁定力度大，发生锁冲突概率高，并发度最低;不会出现死锁。
• 行锁： 开销大，加锁慢；会出现死锁；锁定粒度小，发生锁冲突的概率低，并发度高。
• 页锁： 开销和加锁速度介于表锁和行锁之间；会出现死锁；锁定粒度介于表锁和行锁之间，并发度一般

参考：

（33） Hash索引和B+树区别是什么？你在设计索引是怎么抉择的？

 B+树可以进行范围查询，Hash索引不能。  B+树支持联合索引的最左侧原则，Hash索引不支持。  B+树支持order by排序，Hash索引不支持。  Hash索引在等值查询上比B+树效率更高。  B+树使用like 进行模糊查询的时候，like后面（比如%开头）的话可以起到优化的作 用，Hash索引根本无法进行模糊查询。

（34） 说一下数据库的三大范式

第一范式：数据表中的每一列（每个字段）都不可以再拆分。

第二范式：在第一范式的基础上，分主键列完全依赖于主键，而不能是依赖于主键的一部分。

第三范式：在满足第二范式的基础上，表中的非主键只依赖于主键，而不依赖于其他非主键。

（35） Mysql的binlog有几种录入格式？分别有什么区别？

有三种格式哈，statement，row和mixed。

• statement，每一条会修改数据的sql都会记录在binlog中。不需要记录每一行的变 化，减少了binlog日志量，节约了IO，提高性能。由于sql的执行是有上下文的，因 此在保存的时候需要保存相关的信息，同时还有一些使用了函数之类的语句无法被 记录复制。
• row，不记录sql语句上下文相关信息，仅保存哪条记录被修改。记录单元为每一行 的改动，基本是可以全部记下来但是由于很多操作，会导致大量行的改动(比如alter table)，因此这种模式的文件保存的信息太多，日志量太大。
• mixed，一种折中的方案，普通操作使用statement记录，当无法使用statement的 时候使用row。

参考：http://blog.xiaot123.com/mysqlbinlogredologundolog-lagwx

（36） InnoDB引擎的4大特性，了解过吗

• 插入缓冲（insert buffer)
• 二次写(double write)
• 自适应哈希索引(ahi)
• 预读(read ahead)

参考：https://www.cnblogs.com/zhs0/p/10528520.html

（37）创建索引有什么原则呢？

• 最左前缀匹配原则
• 频繁作为查询条件的字段才去创建索引
• 频繁更新的字段不适合创建索引
• 索引列不能参与计算，不能有函数操作
• 优先考虑扩展索引，而不是新建索引，避免不必要的索引
• 在order by或者group by子句中，创建索引需要注意顺序
• 区分度低的数据列不适合做索引列(如性别）
• 定义有外键的数据列一定要建立索引。
• 对于定义为text、image数据类型的列不要建立索引。
• 删除不再使用或者很少使用的索引

（38） 百万级别或以上的数据，你是如何删除的？

• 我们想要删除百万数据的时候可以先删除索引
• 然后批量删除其中无用数据
• 删除完成后重新创建索引。

ps ：我觉得rename方式会更好

（39）varchar(50)中50的涵义

字段最多存放 50 个字符 如 varchar(50) 和 varchar(200) 存储 "jay" 字符串所占空间 是一样的，后者在排序时会消耗更多内存

（40）drop、delete与truncate的区别

	delete （删除特定记录）	truncate（清空表）	drop（删除表）
类型	DML	DDL	DDL
是否可以回滚	是	否	否
删除内容	表结构还在，删除表的全部或者一部分数据行	表结构还在，删除表的所有数据行	删除表以及所有信息
删除速度	慢，要逐行删除	快	最快

（41） UNION与UNION ALL的区别？

• Union：对两个结果集进行并集操作，不包括重复行，同时进行默认规则的排序；
• Union All：对两个结果集进行并集操作，包括重复行，不进行排序；
• UNION的效率高于 UNION ALL

（42）一条Sql的执行顺序？

（43） MySQL数据库cpu飙升的话，要怎么处理呢？

排查过程：

• 使用top 命令观察，确定是mysqld导致还是其他原因。
• 如果是mysqld导致的，show processlist，查看session情况，确定是不是有消耗资源的sql在运行。
• 找出消耗高的 sql，看看执行计划是否准确， 索引是否缺失，数据量是否太大。

处理：

• kill 掉这些线程(同时观察 cpu 使用率是否下降)，
• 进行相应的调整(比如说加索引、改 sql、改内存参数)
• 重新跑这些 SQL。

其他情况：

也有可能是每个 sql 消耗资源并不多，但是突然之间，有大量的 session 连进来导致 cpu 飙升，这种情况就需要跟应用一起来分析为何连接数会激增，再做出相应的调整， 比如说限制连接数等

（44）谈谈MySQL的Explain

Explain 执行计划包含字段信息如下：分别是 id、select_type、table、partitions、 type、possible_keys、key、key_len、ref 、rows、filtered、Extra 等12个字段。 我 们重点关注的是type，它的属性排序如下：

system > const > eq_ref > ref 1 > ref_or_null >
index_merge > unique_subquery > index_subquery >
range > index > ALL

参考：http://blog.xiaot123.com/mysql-poyho

（45）一个6亿的表a，一个3亿的表b，通过外间tid关联，你如何最快的查询出满足条件的第50000到第50200中的这200条数据记录。

1、如果A表TID是自增,并且是连续的,B表的ID为索引：

select * from a,b where a.tid = b.id and a.tid>1 500000 limit 200;

2、如果A表的TID不是连续的,那么就需要使用覆盖索引.TID要么是主键,要么是辅助索引,B表ID也需要有索引。

select * from b , (select tid from a limit 50000,200) a where b.id = a
.tid;