11.数据库技术

1.一条SQL语句执行得很慢的原因有哪些？

针对偶尔很慢的情况

数据库在刷新脏页我也无奈啊

当我们要往数据库插入一条数据、或者要更新一条数据的时候，我们知道数据库会在内存中把对应字段的数据更新了，但是更新之后，这些更新的字段并不会马上同步持久化到磁盘中去，而是把这些更新的记录写入到 redo log 日记中去，等到空闲的时候，在通过 redo log 里的日记把最新的数据同步到磁盘中去。

不过，redo log 里的容量是有限的，如果数据库一直很忙，更新又很频繁，这个时候 redo log 很快就会被写满了，这个时候就没办法等到空闲的时候再把数据同步到磁盘的，只能暂停其他操作，全身心来把数据同步到磁盘中去的，而这个时候，就会导致我们平时正常的SQL语句突然执行的很慢，所以说，数据库在在同步数据到磁盘的时候，就有可能导致我们的SQL语句执行的很慢了。

拿不到锁我能怎么办

这个就比较容易想到了，我们要执行的这条语句，刚好这条语句涉及到的表，别人在用，并且加锁了，我们拿不到锁，只能慢慢等待别人释放锁了。或者，表没有加锁，但要使用到的某个一行被加锁了，这个时候，我也没办法啊。

如果要判断是否真的在等待锁，我们可以用 show processlist这个命令来查看当前的状态哦

针对一直都这么慢的情况

如果在数据量一样大的情况下，这条 SQL 语句每次都执行的这么慢，那就就要好好考虑下你的 SQL 书写了，下面我们来分析下哪些原因会导致我们的 SQL 语句执行的很不理想。

我们先来假设我们有一个表，表里有下面两个字段,分别是主键 id，和两个普通字段 c 和 d。

mysql> CREATE TABLE `t` (
 `id` int(11) NOT NULL,
 `c` int(11) DEFAULT NULL,
 `d` int(11) DEFAULT NULL,
 PRIMARY KEY (`id`)
) ENGINE=InnoDB;

扎心了，没用到索引

没有用上索引，我觉得这个原因是很多人都能想到的，例如你要查询这条语句

select * from t where 100



字段没有索引

刚好你的 c 字段上没有索引，那么抱歉，只能走全表扫描了，这导致这条查询语句很慢。

字段有索引，但却没有用索引

好吧，这个时候你给 c 这个字段加上了索引，然后又查询了一条语句
select * from t where c - 1 = 1000;
我想问大家一个问题，这样子在查询的时候会用索引查询吗？
答是不会，如果我们在字段的左边做了运算，那么很抱歉，在查询的时候，就不会用上索引了，所以呢，大家要注意这种字段上有索引，但由于自己的疏忽，导致系统没有使用索引的情况了。
正确的查询应该如下
select * from t where c = 1000 + 1;
有人可能会说，右边有运算就能用上索引？难道数据库就不会自动帮我们优化一下，自动把 c - 1=1000 自动转换为 c = 1000+1。
不好意思，确实不会帮你，所以，你要注意了。

函数操作导致没有用上索引

如果我们在查询的时候，对字段进行了函数操作，也是会导致没有用上索引的，例如
select * from t where pow(c,2) = 1000;
这里我只是做一个例子，假设函数 pow 是求 c 的 n 次方，实际上可能并没有 pow(c,2)这个函数。其实这个和上面在左边做运算也是很类似的。
所以呢，一条语句执行都很慢的时候，可能是该语句没有用上索引了，不过具体是啥原因导致没有用上索引的呢，你就要会分析了，我上面列举的三个原因，应该是出现的比较多的吧。
呵呵，数据库自己选错索引了
我们在进行查询操作的时候，例如
select * from t where 100 < c and c < 100000;
我们知道，主键索引和非主键索引是有区别的，主键索引存放的值是整行字段的数据，而非主键索引上存放的值不是整行字段的数据，而且存放主键字段的值。不大懂的可以看我这篇文章：面试小知识：MySQL索引相关 里面有说到主键索引和非主键索引的区别
也就是说，我们如果走 c 这个字段的索引的话，最后会查询到对应主键的值，然后，再根据主键的值走主键索引，查询到整行数据返回。
就算你在 c 字段上有索引，系统也并不一定会走 c 这个字段上的索引，而是有可能会直接扫描扫描全表，找出所有符合 100 < c and c < 100000 的数据。
为什么会这样呢？
其实是这样的，系统在执行这条语句的时候，会进行预测：究竟是走 c 索引扫描的行数少，还是直接扫描全表扫描的行数少呢？显然，扫描行数越少当然越好了，因为扫描行数越少，意味着I/O操作的次数越少。
如果是扫描全表的话，那么扫描的次数就是这个表的总行数了，假设为 n；而如果走索引 c 的话，我们通过索引 c 找到主键之后，还得再通过主键索引来找我们整行的数据，也就是说，需要走两次索引。而且，我们也不知道符合 100 c < and c < 10000 这个条件的数据有多少行，万一这个表是全部数据都符合呢？这个时候意味着，走 c 索引不仅扫描的行数是 n，同时还得每行数据走两次索引。
所以呢，系统是有可能走全表扫描而不走索引的。那系统是怎么判断呢？
判断来源于系统的预测，也就是说，如果要走 c 字段索引的话，系统会预测走 c 字段索引大概需要扫描多少行。如果预测到要扫描的行数很多，它可能就不走索引而直接扫描全表了。
那么问题来了，系统是怎么预测判断的呢？这里我给你讲下系统是怎么判断的吧，虽然这个时候我已经写到脖子有点酸了。
系统是通过索引的区分度来判断的，一个索引上不同的值越多，意味着出现相同数值的索引越少，意味着索引的区分度越高。我们也把区分度称之为基数，即区分度越高，基数越大。所以呢，基数越大，意味着符合 100 < c and c < 10000 这个条件的行数越少。
所以呢，一个索引的基数越大，意味着走索引查询越有优势。
那么问题来了，怎么知道这个索引的基数呢？
系统当然是不会遍历全部来获得一个索引的基数的，代价太大了，索引系统是通过遍历部分数据，也就是通过采样的方式，来预测索引的基数的。
扯了这么多，重点的来了，居然是采样，那就有可能出现失误的情况，也就是说，c 这个索引的基数实际上是很大的，但是采样的时候，却很不幸，把这个索引的基数预测成很小。例如你采样的那一部分数据刚好基数很小，然后就误以为索引的基数很小。然后就呵呵，系统就不走 c 索引了，直接走全部扫描了。
所以呢，说了这么多，得出结论：由于统计的失误，导致系统没有走索引，而是走了全表扫描，而这，也是导致我们 SQL 语句执行的很慢的原因。

这里我声明一下，系统判断是否走索引，扫描行数的预测其实只是原因之一，这条查询语句是否需要使用使用临时表、是否需要排序等也是会影响系统的选择的。

不过呢，我们有时候也可以通过强制走索引的方式来查询，例如
select * from t force index(a) where c < 100 and c < 100000;
我们也可以通过
show index from t;
来查询索引的基数和实际是否符合，如果和实际很不符合的话，我们可以重新来统计索引的基数，可以用这条命令
analyze table t;
来重新统计分析。
既然会预测错索引的基数，这也意味着，当我们的查询语句有多个索引的时候，系统有可能也会选错索引哦，这也可能是 SQL 执行的很慢的一个原因。
好吧，就先扯这么多了，你到时候能扯出这么多，我觉得已经很棒了，下面做一个总结。
总结
以上是我的总结与理解，最后一个部分，我怕很多人不大懂数据库居然会选错索引，所以我详细解释了一下，下面我对以上做一个总结。
一个 SQL 执行的很慢，我们要分两种情况讨论：
1、大多数情况下很正常，偶尔很慢，则有如下原因
   (1) 数据库在刷新脏页，例如 redo log 写满了需要同步到磁盘。
    (2) 执行的时候，遇到锁，如表锁、行锁。
2、这条 SQL 语句一直执行的很慢，则有如下原因。
    (1) 没有用上索引：例如该字段没有索引；由于对字段进行运算、函数操作导致无法用索引。
     (2) 数据库选错了索引。

2.数据库隔离级别有哪些,各自的含义是什么, MYSQL默认的隔离级别是是什么.

Read Uncommitted（读取未提交内容）：出现脏读，也就是可能读取到其他会话中未提交事务修改的数据。
Read Committed（读取提交内容）：不可重复读，只能读取到已经提交的数据。Oracle等数据库默认的隔离级别。
Repeatable Read（可重读）：出现幻读。在同一个事务内的查询都和事务开始时刻一致。InnoDB默认级别。
Serializable（串行读）：完全串行化的读，每次读都需要获得表级共享锁，读写相互都会阻塞。
MYSQL默认的隔离级别：Repeatable Read（可重读）级别。
  


3.什么是幻读。
官方：幻读是指当事务不是独立执行时发生的一种现象，
  例如第一个事务对一个表中的数据进行了修改，比如这种修改涉及到表中的“全部数据行”。同时，第二个事务也修改这个表中的数据，这种修改是向表中插入“一行新数据”。那么，以后就会发生操作第一个事务的用户发现表中还存在没有修改的数据行，就好象发生了幻觉一样。
一般解决幻读的方法是增加范围锁RangeS，锁定检索范围为只读，这样就避免了幻读。
 个人解读：举个栗子，A查询ID（唯一索引）>6的数据，查询结果为空，此时B插入一条ID=6的数据，因为当前A的隔离级别是可重复读，那么当A第二次查询ID>6时，还是空，此时A插入ID=6的数据，会出现ID冲突不能插入。A就是不明白为什么ID=6不存在但是自己就是插入不了，但我们知道为什么。因为A出现了幻读。
事务在插入已经检查过不存在的记录时，惊奇的发现这些数据已经存在了，之前的检测获取到的数据如同鬼影一般。
https://blog.csdn.net/v123411739/article/details/39298127

4. MYSQL有哪些存储引擎,各自优缺点。

MyISAM： 拥有较高的插入，查询速度，但不支持事务
InnoDB ：5.5版本后Mysql的默认数据库，事务型数据库的首选引擎，支持ACID事务，支持行级锁定
BDB： 源自Berkeley DB，事务型数据库的另一种选择，支持COMMIT和ROLLBACK等其他事务特性
Memory ：所有数据置于内存的存储引擎，拥有极高的插入，更新和查询效率。但是会占用和数据量成正比的内存空间。并且其内容会在Mysql重新启动时丢失
Merge ：将一定数量的MyISAM表联合而成一个整体，在超大规模数据存储时很有用
Archive ：非常适合存储大量的独立的，作为历史记录的数据。因为它们不经常被读取。Archive拥有高效的插入速度，但其对查询的支持相对较差
Federated： 将不同的Mysql服务器联合起来，逻辑上组成一个完整的数据库。非常适合分布式应用
Cluster/NDB ：高冗余的存储引擎，用多台数据机器联合提供服务以提高整体性能和安全性。适合数据量大，安全和性能要求高的应用
CSV： 逻辑上由逗号分割数据的存储引擎。它会在数据库子目录里为每个数据表创建一个.CSV文件。这是一种普通文本文件，每个数据行占用一个文本行。CSV存储引擎不支持索引。
BlackHole ：黑洞引擎，写入的任何数据都会消失，一般用于记录binlog做复制的中继

另外，Mysql的存储引擎接口定义良好。有兴趣的开发者通过阅读文档编写自己的存储引擎。
http://baike.baidu.com/item/存储引擎

5.高并发下,如何做到安全的修改同一行数据。
使用悲观锁 悲观锁本质是当前只有一个线程执行操作，结束了唤醒其他线程进行处理。
也可以缓存队列中锁定主键。

♀ 使用悲观锁：悲观锁本质是当前只有一个线程执行操作，排斥外部请求的修改。遇到加锁的状态，就必须等待。结束了唤醒其他线程进行处理。虽然此方案的确解决了数据安全的问题，但是，我们的场景是“高并发”。也就是说，会很多这样的修改请求，每个请求都需要等待“锁”，某些线程可能永远都没有机会抢到这个“锁”，这种请求就会死在那里。同时，这种请求会很多，瞬间增大系统的平均响应时间，结果是可用连接数被耗尽，系统陷入异常。（细节参考5）
 ♂ 也是通过FIFO（First Input First Output，先进先出）缓存队列思路：直接将请求放入队列中，就不会导致某些请求永远获取不到锁。看到这里，是不是有点强行将多线程变成单线程的感觉哈。

   
       
然后，我们现在解决了锁的问题，全部请求采用“先进先出”的队列方式来处理。那么新的问题来了，高并发的场景下，因为请求很多，很可能一瞬间将队列内存“撑爆”，然后系统又陷入到了异常状态。或者设计一个极大的内存队列，也是一种方案，但是，系统处理完一个队列内请求的速度根本无法和疯狂涌入队列中的数目相比。也就是说，队列内的请求会越积累越多，最终Web系统平均响应时候还是会大幅下降，系统还是陷入异常。
 ♀ 使用乐观锁：这个时候，我们就可以讨论一下“乐观锁”的思路了。乐观锁，是相对于“悲观锁”采用更为宽松的加锁机制，大都是采用带版本号（Version）更新。实现就是，这个数据所有请求都有资格去修改，但会获得一个该数据的版本号，只有版本号符合的才能更新成功，其他的返回抢购失败。这样的话，我们就不需要考虑队列的问题，不过，它会增大CPU的计算开销。但是，综合来说，这是一个比较好的解决方案。（具体参考5）

6. SQL优化的一般步骤是什么,怎么看执行计划,如何理解其中各个字段的含义。

查看慢日志（show [session|gobal] status ），定位慢查询，查看慢查询执行计划  根据执行计划确认优化方案
Explain sql
select_type:表示select类型。常见的取值有SIMPLE（简单表，即不使用连接或者子查询）、PRIMARY（主查询，即外层的查询）、UNION（union中的第二个或者后面的查询语句）、SUBQUERY（子查询中的第一个SELECT）等。
talbe：输出结果集的表。
type:表的连接类型。性能由高到底：system（表中仅有一行）、const（表中最多有一个匹配行）、eq_ref、ref、ref_null、index_merge、unique_subquery、index_subquery、range、idnex等
possible_keys:查询时，可能使用的索引
key:实际使用的索引
key_len:索引字段的长度
rows：扫描行的数量
Extra：执行情况的说明和描述

http://blog.csdn.net/hsd2012/article/details/51106285

7.数据库会死锁吗,举一个死锁的例子, mysql怎么解决死锁。

产生死锁的原因主要是：
（1）系统资源不足。
（2） 进程运行推进的顺序不合适。
（3）资源分配不当等。
如果系统资源充足，进程的资源请求都能够得到满足，死锁出现的可能性就很低，否则就会因争夺有限的资源而陷入死锁。其次，进程运行推进顺序与速度不同，也可能产生死锁。
产生死锁的四个必要条件：
（1） 互斥条件：一个资源每次只能被一个进程使用。
（2） 请求与保持条件：一个进程因请求资源而阻塞时，对已获得的资源保持不放。
（3） 不剥夺条件:进程已获得的资源，在末使用完之前，不能强行剥夺。
（4） 循环等待条件:若干进程之间形成一种头尾相接的循环等待资源关系。
这四个条件是死锁的必要条件，只要系统发生死锁，这些条件必然成立，而只要上述条件之一不满足，就不会发生死锁。
这里提供两个解决数据库死锁的方法：
1）重启数据库（谁用谁知道）
2）杀掉抢资源的进程：
先查哪些进程在抢资源：SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX;
杀掉它们：Kill trx_mysql_thread_id；
  


8. Mysql的索引原理,索引的类型有哪些,如何创建合理的索引,索引如何优化。9,聚集索引和非聚集索引的区别,
      MySql索引的原理：
              1）通过不断地缩小想要获取数据的范围来筛选出最终想要的结果，同时把随机的事件变成顺序的事件，也就是说，有了这种索引机制，我们可以总是用同一种查找方式来锁定数据。
               2）索引是通过复杂的算法，提高数据查询性能的手段。从磁盘io到内存io的转变。
       MySql索引原理参考博客：
https://blog.csdn.net/u013235478/article/details/50625677


      MySql索引的类型：
            1）普通索引index：加速查找
             2）唯一索引：   ① 主键索引：primary key：加速查找+主键唯一约束且不为空。
                                        ② 唯一索引：unique：加速查找+主键唯一约束。
             3）联合索引：   ① primary key(id,name)：联合主键索引。
                                        ② unique(id,name)：联合唯一索引。
                                        ③ unique(id,name）：联合普通索引。
             4）全文索引fulltext：用于搜索很长一篇文章的时候，效果最好。
             5）空间索引spatial：了解就好，几乎不用


       创建索引的原则：
           1）最左前缀匹配原则，非常重要的原则，mysql会一直向右匹配直到遇到范围查询(>、<、between、like)就停止匹配，比如a = 1 and b = 2 and c > 3 and d = 4 如果建立(a,b,c,d)顺序的索引，d是用不到索引的，如果建立(a,b,d,c)的索引则都可以用到，a,b,d的顺序可以任意调整。
         2）=和in可以乱序，比如a = 1 and b = 2 and c = 3 建立(a,b,c)索引可以任意顺序，mysql的查询优化器会帮你优化成索引可以识别的形式。
        3）尽量选择区分度高的列作为索引,区分度的公式是count(distinct col)/count(*)，表示字段不重复的比例，比例越大我们扫描的记录数越少，唯一键的区分度是1，而一些状态、性别字段可能在大数据面前区分度就是0，那可能有人会问，这个比例有什么经验值吗？使用场景不同，这个值也很难确定，一般需要join的字段我们都要求是0.1以上，即平均1条扫描10条记录。
        4）索引列不能参与计算，保持列“干净”，比如from_unixtime(create_time) = ’2014-05-29’就不能使用到索引，原因很简单，b+树中存的都是数据表中的字段值，但进行检索时，需要把所有元素都应用函数才能比较，显然成本太大。所以语句应该写成create_time = unix_timestamp(’2014-05-29’)。
        5）尽量的扩展索引，不要新建索引。比如表中已经有a的索引，现在要加(a,b)的索引，那么只需要修改原来的索引即可     
https://blog.csdn.net/zhengzhaoyang122/article/details/79463583
https://blog.csdn.net/zhengzhaoyang122/article/details/82183977 
http://tech.meituan.com/mysql-index.html
http://www.cnblogs.com/cq-home/p/3482101.html

 聚集索引和非聚集索引的区别
     “聚簇”就是索引和记录紧密在一起。
      非聚簇索引 索引文件和数据文件分开存放，索引文件的叶子页只保存了主键值，要定位记录还要去查找相应的数据块。

9.select for update是什么含义,会锁表还是锁行或是其他。
select for update 语句是我们经常使用手工加锁语句。
借助for update子句，我们可以在应用程序的层面手工实现数据加锁保护操作。
属于并发行锁，这个我们上面在悲观锁的时候也有介绍。
https://www.cnblogs.com/micrari/p/8029710.html

10.为什么要用Btree实现,它是怎么分裂的,什么时候分裂,为什么是平衡的。
https://blog.csdn.net/endlu/article/details/51720299

Key 超过1024才分裂
因为随着数据的增多，一个结点的key满了，为了保持B树的特性，就会产生分裂，就向红黑树和AVL树为了保持树的性质需要进行旋转一样！


11.数据库的ACID是什么。

A    Atomic-->原子性，要么都提交，要么都失败，不能一部分成功，一部分失败。
C   Consistent-->一致性，事物开始及结束后，数据的一致性约束没有被破坏
I     Isolation-->隔离性，并发事物间相互不影响，互不干扰。
D   Durability-->持久性，已经提交的事物对数据库所做的更新必须永久保存。即便发生崩溃，也不能被回滚或数据丢失。


12.某个表有近千万数据, CRUD比较慢,如何优化。

数据千万级别之多，占用的存储空间也比较大，可想而知它不会存储在一块连续的物理空间上，而是链式存储在多个碎片的物理空间上。可能对于长字符串的比较，就用更多的时间查找与比较，这就导致用更多的时间。
  1）作为关系型数据库，是什么原因出现了这种大表？是否可以做表拆分，减少单表字段数量，优化表结构。
  2）在保证主键有效的情况下，检查主键索引的字段顺序，使得查询语句中条件的字段顺序和主键索引的字段顺序保持一致。
  3）在程序逻辑中采用手动事务控制，不要每插入一条数据就自动提交，而是定义一个计数器，进行批量手动提交，能够有效提高运行速度。
  

http://www.cainiaoxueyuan.com/sjk/5178.html
https://blog.csdn.net/qq_37221991/article/details/87693639

13.Mysql怎么优化table scan的。

避免在where子句中对字段进行is null判断。
应尽量避免在where 子句中使用!=或<>操作符，否则将引擎放弃使用索引而进行全表扫描。
避免在where 子句中使用or 来连接条件。
in 和not in 也要慎用。
Like查询（非左开头）。
使用NUM=@num参数这种。
 where 子句中对字段进行表达式操作num/2=XX。
在where子句中对字段进行函数操作
  

https://blog.csdn.net/chen1280436393/article/details/80493088

14.如何写sql能够有效的使用到复合素引.
由于复合索引的组合索引，类似多个木板拼接在一起，如果中间断了就无法用了，所以要能用到复合索引，首先开头(第一列)要用上，比如index(a,b) 这种，
我们可以select table tname where a=XX 用到第一列索引  如果想用第二列 可以 and b=XX 或者and b like‘TTT%’

15.mysgl中in和exists区别

mysql中的in语句是把外表和内表作hash 连接，而exists语句是对外表作loop循环，每次loop循环再对内表进行查询。一直大家都认为exists比in语句的效率要高，这种说法其实是不准确的。这个是要区分环境的。
如果查询的两个表大小相当，那么用in和exists差别不大。
如果两个表中一个较小，一个是大表，则子查询表大的用exists，子查询表小的用in：
not in 和not exists如果查询语句使用了not in 那么内外表都进行全表扫描，没有用到索引；而not extsts 的子查询依然能用到表上的索引。所以无论那个表大，用not exists都比not in要快。
1.EXISTS只返回TRUE或FALSE，不会返回UNKNOWN。
2.IN当遇到包含NULL的情况，那么就会返回UNKNOWN。
  


16.数据库自增主键可能的问题.
（1）设置主键自增为何不可取
        这样的话，数据库本身是单点，不可拆库，因为id会重复。
（2）依赖数据库自增机制达到全局ID唯一
 使用如下语句：
REPLACE INTO Tickets64 (stub) VALUES ('a'); 
SELECT LAST_INSERT_ID();

 这样可以保证全局ID唯一，但这个Tickets64表依旧是个单点。
（3）依赖数据库自增机制达到全局ID唯一并消除单点
    在2的基础上，部署两个（多个）数据库实例，
   设置自增步长为2（多个则为实例数），即auto-increment-increment = 2
   设置auto-increment-offset分别为1,2.....
   这样第一台数据库服务器的自增id为 1 3 5 7 9
   第二台为2 4 6 8 10
（4）解决每次请求全局ID都读库写库压力过大的问题
    比如第一次启动业务服务，会请求一个唯一id为3559
   如果是2、3的方法，则id为3559，这样每次都请求数据库，对数据库压力比较大
   可以用3559 * 65536（举个例子，并不一定是65536）+ 内存自增变量来作为id
   当内存自增变量到达65535时，从数据库重新获取一个自增id
   这样即使有多台业务服务器，id也不会重复：
   第一台 3559 * 65536 + 1,2,3.....65535
   第二台 3560 * 65536 + 1,2,3.....65535
   然后第一台到65535了，换一个数据库自增id，这时候可能是3561 * 65536 + 1,2,3....

17. MVCC的含义,如何实现的
 MVCC：Multi-Version Concurrency Control 多版本并发控制，
 MVCC 是一种并发控制的方法，一般在数据库管理系统中，实现对数据库的并发访问；在编程语言中实现事务内存。
 MVCC最大的好处 读不加锁，读写不冲突。在读多写少的OLTP应用中，读写不冲突是非常重要的，极大的增加了系统的并发性能，这也是为什么现阶段，几乎所有的RDBMS，都支持了MVCC。

18.你做过的项目里遇到份库分表了吗,怎么做的,有用到中间件么,比如sharding jdbc等他
们的原理知道么.

 垂直分表：垂直分表在日常开发和设计中比较常见，通俗的说法叫做“大表拆小表”，拆分是基于关系型数据库中的“列”（字段）进行的。通常情况，某个表中的字段比较多，可以新建立一张“扩展表”，将不经常使用或者长度较大的字段拆分出去放到“扩展表”中，如下图所示：

   
       

垂直分库：垂直分库在“微服务”盛行的今天已经非常普及了，基本思路是按照业务模块划分不同的数据库，而不是像早起一样将所有的数据库表都放到同一个库中。

          

 水平分表：水平分表也称为横向分表，比较容易理解，就是将表中不同的数据按照一定规律分布到不通的数据库表中，这样来降低单表的数据量，优化查询性能，水平分表能降低单表数据量，一定程度上可以缓解查询性能的瓶颈，但本质上这些表保存在同一个库中，所以库级别还是会有io瓶颈。      水平分库分表：平分库分表与上面讲到的水平分表思路相同，唯一不同就是将这些拆分出来的表保存在不同的数据库中。


      
https://blog.csdn.net/faye0412/article/details/78351414

19 .MYSQL的主从延迟怎么解决。

实际上主从同步延迟根本没有什么一招制敌的办法，因为所有的SQL必须都要在从服务器里面执行一遍，但是主服务器如果不断的有更新操作源源不断的写入， 那么一旦有延迟产生，那么延迟加重的可能性就会原来越大。 当然我们可以做一些缓解的措施。
 a）最简单的减少slave同步延时的方案就是在架构上做优化，尽量让主库的DDL快速执行。还有就是主库是写，对数据安全性较高，比如 sync_binlog=1，innodb_flush_log_at_trx_commit = 1 之类的设置，而slave则不需要这么高的数据安全，完全可以讲sync_binlog设置为0或者关闭binlog，innodb_flushlog也 可以设置为0来提高sql的执行效率。另外就是使用比主库更好的硬件设备作为slave。
 b）把一台从服务器当作备份使用， 而不提供查询， 这样他的负载就下来了， 执行relay log 里面的SQL效率自然就高了。 
 c）增加从服务器，这个目的还是分散读的压力， 从而降低服务器负载。


20.数据库的三范式是什么？

第一范式:强调的是列的原子性，即数据库表的每一列都是不可分割的原子数据项。
第二范式:要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性。
第三范式:任何非主属性不依赖于其它非主属性。


21.一张自增表里面总共有 7 条数据，删除了最后 2 条数据，重启 mysql 数据库，又插入了一条数据，此时 id 是几？

表类型如果是MyISAM，那id就是8。
表类型如果是InnoDB，那id就是6。
InnoDB表只会把自增主键的最大id记录在内存中,所以重启之后会导致最大id丢失。


22.如何获取当前数据库版本？

使用select version()获取当前MysQL数据库版本。


23.char 和 varchar 的区别是什么？
char(n) ：固定长度类型,比如订阅cha(10)，当你输入"abe"三个字符的时候，它们占的空间还是10个字节，其他7个是空字节。
   char优点：效率高；缺点：占用空间;
   适用场量：存储密码的nd5值,固定长度的，使用char非常合适。
varchar(n) ：可变长度,存储的值是每个值占用的字节再加上一个用来记录其长度的字节的长度。
所以，从空间上考虑varcahr比较合适；从效率上考虑char比较合适,二者使用需要权衡。

24.float 和 double 的区别是什么？

float最多可以存储8位的十进制数，并在内存中占4字节。
double最多可以存储16位的十进制数，并在内存中占8字节。


25.mysql 的内连接、左连接、右连接有什么区别？

内连接关键字：inner join；左连接: leftjoin；右连接：right join.
内连接是把匹配的关联数据显示出来
左连接是左边的表全部显示出来,
右边的表显示出符合条件的数据；右连接正好相反。


26.怎么验证 mysql 的索引是否满足需求？


 
27.说一下 mysql 常用的引擎？


28.说一下 mysql 的行锁和表锁？
MyISAM只支持表锁， InnoDB支持表锁和行锁,默认为行锁。

表级锁:开销小，加锁快，不会出现死锁。锁定粒度大,发生锁冲突的概率最高，并发量最低。
行级锁:开销大，加锁慢，会出现死锁。锁力度小,发生锁冲突的概率小，并发度最高。


29.说一下乐观锁和悲观锁？

乐观锁:每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在提交更新的时候会判断一下在此期间别人有没有去更新这个数据。
悲观锁:每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁,这样别人想拿这个数据就会阻止，直到这个锁被释放。
数据库的乐观锁需要自己实现,在表里面添加一个version字段，每次修改成功值加1,这样每次修改的时候先对比一下， 自己拥有的version和数据库现在的version是否-致,如果不一致就不修改,这样就实现了乐观锁。


30.mysql 问题排查都有哪些手段？

使用show processlist命令查看当前所有连接信息,
使用explain命令查询SQL语句执行计划。
开启慢查询日志,查看慢查询的SQL.


31.count(*)，count(1)和count(字段) 的区别
count(1)和count(*)都会对全表进行扫描，统计所有记录的条数，包括那些为null的记录，因此，它们的效率可以说是相差无几。而count(字段)则与前两者不同，它会统计该字段不为null的记录条数。
下面它们之间的一些对比：

在表没有主键时，count(1)比count(*)快；
有主键时，主键作为计算条件，count(主键)效率最高；
若表格只有一个字段，则count(*)效率较高。


32.平常用到了什么索引优化，如何优化limit，如何优化 
在表上创建索引后，如何使用到这些索引需要注意的问题。
1.索引列上不能使用表达式或函数。
例如：select * from users where upper(name)=’ABC';

改成：select * from users where  name=’ABC';
2.前缀索引和索引列的选择性
   索引的选择性越高索引效率越高。
3.联合索引
    如何选择索引列的顺序
   1.经常会被使用到的列优先
     联合索引的列索引顺序是从左到右使用的。
    2.选择性高的列优先
   选择性很差的列不宜放到最左边。比如状态列。
    3.宽度小的列优先
4.覆盖索引
索引中包含了所有查询的字段的情况的索引。
优点：
    可以优化缓存，减少磁盘IO操作。
   可以减少随机IO 变随机IO为顺序IO操作。
   避免对INNODB主键索引的二次查询
   可以避免myisam表进行系统调用
无法使用覆盖索引的情况：
   1.存储引擎不支持覆盖索引
   2.查询中使用了太多的列。
   3.使用了双%号的like查询
5.使用索引扫描优化排序
  索引的列顺序和order by 子句的顺序完全一致
  索引中所有列的方向（升序和降序）和order by 子句完全一致
  order by 中 的字段全部在关联表中的第一张表中。
6.利用索引优化锁
  1.索引可以减少锁定的行数
  2.索引可以加快处理速度，同时加快锁的释放。
7.删除重复和冗余的索引
重复的索引：
比如：primary key(id),unique key (id) ,index (id);
这样索引就重复了
冗余的索引：
index(name) ,index(name,age) 联合索引，那么 index(name) 就冗余了。
可以使用工具
pt-duplicate-key-checker –h=localhost 检查重复索引。
查找未被使用过的索引：
更新索引统计信息及减少索引碎片
analyze table table_name;

35.哪些情况会引起索引的失效
   索引并不是时时都会生效的，比如以下几种情况，将导致索引失效：

如果条件中有or，即使其中有条件带索引也不会使用(这也是为什么尽量少用or的原因)

　    　注意：要想使用or，又想让索引生效，只能将or条件中的每个列都加上索引

对于多列索引，不是使用的第一部分，则不会使用索引
Like查询是以%开头
如果列类型是字符串，那一定要在条件中将数据使用引号引用起来,否则不使用索引
如果mysql估计使用全表扫描要比使用索引快,则不使用索引


36.多表查询怎么优化
   交代一下背景，这算是一次项目经验吧，属于公司一个已上线平台的功能，这算是离职人员挖下的坑，随着数据越来越多，原本的SQL查询变得越来越慢，用户体验特别差，因此SQL优化任务交到了我手上。 
 这个SQL查询关联两个数据表，一个是攻击IP用户表主要是记录IP的信息，如第一次攻击时间，地址，IP等等，一个是IP攻击次数表主要是记录每天IP攻击次数。而需求是获取某天攻击IP信息和次数。（以下SQL语句测试均在测试服务器上上，正式服务器的性能好，查询时间快不少。）
查看表的行数： 
 
 
 未优化前SQL语句为：
SELECT
   attack_ip,
   country,
   province,
   city,
   line,
   info_update_time AS attack_time,
   sum( attack_count ) AS attack_times
FROM
  `blacklist_attack_ip`
INNER JOIN `blacklist_ip_count_date` ON `blacklist_attack_ip`.`attack_ip` = `blacklist_ip_count_date`.`ip`
WHERE
`attack_count` > 0
 AND `date` BETWEEN '2017-10-13 00:00:00'
 AND '2017-10-13 23:59:59'
 GROUP BY
 `ip`
 LIMIT 10 OFFSET 1000
AIN分析一下： 

 这里看到索引是有的，但是IP攻击次数表blacklist_ip_count_data也用上了临时表。那么这SQL不优化直接第一次执行需要多久（这里强调第一次是因为MYSQL带有缓存功能，执行过一次的同样SQL，第二次会快很多。） 

 实际查询时间为300+秒，这完全不能接受呀，这还是没有其他搜索条件下的。 
 那么我们怎么优化呢，索引既然走了，我尝试一下避免临时表，这时我们先了解一下临时表跟group by的使联系:

查找了网上一些博客分析GROUP BY 与临时表的关系 : 
 　　1. 如果GROUP BY 的列没有索引,产生临时表. 
 　　2. 如果GROUP BY时,SELECT的列不止GROUP BY列一个,并且GROUP BY的列不是主键 ,产生临时表. 
 　　3. 如果GROUP BY的列有索引,ORDER BY的列没索引.产生临时表. 
 　　4. 如果GROUP BY的列和ORDER BY的列不一样,即使都有索引也会产生临时表. 
 　　5. 如果GROUP BY或ORDER BY的列不是来自JOIN语句第一个表.会产生临时表. 
 　　6. 如果DISTINCT 和 ORDER BY的列没有索引,产生临时表.

其实，9W的临时表并不算多，那么为什么导致会这么久的查询呢？我们想想这没优化的SQL的执行过程是怎么样的呢？
网上搜索得知内联表查询一般的执行过程是：
1、执行FROM语句
2、执行ON过滤
3、添加外部行
4、执行where条件过滤
5、执行group by分组语句
6、执行having
7、select列表
8、执行distinct去重复数据
9、执行order by字句
10、执行limit字句
第一种优化：Mysql 是先执行内联表然后再进行条件查询的最后再分组,那么想想这SQL的条件查询和分组都只是一个表的，内联后数据就变得臃肿了，这时候再进行条件查询和分组是否太吃亏了，
我们可以尝试一下提前进行分组和条件查询，实现方法就是子查询联合内联查询。 

 这里EXPLAIN看来，只是多了子查询，ROWS和临时表都没有变化。那么我们看看实际的效果呢？ 

可见，取出来的数据完全一模一样，可是优化后效率从原来的330秒变成了0.28秒，这里足足提升了1000多倍的速度。这也基本满足了我们的优化需求。
 第二种优化：
        这里用的是内联表查询，大家都是知道子查询完全是可以代替内联表查询的，只不过SQL语句复杂了不少，那么我们分析一下这SQL，两个表分表提供了什么？ 
1、IP攻击次数表blacklist_ip_count_data主要提供的指定时间条件查询，攻击次数条件查询后的IP和每个IP符合条件下的具体攻击次数。 
 2、攻击IP用户表blacklist_attack_ip主要是具体IP的信息，如第一次攻击时间，地址，IP等等。 
 那么我们一步步来： 
 1、IP攻击次数表blacklist_ip_count_data获取符合时间条件和攻击次数的IP并且以IP分组： 
 
 2、攻击IP用户表blacklist_attack_ip指定具体的IP获取信息： 
 
 然后结合在一起： 

 可见，取出来的数据完全一模一样，可是优化后效率从原来的330秒变成了0.28秒，这里足足提升了1000多倍的速度。这也基本满足了我们的优化需求。 
 我们EXPLAIN了解一下情况： 


37.聚集索引和非聚集索引知道吗？什么情况用聚集索引什么情况用非聚集索引
根本区别
    聚集索引和非聚集索引的根本区别是表记录的排列顺序和与索引的排列顺序是否一致。
聚集索引
    聚集索引表记录的排列顺序和索引的排列顺序一致，所以查询效率快，只要找到第一个索引值记录，其余就连续性的记录在物理也一样连续存放。聚集索引对应的缺点就是修改慢，因为为了保证表中记录的物理和索引顺序一致，在记录插入的时候，会对数据页重新排序。
非聚集索引
    非聚集索引制定了表中记录的逻辑顺序，但是记录的物理和索引不一定一致，两种索引都采用B+树结构，非聚集索引的叶子层并不和实际数据页相重叠，而采用叶子层包含一个指向表中的记录在数据页中的指针方式。非聚集索引层次多，不会造成数据重排。
例子对比两种索引
     聚集索引就类似新华字典中的拼音排序索引，都是按顺序进行，例如找到字典中的“爱”，就里面顺序执行找到“癌”。而非聚集索引则类似于笔画排序，索引顺序和物理顺序并不是按顺序存放的。
索引创建Demo
create database IndexDemo 
go 
use IndexDemo 
go 
create table ABC 
( 
A int not null, 
B char(10), 
C varchar(10) 
) 
go 
insert into ABC select 1,'B','C' 
union select 5,'B','C' 
union select 7,'B','C' 
union select 9,'B','C' 
go select * from abc

这个时候查看表记录，如图一显示
这个时候插入一条数据，
insert into abc values('6','B','C')

此时的查询记录为图二展示
 添加聚集索引，再查询数据显示为图三，此时发现表的顺序发生了变化，此时的排序按A字段的递增排序。
create clustered index CLU_ABC on abc(A) 
删除聚集索引，会发现表的顺序不会发生改变。
drop index abc.CLU_ABC

添加非聚集索引，添加新的记录，查看表顺序，如图四，并没有影响表的顺序。
create nonclustered index NONCLU_ABC on abc(A) 
insert into abc values('4','B','C')
【总结】
     关于聚集索引和非聚集索引小编也就知道这么多了，感觉一个小小的索引用法还要很多种啊，要想真正的用好还是不怎么容易的。理论和简单的demo都做了，剩下的就是在项目中实战了！相信未来会更美好的，O(∩_∩)O哈哈~。
涉及频繁的update的列最好用非聚集索引，因为频繁的update会频繁的改变索引结构

39.如何定位一个慢查询，一个服务有多条SQL你怎么快速定位
1，slow_query_log
    这个参数设置为ON，可以捕获执行时间超过一定数值的SQL语句。
2，long_query_time
    当SQL语句执行时间超过此数值时，就会被记录到日志中，建议设置为1或者更短。
3，slow_query_log_file
   记录日志的文件名。
4，log_queries_not_using_indexes
    这个参数设置为ON，可以捕获到所有未使用索引的SQL语句，尽管这个SQL语句有可能执行得挺快。

40.在 oracle 数据库中需要查询出前 8 条记录的 sql 语句怎么写？
SELECT * FROM 表名 WHERE ROWNUM<=10
补充：ROWNUM是一个序列，是oracle数据库从数据文件或缓冲区中读取数据的顺序。
它取得第一条记录则rownum值为1，第二条为2，依次类推。小于等于10，则就会只取前10条记录。

41.如果有很多数据插入MYSQL 你会选择什么方式?
 利用mybatis的foreach 拼接动态sql或者java中写循环拼接，将数据分组拼接成大sql，
比如可以每1万行数据拼接为一个insert语句
设置Mybatis的sqlsession的ExecutorType为batch,如果用jdbc则用executeBatch

42.如果查询很慢，你会想到的第一个方式是什么？索引是干嘛的?
sql语句优化或者该数据表添加索引，
就比如一本书，你想看第六章第六节讲的是什么，你会怎么做，一般人肯定去看目录，
找到这一节对应的页数，然后翻到这一页。这就是目录索引，帮助读者快速找到想要的章节。
在数据库中，我们也有索引，其目的当然和我们翻书一样，能帮助我们提高查询的效率。
索引就像目录一样，减少了计算机工作量，对于表记录较多的数据库来说是非常实用的，
可以大大的提高查询的速度。否则的话，如果没有索引，计算机会一条一条的扫描，
每一次都要扫描所有的记录，浪费大量的cpu时间。

我们都知道对于一个无序的表，和一个有序的表，有序表的查询方法会有更多地选择，
每种查询方法的效率也不同，其实为表建立索引，也就是对表中的记录按照索引字段排序。
 

43.怎么看是否用到了了某个索引？
1、查询表中的索引
   select * from user_indexes where table_name='WORKLOG'；（大写表名）
我查询出并选择索引是PK_WORKLOG该索引建在LINTERID字段上，
2、另 查询所有聚集型索引（与分析索引无关）
select * from user_indexes where uniqueness='UNIQUE'
3、确定了表和表中的索引后，就要执行分析索引的语句，如下
alert index PK_WORKLOG monitoring usage;
这时候数据库会监控索引的使用情况
4、执行相关的sql语句，如
select * from WORKLOG  T where  T.LINTERID='110';
被分析的索引一定要在查询条件里，这样索引才能被分析
5、最后查询索引的使用情况。
select  table_name,index_name,used from v$object_usage;
在used列就可以看到索引是否被使用，
由此分析，在复杂的sql语句语句中可以将语句分离，可以先单独的分析每个表的索引使用情况

44.like %aaa%会使用索引吗? like aaa%呢?
     like 要是使用索引 就必须这样写 like ‘a%’ ，两边都加上是不会触发索引的。 
想想你也知道，没有一个确切的值怎么能按一定条件查找数据呢？‘%a%’这种写法只会造成全表扫描。
但是下面的SQL将走全表扫描（不会使用索引） 
SELECT * FROM jka WHERE v LIKE '%ABC';

45.drop、truncate、delete的区别？
（1）DELETE语句执行删除的过程是每次从表中删除一行，并且同时将该行的删除操作作为事务记录在日志中保存以便进行进行回滚操作。
   TRUNCATE TABLE 则一次性地从表中删除所有的数据并不把单独的删除操作记录记入日志保存，删除行是不能恢复的。并且在删除的过程中不会激活与表有关的删除触发器。执行速度快。
（2）表和索引所占空间。
   当表被TRUNCATE 后，这个表和索引所占用的空间会恢复到初始大小，
   DELETE操作不会减少表或索引所占用的空间。
   drop语句将表所占用的空间全释放掉。
（3）一般而言，drop > truncate > delete
（4）应用范围。
    TRUNCATE 只能对TABLE；         DELETE可以是table和view
（5）TRUNCATE 和DELETE只删除数据， DROP则删除整个表（结构和数据）。
（6）truncate与不带where的delete ：只删除数据，而不删除表的结构（定义）drop语句将删除表的结构被依赖的约束（constrain),触发器（trigger)索引（index);依赖于该表的存储过程/函数将被保留，但其状态会变为：invalid。
（7）delete语句为DML（data maintain Language),这个操作会被放到 rollback segment中,事务提交后才生效。如果有相应的 tigger,执行的时候将被触发。
（8）truncate、drop是DLL（data define language),操作立即生效，原数据不放到 rollback segment中，不能回滚
（9）在没有备份情况下，谨慎使用 drop 与 truncate。要删除部分数据行采用delete且注意结合where来约束影响范围。回滚段要足够大。要删除表用drop;若想保留表而将表中数据删除，如果于事务无关，用truncate即可实现。如果和事务有关，或老师想触发trigger,还是用delete。
（10） Truncate table 表名 速度快,而且效率高,因为: 
 truncate table 在功能上与不带 WHERE 子句的 DELETE 语句相同：二者均删除表中的全部行。但 TRUNCATE TABLE 比 DELETE 速度快，且使用的系统和事务日志资源少。DELETE 语句每次删除一行，并在事务日志中为所删除的每行记录一项。TRUNCATE TABLE 通过释放存储表数据所用的数据页来删除数据，并且只在事务日志中记录页的释放。 
（11） TRUNCATE TABLE 删除表中的所有行，但表结构及其列、约束、索引等保持不变。新行标识所用的计数值重置为该列的种子。如果想保留标识计数值，请改用 DELETE。如果要删除表定义及其数据，请使用 DROP TABLE 语句。 
（12） 对于由 FOREIGN KEY 约束引用的表，不能使用 TRUNCATE TABLE，而应使用不带 WHERE 子句的 DELETE 语句。由于 TRUNCATE TABLE 不记录在日志中，所以它不能激活触发器。
一、delete
1、delete是DML，执行delete操作时，每次从表中删除一行，并且同时将该行的的删除操作记录在redo和undo表空间中以便进行回滚（rollback）和重做操作，但要注意表空间要足够大，需要手动提交（commit）操作才能生效，可以通过rollback撤消操作。
2、delete可根据条件删除表中满足条件的数据，如果不指定where子句，那么删除表中所有记录。
3、delete语句不影响表所占用的extent，高水线(high watermark)保持原位置不变。
二、truncate
1、truncate是DDL，会隐式提交，所以，不能回滚，不会触发触发器。
2、truncate会删除表中所有记录，并且将重新设置高水线和所有的索引，缺省情况下将空间释放到minextents个extent，除非使用reuse storage，。不会记录日志，所以执行速度很快，但不能通过rollback撤消操作（如果一不小心把一个表truncate掉，也是可以恢复的，只是不能通过rollback来恢复）。
3、对于外键（foreignkey ）约束引用的表，不能使用 truncate table，而应使用不带 where 子句的 delete 语句。
4、truncatetable不能用于参与了索引视图的表。
三、drop
1、drop是DDL，会隐式提交，所以，不能回滚，不会触发触发器。
2、drop语句删除表结构及所有数据，并将表所占用的空间全部释放。
3、drop语句将删除表的结构所依赖的约束，触发器，索引，依赖于该表的存储过程/函数将保留,但是变为invalid状态。
总结：
1、在速度上，一般来说，drop> truncate > delete。
2、在使用drop和truncate时一定要注意，虽然可以恢复，但为了减少麻烦，还是要慎重。
3、如果想删除部分数据用delete，注意带上where子句，回滚段要足够大；
   如果想删除表，当然用drop； 
   如果想保留表而将所有数据删除，如果和事务无关，用truncate即可；
   如果和事务有关，或者想触发trigger，还是用delete；
   如果是整理表内部的碎片，可以用truncate跟上reuse stroage，再重新导入/插入数据。

46.你们数据库是否支持emoji表情，如果不支持，如何操作?
mysql数据库的默认字符集utf8，只能存储3个字节的数据。
标准的emoji表情是4个字节，在APP端输入保存表情是用户的普遍需求和行为。
   插入数据库报错如下：
   java.sql.SQLException: Incorrect string value: '\xF0\x9F\x92\xAA",...' for column 'raw_json' at row 1, 异常:org.springframework.jdbc.UncategorizedSQLException: 
   解决方式：更换字符集utf8-->utf8mb4      mb4的意思是most bytes 4，专门为兼容四个字节的。utf8mb4是向下兼容utf8的，所以即便修改了字段的字符集也不会影响线上数据。
   前提：mysql大于5.5.3版本。
   步骤： 1.修改字段的字符集
    ALTER table mb_touchpay_record  modify  clientName  varchar(100) character set utf8mb4 collate utf8mb4_unicode_ci
 2.表   ALTER table mb_touchpay_record charset=utf8mb4;
 3.库    set names utf8mb4

47.你们的数据库单表数据量是多少？一般多大的时候开始出现查询性能急剧下降？
    跟mysql版本有关系，如果是5.7的话，是几千万。但是5.7之后基本上就不用考虑数据量的问题了。但是这个问题问的不好，因为性能急剧下降不但但是跟数据量这一个因素有关系。
    还有机器的配置，比如内存，如果内存放不下索引而把索引放在了虚拟内存上，那么效率就会急剧下降了。
 还有就是sql建立合适的索引了。

48.查询死掉了，想要找出执行的查询进程用什么命令？找出来之后一般你会干嘛？
如果查询到脏数据 或者没有的数据
mysql 就可能会“死掉”必须用net stop mysql 停止服务 ，
再用net start mysql 启动服务才行

49.读写分离是怎么做的？你认为中间件会怎么来操作？这样操作跟事务有什么关系？
①.读写分离的实现原理就是在执行SQL语句的时候，判断到底是读操作还是写操作，把读的操作转向到读的服务器上（从服务器，一般是多台），写的操作转到写的服务器上（主服务器，一般是一台），当然为了保证多台数据库数据的一致性，需要主从复制。
主从复制的实现原理是：
       mysql中有一种日志，叫做bin日志（二进制日志），会记录下所有修改过数据库的sql语句。
 主从复制的原理实际是多台服务器都开启bin日志，然后主服务器会把执行过的sql语句记录到bin日志中，之后从服务器读取这个bin日志，把该日志的内容保存到自己中继日志里面，从服务器再把中继日志中记录的sql语句同样的执行一遍，这样从服务器上的数据就和主服务器相同了。
 ②.中间件有淘宝开源的cobar，以及后来开源社区根据cobar进行二次开发的mycat

50.分库分表有没有做过？线上的迁移过程是怎么样的？如何确定数据是正确的？
分表分库

水平拆分：依据表中的数据的逻辑关系，将同一个表中的数据依照某种条件拆分到多台数据库（主机）上面。按照1个或多个字段以及相应的规则，将一张表重的数据分到多张表中去。比如按照id%5的规则，将一张大表拆分成5张小表。适合具有超大表的系统。
垂直拆分：依照不同的表（或者Schema）来切分到不同的数据库（主机）之上。一般按照模块来分库。适合各业务之间耦合度非常低的系统。

隔离级别

read uncommit:读不加锁，写加共享锁。会产生脏读、幻读。
read commit：读加共享锁，写加排它锁，但不加间隙锁。间隙锁的主要作用是防止不可重复读，但会加大锁的范围。
repeatable read(innodb默认):读加共享锁，写加间隙排它锁。注意，Innodb对这个级别进行了特殊处理，使得这个级别能够避免幻读，但不是所有引擎都能够防止幻读！(网易面试官问)
serialization：会给整张表加锁，强一致，但是效率低。

对于SQL慢查询的优化？（主要是从查询语句和数据库表设计两个方面来考虑，查询语句方面可以增加索引，增加查询筛选的限制条件；数据库表设计的时候可以拆分表，设计得更细粒度。但是后来才发现面试官想要的就是查询大量数据的慢查询问题的优化。）

51. 你建过索引吗? 建索引的原则
1．选择唯一性索引
     唯一性索引的值是唯一的，可以更快速的通过该索引来确定某条记录。例如，学生表中学号是具有唯一性的字段。为该字段建立唯一性索引可以很快的确定某个学生的信息。如果使用姓名的话，可能存在同名现象，从而降低查询速度。
2．为经常需要排序、分组和联合操作的字段建立索引
经常需要ORDER BY、GROUP BY、DISTINCT和UNION等操作的字段，排序操作会浪费很多时间。如果为其建立索引，可以有效地避免排序操作。
3．为常作为查询条件的字段建立索引
如果某个字段经常用来做查询条件，那么该字段的查询速度会影响整个表的查询速度。因此，为这样的字段建立索引，可以提高整个表的查询速度。
4．限制索引的数目
索引的数目不是越多越好。每个索引都需要占用磁盘空间，索引越多，需要的磁盘空间就越大。修改表时，对索引的重构和更新很麻烦。越多的索引，会使更新表变得很浪费时间。
5．尽量使用数据量少的索引
如果索引的值很长，那么查询的速度会受到影响。例如，对一个CHAR(100)类型的字段进行全文检索需要的时间肯定要比对CHAR(10)类型的字段需要的时间要多。
6．尽量使用前缀来索引
如果索引字段的值很长，最好使用值的前缀来索引。例如，TEXT和BLOG类型的字段，进行全文检索会很浪费时间。如果只检索字段的前面的若干个字符，这样可以提高检索速度。
7．删除不再使用或者很少使用的索引
表中的数据被大量更新，或者数据的使用方式被改变后，原有的一些索引可能不再需要。数据库管理员应当定期找出这些索引，将它们删除，从而减少索引对更新操作的影响。
8 . 最左前缀匹配原则，非常重要的原则。
mysql会一直向右匹配直到遇到范围查询(>、<、between、like)就停止匹配，比如a 1=”” and=”” b=”2” c=”“> 3 and d = 4 如果建立(a,b,c,d)顺序的索引，d是用不到索引的，如果建立(a,b,d,c)的索引则都可以用到，a,b,d的顺序可以任意调整。
9 .=和in可以乱序。
比如a = 1 and b = 2 and c = 3 建立(a,b,c)索引可以任意顺序，mysql的查询优化器会帮你优化成索引可以识别的形式
10 . 尽量选择区分度高的列作为索引。
区分度的公式是count(distinct col)/count(*)，表示字段不重复的比例，比例越大我们扫描的记录数越少，唯一键的区分度是1，而一些状态、性别字段可能在大数据面前区分度就 是0，那可能有人会问，这个比例有什么经验值吗？使用场景不同，这个值也很难确定，一般需要join的字段我们都要求是0.1以上，即平均1条扫描10条 记录
11 .索引列不能参与计算，保持列“干净”。
比如from_unixtime(create_time) = ’2014-05-29’就不能使用到索引，原因很简单，b+树中存的都是数据表中的字段值，但进行检索时，需要把所有元素都应用函数才能比较，显然成本 太大。所以语句应该写成create_time = unix_timestamp(’2014-05-29’);
12 .尽量的扩展索引，不要新建索引。 
 比如表中已经有a的索引，现在要加(a,b)的索引，那么只需要修改原来的索引即可
注意：选择索引的最终目的是为了使查询的速度变快。上面给出的原则是最基本的准则，但不能拘泥于上面的准则。读者要在以后的学习和工作中进行不断的实践。根据应用的实际情况进行分析和判断，选择最合适的索引方式。
索引的理解：
   索引是对数据库表中的一列或多列的值进行排序的一种数据结构。 
   索引的作用就类似于书本的目录，新华字典的拼音，偏旁部首的首查字，可以快速的检索到需要的内容，mysql在300万条记录性能就下降了，虽然mysql官方文档说达500万~800万，所以当数据达到几百万的时候，那么索引就很有必要了。 
   当表中有大量记录的时候，若要对表进行查询，第一种就是就需要把表中的记录全部取出来，在和查询条件一一对比，然后返回满足条件的记录、这样做就会大大消耗数据库系统的时间，并造成大量磁盘I/O操作；第二种就是在表中建立索引，然后在索引中找到符合查询条件的索引值，最后通过保存在索引中ROWID(相当于页码)快速找到表中的记录。
语句：
CREATE TABLE table_name[filed_name data type] 
[unique|fulltext][index|key][index_name](filed_name[length])[asc|desc]
unique|fulltext为可选参数，分别表示唯一索引、全文索引
 index和key为同义词，两者作用相同，用来指定创建索引
 filed_name为需要创建索引的字段列，该列必须从数据表中该定义的多个列中选择
 index_name指定索引的名称，为可选参数，如果不指定，默认filed_name为索引值
 length为可选参数，表示索引的长度，只有字符串类型的字段才能指定索引长度
 asc或desc指定升序或降序的索引值存储

 索引类型:
 一、唯一索引(unique):列的值必须唯一，但允许有空值。如果是组合索引则列值必须唯一
 1)、创建唯一索引
CREATE UNIQUE INDEX index_name ON table(column(length))
2)、修改表结构
ALTER TABLE table_name ADD UNIQUE INDEX index_name ON (column(length))
3)、创建表时直接指定
CREATE TABLE `table_name`( 
`id` INT(11) NOT NULL AUTO_INCREMENT, 
`code` INT(8) NOT NULL, 
`title` VARCHAR(255) NOTNULL, 
`content` TEXT, 
`time` INT(10) NULL DEFAULT NULL, 
UNIQUE index_name(code) 
);
二、主键索引(primary key):是一特殊的唯一索引，一个表允许有一个主键，主键要求建表时指定.
CREATE TABLE `table_name`( 
`id` INT(11) NOT NULL AUTO_INCREMENT, 
`code` INT(8) NOT NULL, 
`title` VARCHAR(255) NOTNULL, 
`content` TEXT, 
`time` INT(10) NULL DEFAULT NULL, 
PRIMARY KEY(`id`) 
);
三、普通索引(index)：最基本的索引，没有任何限制。如果是char,varchar类型，length可以小于字段长度、如果是BLOB和TEXT类型，必须指定长度。
 1)、直接创建
CREATE INDEX index_name ON table(column(length))
2)、修改表结构的方式添加
ALTER TABLE table_name ADD INDEX index_name ON (column(length))
3)、创建表时直接指定
CREATE TABLE `table_name`( 
`id` INT(11) NOT NULL AUTO_INCREMENT, 
`title` VARCHAR(255) NOTNULL, 
`content` TEXT, 
`time` INT(10) NULL DEFAULT NULL, 
PRIMARY KEY(`id`), 
INDEX index_name(title(length)) 
);
4)、删除索引
DROP INDEX index_name ON table
四、多列索引:指多个字段上创建的索引，只有在查询条件中使用了创建索引时的第一个字段索引才会使用。使用组合索引遵循最左前缀原则
 五、全文索引(fulltext)：主要是用来查找文本的关键字，而不是直接与索引中的值比较。fulltext索引跟其他索引大不相同，它更像一个搜索引擎，而不是简单的where语句的参数匹配。fulltext要配合match against操作使用，而不是一般的where语句加like。它可以在create table、alter table、create index使用，不过目前只有char varchar text列上可以创建全文索引。
 tip:全文索引只有MyISAM支持，不过在mysql5.6后Innodb也支持了
1)、创建表的时候添加全文索引

CREATE TABLE `table_name`( 
`id` INT(11) NOT NULL AUTO_INCREMENT, 
`title` VARCHAR(255) NOTNULL, 
`content` TEXT, 
`time` INT(10) NULL DEFAULT NULL, 
FULLTEXT (content) 
);
2)、修改表结构添加全文索引
ALTER TABLE table_name ADD FULLTEXT index_name(content)
3)、直接创建索引
CREATE FULLTEXT INDEX index_namet ON table_name(content)
缺点：
 虽然索引大大的提升了查询的速度，同时也降低了对表的增删改的速度，因为更新表，不仅要保存数据，还要保存索引文件
 建立索引会占用磁盘空间。一般不太严重，如果你在一个大表上创建多种组合索引，索引文件会增长很快索引只是提高效率的一个因素，如果有大数据量的表，就要花时间研究建立最优秀的索引，或优化查询语句
 索引方式：
     对于BTREE和HASH索引，当使用=、<=>、IN、IS NULL或者IS NOT NULL操作符时，关键元素与常量值的比较关系对应一个范围条件。Hash索引还有一些其它特征：它们只用于使用=或<=>操作符的等式比较(但很快)。优化器不能使用hash索引来加速ORDER BY操作。(该类索引不能用来按顺序搜索下一个条目）。MySQL不能确定在两个值之间大约有多少行(这被范围优化器用来确定使用哪个索引)。如果你将一个MyISAM表改为hash-索引的MEMORY表，会影响一些查询。只能使用整个关键字来搜索一行。(用B-树索引，任何关键字的最左面的前缀可用来找到行)。
    对于BTREE索引，当使用>、<、>=、<=、BETWEEN、!=或者<>，或者LIKE ‘pattern’(其中 ‘pattern’不以通配符开始)操作符时，关键元素与常量值的比较关系对应一个范围条件。“常量值”系指：查询字符串中的常量、同一联接中的const或system表中的列、无关联子查询的结果、完全从前面类型的子表达式组成的表达式。
下面是一些WHERE子句中有范围条件的查询的例子。 
 下列范围查询适用于 btree索引和hash索引：
SELECT * FROM t1 WHERE key_col = 1 OR key_col IN (15,18,20);
下列范围查询适用于btree索引
SELECT * FROM t1 WHERE key_col > 1 AND key_col < 10; 
SELECT * FROM t1 WHERE key_col LIKE 'ab%' OR key_col BETWEEN 'bar' AND 'foo';
创建索引原则与使用索引注意事项：
 选择唯一索引
唯一索引的值是唯一的，可以更快速的通过该索引确定某一条记录
为经常需要排序、分组和联合操作的字段建立索引
经常需要order by、 group by、distinct和union等操作的字段，排序会浪费很多时间,如果为其建立索引，可以有效避免排序操作
经常作为查询条件的字段建立索引
如果某个字段经常作为查询条件，name该字段的查询速度就会影响整个表的速度。因此，为这样的字段建立索引，可以提高整个表的查询速度
限制索引的数目
索引的数目不是越多越好。每个索引都是要占用磁盘空间的，索引越多，需要的磁盘空间就越大。修改表时，和更新会很麻烦。越多的索引，会使更新表变得很浪费时间
尽量使用数据量少的索引
如果索引的值很长，那么查询的速度就会受到影响，例如对一个char(100)类型的字段进行全文检索需要的时间肯定要比char(10)类型的字段需要的时间多得多，并且char(10)全文检索而且可以节省磁盘空间和I/O操作。
尽量使用前缀来索引
如果索引字段的值很长，最好使用值的前缀来索引。例如，TEXT和BLOG类型的字段，进行全文检索会很浪费时间。如果只检索字段的前面的若干个字符，这样可以提高检索速度。
删除不再使用或者很少使用的索引
表中的数据被大量更新，或者数据使用方式被改变后，原有的一些索引可能不在需要。数据库管理员应当定期找出这些索引，将它们删除。从而减少索引对更新操作的影响
最左前缀原则，非常重要的一个原则
mysql会一直向右匹配知道遇到范围查询(>、<、between、like)就停止匹配，比如a=1 and b=2 and c>3 and d=4 如果建立(a,b,c,d)顺序索引，d是用不到索引的，如果是建立(a,b,d,c)则可以都用到
=和in可以乱序
比如a = 1 and b = 2 and c = 3 建立(a,b,c)索引可以任意顺序，mysql的查询优化器会帮你优化成索引可以识别的形式
尽量选择区分度高的列作为索引。
区分度的公式是count(distinct col)/count(*)，表示字段不重复的比例，比例越大我们扫描的记录数越少，唯一键的区分度是1，而一些状态、性别字段可能在大数据面前区分度就 是0，那可能有人会问，这个比例有什么经验值吗？使用场景不同，这个值也很难确定，一般需要join的字段我们都要求是0.1以上，即平均1条扫描10条 记录
索引列不能参与计算，保持列“干净”。
select * from users where YEAR(adddate)<'2007'; 
 将在每个行上进行运算，这将导致索引失效而进行全表扫描，因此我们可以改成: 
 select * from users where adddate<‘2007-01-01';
尽量的扩展索引，不要新建索引。
比如表中已经有a的索引，现在要加(a,b)的索引，那么只需要修改原来的索引即可
不使用NOT IN和<>操作
like语句操作
一般情况下不鼓励使用like操作，如果非使用不可，如何使用也是一个问题。like “%aaa%” 不会使用索引而like “aaa%”可以使用索引。
索引列排序
MySQL查询只使用一个索引，因此如果where子句中已经使用了索引的话，那么order by中的列是不会使用索引的。因此数据库默认排序可以符合要求的情况下不要使用排序操作；尽量不要包含多个列的排序，如果需要最好给这些列创建复合索引。
索引不会包含有NULL值的列
只要列中包含有NULL值都将不会被包含在索引中，复合索引中只要有一列含有NULL值，那么这一列对于此复合索引就是无效的。所以我们在数据库设计时不要让字段的默认值为NULL。
注意：选择索引的最终目的是为了使查询的速度变快。上面给出的原则是最基本的准则，但不能拘泥于上面的准则。读者要在以后的学习和工作中进行不断的实践。根据应用的实际情况进行分析和判断，选择最合适的索引方式。

52. 查看SQL执行计划
索引类似大学图书馆建书目索引，可以提高数据检索的效率，降低数据库的IO成本。MySQL在300万条记录左右性能开始逐渐下降，虽然官方文档说500~800w记录，所以大数据量建立索引是非常有必要的。MySQL提供了Explain，用于显示SQL执行的详细信息，可以进行索引的优化。
一、导致SQL执行慢的原因：
      1.硬件问题。如网络速度慢，内存不足，I/O吞吐量小，磁盘空间满了等。
      2.没有索引或者索引失效。（一般在互联网公司，DBA会在半夜把表锁了，重新建立一遍索引，因为当你删除某个数据的时候，索引的树结构就不完整了。所以互联网公司的数据做的是假删除.一是为了做数据分析,二是为了不破坏索引 ）
      3.数据过多（分库分表）
      4.服务器调优及各个参数设置（调整my.cnf）
二、分析原因时，一定要找切入点：
      1.先观察，开启慢查询日志，设置相应的阈值（比如超过3秒就是慢SQL），在生产环境跑上个一天过后，看看哪些SQL比较慢。
      2.Explain和慢SQL分析。比如SQL语句写的烂，索引没有或失效，关联查询太多（有时候是设计缺陷或者不得以的需求）等等。
      3.Show Profile是比Explain更近一步的执行细节，可以查询到执行每一个SQL都干了什么事，这些事分别花了多少秒。
      4.找DBA或者运维对MySQL进行服务器的参数调优。
三、什么是索引？
      MySQL官方对索引的定义为：索引(Index)是帮助MySQL高效获取数据的数据结构。我们可以简单理解为：快速查找排好序的一种数据结构。Mysql索引主要有两种结构：B+Tree索引和Hash索引。我们平常所说的索引，如果没有特别指明，一般都是指B树结构组织的索引(B+Tree索引)。索引如图所示：
             
      最外层浅蓝色磁盘块1里有数据17、35（深蓝色）和指针P1、P2、P3（黄色）。P1指针表示小于17的磁盘块，P2是在17-35之间，P3指向大于35的磁盘块。真实数据存在于子叶节点也就是最底下的一层3、5、9、10、13......非叶子节点不存储真实的数据，只存储指引搜索方向的数据项，如17、35。
      查找过程：例如搜索28数据项，首先加载磁盘块1到内存中，发生一次I/O，用二分查找确定在P2指针。接着发现28在26和30之间，通过P2指针的地址加载磁盘块3到内存，发生第二次I/O。用同样的方式找到磁盘块8，发生第三次I/O。
      真实的情况是，上面3层的B+Tree可以表示上百万的数据，上百万的数据只发生了三次I/O而不是上百万次I/O，时间提升是巨大的。
四、Explain分析
      前文铺垫完成，进入实操部分，先来插入测试需要的数据：
初体验，执行Explain的效果：

索引使用情况在possible_keys、key和key_len三列，接下来我们先从左到右依次讲解。
1.id
--id相同,执行顺序由上而下explain select u.*,o.* from user_info u,order_info o where u.id=o.user_id;

--id不同,值越大越先被执行explain select * from  user_info  where id=(select user_id from order_info where  product_name ='p8');

 
2.select_type
可以看id的执行实例，总共有以下几种类型：

 SIMPLE： 表示此查询不包含 UNION 查询或子查询
 
 PRIMARY： 表示此查询是最外层的查询
 
 SUBQUERY： 子查询中的第一个 SELECT
 
 UNION： 表示此查询是 UNION 的第二或随后的查询
 
 DEPENDENT UNION： UNION 中的第二个或后面的查询语句, 取决于外面的查询
 
 UNION RESULT, UNION 的结果
 
 DEPENDENT SUBQUERY: 子查询中的第一个 SELECT, 取决于外面的查询. 即子查询依赖于外层查询的结果.
 
 DERIVED：衍生，表示导出表的SELECT（FROM子句的子查询）
 

3.table
table表示查询涉及的表或衍生的表：
explain select tt.* from (select u.* from user_info u,order_info o where u.id=o.user_id and u.id=1) tt

id为1的的表示id为2的u和o表衍生出来的。
4.type
type 字段比较重要，它提供了判断查询是否高效的重要依据依据。 通过 type 字段，我们判断此次查询是 全表扫描 还是 索引扫描等。

 type 常用的取值有:

 system: 表中只有一条数据， 这个类型是特殊的 const 类型。
 
 const: 针对主键或唯一索引的等值查询扫描，最多只返回一行数据。 const 查询速度非常快， 因为它仅仅读取一次即可。例如下面的这个查询，它使用了主键索引，因此 type 就是 const 类型的：explain select * from user_info where id = 2；
 
 eq_ref: 此类型通常出现在多表的 join 查询，表示对于前表的每一个结果，都只能匹配到后表的一行结果。并且查询的比较操作通常是 =，查询效率较高。例如：explain select * from user_info, order_info where user_info.id = order_info.user_id;
 
 ref: 此类型通常出现在多表的 join 查询，针对于非唯一或非主键索引，或者是使用了 最左前缀 规则索引的查询。例如下面这个例子中， 就使用到了 ref 类型的查询：explain select * from user_info, order_info where user_info.id = order_info.user_id AND order_info.user_id = 5
 
 range: 表示使用索引范围查询，通过索引字段范围获取表中部分数据记录。这个类型通常出现在 =, <>, >, >=, <, <=, IS NULL, <=>, BETWEEN, IN() 操作中。例如下面的例子就是一个范围查询：explain select * from user_info  where id between 2 and 8；
 
 index: 表示全索引扫描(full index scan)，和 ALL 类型类似，只不过 ALL 类型是全表扫描，而 index 类型则仅仅扫描所有的索引， 而不扫描数据。index 类型通常出现在：所要查询的数据直接在索引树中就可以获取到, 而不需要扫描数据。当是这种情况时，Extra 字段 会显示 Using index。
 
 ALL: 表示全表扫描，这个类型的查询是性能最差的查询之一。通常来说， 我们的查询不应该出现 ALL 类型的查询，因为这样的查询在数据量大的情况下，对数据库的性能是巨大的灾难。 如一个查询是 ALL 类型查询， 那么一般来说可以对相应的字段添加索引来避免。
 

      通常来说, 不同的 type 类型的性能关系如下:
       ALL < index < range ~ index_merge < ref < eq_ref < const < system
       ALL 类型因为是全表扫描， 因此在相同的查询条件下，它是速度最慢的。而 index 类型的查询虽然不是全表扫描，但是它扫描了所有的索引，因此比 ALL 类型的稍快.后面的几种类型都是利用了索引来查询数据，因此可以过滤部分或大部分数据，因此查询效率就比较高了。
5.possible_keys
      它表示 mysql 在查询时，可能使用到的索引。 注意，即使有些索引在 possible_keys 中出现，但是并不表示此索引会真正地被 mysql 使用到。 mysql 在查询时具体使用了哪些索引，由 key 字段决定。
6.key
      此字段是 mysql 在当前查询时所真正使用到的索引。比如请客吃饭,possible_keys是应到多少人，key是实到多少人。当我们没有建立索引时：
explain select o.* from order_info o where  o.product_name= 'p1' and  o.productor='whh';create index idx_name_productor on order_info(productor);drop index idx_name_productor on order_info;

建立复合索引后再查询：

 
7.key_len
      表示查询优化器使用了索引的字节数，这个字段可以评估组合索引是否完全被使用。
8.ref
      这个表示显示索引的哪一列被使用了，如果可能的话,是一个常量。前文的type属性里也有ref，注意区别。

 
9.rows
      rows 也是一个重要的字段，mysql 查询优化器根据统计信息，估算 sql 要查找到结果集需要扫描读取的数据行数，这个值非常直观的显示 sql 效率好坏， 原则上 rows 越少越好。可以对比key中的例子，一个没建立索引钱，rows是9，建立索引后，rows是4。
10.extra

explain 中的很多额外的信息会在 extra 字段显示, 常见的有以下几种内容:

 using filesort ：表示 mysql 需额外的排序操作，不能通过索引顺序达到排序效果。一般有 using filesort都建议优化去掉，因为这样的查询 cpu 资源消耗大。
 
 using index：覆盖索引扫描，表示查询在索引树中就可查找所需数据，不用扫描表数据文件，往往说明性能不错。
 
 using temporary：查询有使用临时表, 一般出现于排序， 分组和多表 join 的情况， 查询效率不高，建议优化。
 
 using where ：表名使用了where过滤。
 

五、优化案例
explain select u.*,o.* from user_info u LEFT JOIN  order_info o on u.id=o.user_id;
执行结果，type有ALL，并且没有索引：

开始优化，在关联列上创建索引，明显看到type列的ALL变成ref，并且用到了索引，rows也从扫描9行变成了1行：

这里面一般有个规律是：左链接索引加在右表上面，右链接索引加在左表上面。
六、是否需要创建索引？   
      索引虽然能非常高效的提高查询速度，同时却会降低更新表的速度。实际上索引也是一张表，该表保存了主键与索引字段，并指向实体表的记录，所以索引列也是要占用空间的。
              

53. 有十万条数据, 写SQL语句查询其中某字段较大值的几条数据
select * from 表 order by 要最大值的字段 desc limit 0,10

54. 子查询与关联查询的区别
SELECT DISTINCT 
FROM 
 JOIN 
ON 
WHERE 
GROUP BY 
HAVING 
ORDER BY 
LIMIT 
如果你知道每个关键字的意思，作用，如果你还用过的话，那再好不过了。但是，你知道这些语句，它们的执行顺序你清楚么？如果你非常清楚，你就没有必要再浪费时间继续阅读了；如果你不清楚，非常好，你应该庆幸你阅读到了这么好的一篇文章。
SQL逻辑查询语句执行顺序
还记得上面给出的那一长串的SQL逻辑查询规则么？那么，到底哪个先执行，哪个后执行呢？现在，我先给出一个查询语句的执行顺序：
(7) SELECT

(8) DISTINCT 

(1) FROM 

(3)  JOIN 

(2) ON 

(4) WHERE 

(5) GROUP BY 

(6) HAVING 

(9) ORDER BY 

(10) LIMIT 
上面在每条语句的前面都标明了执行顺序号，不要问我怎么知道这个顺序的。我也是读各种“武林秘籍”才得知的，如果你有功夫，去阅读一下MySQL的源码，也会得出这个结果的。
好了，上面我标出了各条查询规则的执行先后顺序，那么各条查询语句是如何执行的呢？这就是我今天这篇博文的重点内容。Go on…
执行FROM语句
在这些SQL语句的执行过程中，都会产生一个虚拟表，用来保存SQL语句的执行结果（这是重点），我现在就来跟踪这个虚拟表的变化，得到最终的查询结果的过程，来分析整个SQL逻辑查询的执行顺序和过程。
第一步，执行FROM语句。我们首先需要知道最开始从哪个表开始的，这就是FROM告诉我们的。现在有了和两个表，我们到底从哪个表开始，还是从两个表进行某种联系以后再开始呢？它们之间如何产生联系呢？——笛卡尔积
总共有28（table1的记录条数 * table2的记录条数）条记录。这就是VT1的结果，接下来的操作就在VT1的基础上进行。
执行ON过滤
执行完笛卡尔积以后，接着就进行ON a.customer_id = b.customer_id条件过滤，根据ON中指定的条件，去掉那些不符合条件的数据，得到VT2表，内容如下：
VT2就是经过ON条件筛选以后得到的有用数据，而接下来的操作将在VT2的基础上继续进行。
添加外部行
这一步只有在连接类型为OUTER JOIN时才发生，如LEFT OUTER JOIN、RIGHT OUTER JOIN和FULL OUTER JOIN。在大多数的时候，我们都是会省略掉OUTER关键字的，但OUTER表示的就是外部行的概念。
LEFT OUTER JOIN把左表记为保留表，得到的结果为：
+-------------+----------+----------+-------------+

| customer_id | city | order_id | customer_id |

+-------------+----------+----------+-------------+

| 163 | hangzhou | 1 | 163 |

| 163 | hangzhou | 2 | 163 |

| 9you | shanghai | 3 | 9you |

| 9you | shanghai | 4 | 9you |

| 9you | shanghai | 5 | 9you |

| tx | hangzhou | 6 | tx |

| baidu | hangzhou | NULL | NULL |

+-------------+----------+----------+-------------+
RIGHT OUTER JOIN把右表记为保留表，得到的结果为：
+-------------+----------+----------+-------------+

| customer_id | city | order_id | customer_id |

+-------------+----------+----------+-------------+

| 163 | hangzhou | 1 | 163 |

| 163 | hangzhou | 2 | 163 |

| 9you | shanghai | 3 | 9you |

| 9you | shanghai | 4 | 9you |

| 9you | shanghai | 5 | 9you |

| tx | hangzhou | 6 | tx |

| NULL | NULL | 7 | NULL |

+-------------+----------+----------+-------------+
FULL OUTER JOIN把左右表都作为保留表，得到的结果为：
+-------------+----------+----------+-------------+

| customer_id | city | order_id | customer_id |

+-------------+----------+----------+-------------+

| 163 | hangzhou | 1 | 163 |

| 163 | hangzhou | 2 | 163 |

| 9you | shanghai | 3 | 9you |

| 9you | shanghai | 4 | 9you |

| 9you | shanghai | 5 | 9you |

| tx | hangzhou | 6 | tx |

| baidu | hangzhou | NULL | NULL |

| NULL | NULL | 7 | NULL |

+-------------+----------+----------+-------------+
添加外部行的工作就是在VT2表的基础上添加保留表中被过滤条件过滤掉的数据，非保留表中的数据被赋予NULL值，最后生成虚拟表VT3。
由于我在准备的测试SQL查询逻辑语句中使用的是LEFT JOIN，过滤掉了以下这条数据：
| baidu | hangzhou | NULL | NULL |
现在就把这条数据添加到VT2表中，得到的VT3表如下：
+-------------+----------+----------+-------------+

| customer_id | city | order_id | customer_id |

+-------------+----------+----------+-------------+

| 163 | hangzhou | 1 | 163 |

| 163 | hangzhou | 2 | 163 |

| 9you | shanghai | 3 | 9you |

| 9you | shanghai | 4 | 9you |

| 9you | shanghai | 5 | 9you |

| tx | hangzhou | 6 | tx |

| baidu | hangzhou | NULL | NULL |

+-------------+----------+----------+-------------+
接下来的操作都会在该VT3表上进行。
执行WHERE过滤
对添加外部行得到的VT3进行WHERE过滤，只有符合的记录才会输出到虚拟表VT4中。当我们执行WHERE a.city = 'hangzhou'的时候，就会得到以下内容，并存在虚拟表VT4中：
+-------------+----------+----------+-------------+

| customer_id | city | order_id | customer_id |

+-------------+----------+----------+-------------+

| 163 | hangzhou | 1 | 163 |

| 163 | hangzhou | 2 | 163 |

| tx | hangzhou | 6 | tx |

| baidu | hangzhou | NULL | NULL |

+-------------+----------+----------+-------------+
但是在使用WHERE子句时，需要注意以下两点：

由于数据还没有分组，因此现在还不能在WHERE过滤器中使用where_condition=MIN(col)这类对分组统计的过滤；
由于还没有进行列的选取操作，因此在SELECT中使用列的别名也是不被允许的，如：SELECT city as c FROM t WHERE c='shanghai';是不允许出现的。

执行GROUP BY分组
GROU BY子句主要是对使用WHERE子句得到的虚拟表进行分组操作。我们执行测试语句中的GROUP BY a.customer_id，就会得到以下内容：
+-------------+----------+----------+-------------+
| customer_id | city | order_id | customer_id |
+-------------+----------+----------+-------------+
| 163 | hangzhou | 1 | 163 |
| baidu | hangzhou | NULL | NULL |
| tx | hangzhou | 6 | tx |
+-------------+----------+----------+-------------+
得到的内容会存入虚拟表VT5中，此时，我们就得到了一个VT5虚拟表，接下来的操作都会在该表上完成。
执行HAVING过滤
HAVING子句主要和GROUP BY子句配合使用，对分组得到的VT5虚拟表进行条件过滤。当我执行测试语句中的HAVING count(b.order_id) < 2时，将得到以下内容：

+-------------+----------+----------+-------------+
| customer_id | city | order_id | customer_id |
+-------------+----------+----------+-------------+
| baidu | hangzhou | NULL | NULL |
| tx | hangzhou | 6 | tx |
+-------------+----------+----------+-------------+
这就是虚拟表VT6。
SELECT列表
现在才会执行到SELECT子句，不要以为SELECT子句被写在第一行，就是第一个被执行的。
我们执行测试语句中的SELECT a.customer_id, COUNT(b.order_id) as total_orders，从虚拟表VT6中选择出我们需要的内容。我们将得到以下内容：

+-------------+--------------+
| customer_id | total_orders |
+-------------+--------------+
| baidu | 0 |
| tx | 1 |
+-------------+--------------+
不，还没有完，这只是虚拟表VT7。
执行DISTINCT子句
如果在查询中指定了DISTINCT子句，则会创建一张内存临时表（如果内存放不下，就需要存放在硬盘了）。这张临时表的表结构和上一步产生的虚拟表VT7是一样的，不同的是对进行DISTINCT操作的列增加了一个唯一索引，以此来除重复数据。
由于我的测试SQL语句中并没有使用DISTINCT，所以，在该查询中，这一步不会生成一个虚拟表。
执行ORDER BY子句
对虚拟表中的内容按照指定的列进行排序，然后返回一个新的虚拟表，我们执行测试SQL语句中的ORDER BY total_orders DESC，就会得到以下内容：

+-------------+--------------+
| customer_id | total_orders |
+-------------+--------------+
| tx | 1 |
| baidu | 0 |
+-------------+--------------+
可以看到这是对total_orders列进行降序排列的。上述结果会存储在VT8中。
执行LIMIT子句
LIMIT子句从上一步得到的VT8虚拟表中选出从指定位置开始的指定行数据。对于没有应用ORDER BY的LIMIT子句，得到的结果同样是无序的，所以，很多时候，我们都会看到LIMIT子句会和ORDER BY子句一起使用。
MySQL数据库的LIMIT支持如下形式的选择：
LIMIT n, m
表示从第n条记录开始选择m条记录。而很多开发人员喜欢使用该语句来解决分页问题。对于小数据，使用LIMIT子句没有任何问题，当数据量非常大的时候，使用LIMIT n, m是非常低效的。因为LIMIT的机制是每次都是从头开始扫描，如果需要从第60万行开始，读取3条数据，就需要先扫描定位到60万行，然后再进行读取，而扫描的过程是一个非常低效的过程。所以，对于大数据处理时，是非常有必要在应用层建立一定的缓存机制。

55. 为什么要使用索引？索引这么多优点，为什么不对表中的每一个列创建一个索引呢？索引是如何提高查询速度的？说一下使用索引的注意事项？Mysql索引主要使用的两种数据结构？什么是覆盖索引?
为什么要使用索引？

通过创建唯一性索引，可以保证数据库表中每一行数据的唯一性。
可以大大加快 数据的检索速度（大大减少的检索的数据量）, 这也是创建索引的最主要的原因。
帮助服务器避免排序和临时表
将随机IO变为顺序IO
可以加速表和表之间的连接，特别是在实现数据的参考完整性方面特别有意义。

索引这么多优点，为什么不对表中的每一个列创建一个索引呢？

当对表中的数据进行增加、删除和修改的时候，索引也要动态的维护，这样就降低了数据的维护速度。
索引需要占物理空间，除了数据表占数据空间之外，每一个索引还要占一定的物理空间，如果要建立聚簇索引，那么需要的空间就会更大。
创建索引和维护索引要耗费时间，这种时间随着数据量的增加而增加。

索引是如何提高查询速度的？
将无序的数据变成相对有序的数据（就像查目录一样）
说一下使用索引的注意事项

避免 where 子句中对宇段施加函数，这会造成无法命中索引。
在使用InnoDB时使用与业务无关的自增主键作为主键，即使用逻辑主键，而不要使用业务主键。
将打算加索引的列设置为 NOT NULL ，否则将导致引擎放弃使用索引而进行全表扫描
删除长期未使用的索引，不用的索引的存在会造成不必要的性能损耗 MySQL 5.7 可以通过查询 sys 库的 chema_unused_indexes 视图来查询哪些索引从未被使用
在使用 limit offset 查询缓慢时，可以借助索引来提高性能

Mysql索引主要使用的哪两种数据结构？

哈希索引：对于哈希索引来说，底层的数据结构就是哈希表，因此在绝大多数需求为单条记录查询的时候，可以选择哈希索引，查询性能最快；其余大部分场景，建议选择BTree索引。
BTree索引：Mysql的BTree索引使用的是B树中的B+Tree。但对于主要的两种存储引擎（MyISAM和InnoDB）的实现方式是不同的。

什么是覆盖索引?
如果一个索引包含（或者说覆盖）所有需要查询的字段的值，我们就称
之为“覆盖索引”。我们知道在InnoDB存储引擎中，如果不是主键索引，叶子节点存储的是主键+列值。最终还是要“回表”，也就是要通过主键再查找一次,这样就会比较慢。覆盖索引就是把要查询出的列和索引是对应的，不做回表操作！

11.数据库技术

1.一条SQL语句执行得很慢的原因有哪些？

2.数据库隔离级别有哪些,各自的含义是什么, MYSQL默认的隔离级别是是什么.

3.什么是幻读。

4. MYSQL有哪些存储引擎,各自优缺点。

5.高并发下,如何做到安全的修改同一行数据。

6. SQL优化的一般步骤是什么,怎么看执行计划,如何理解其中各个字段的含义。

7.数据库会死锁吗,举一个死锁的例子, mysql怎么解决死锁。

8. Mysql的索引原理,索引的类型有哪些,如何创建合理的索引,索引如何优化。9,聚集索引和非聚集索引的区别,

9.select for update是什么含义,会锁表还是锁行或是其他。

10.为什么要用Btree实现,它是怎么分裂的,什么时候分裂,为什么是平衡的。

11.数据库的ACID是什么。

12.某个表有近千万数据, CRUD比较慢,如何优化。

13.Mysql怎么优化table scan的。

14.如何写sql能够有效的使用到复合素引.

15.mysgl中in和exists区别

16.数据库自增主键可能的问题.

17. MVCC的含义,如何实现的

18.你做过的项目里遇到份库分表了吗,怎么做的,有用到中间件么,比如sharding jdbc等他

们的原理知道么.

19 .MYSQL的主从延迟怎么解决。

20.数据库的三范式是什么？

21.一张自增表里面总共有 7 条数据，删除了最后 2 条数据，重启 mysql 数据库，又插入了一条数据，此时 id 是几？

22.如何获取当前数据库版本？

23.char 和 varchar 的区别是什么？

24.float 和 double 的区别是什么？

25.mysql 的内连接、左连接、右连接有什么区别？

26.怎么验证 mysql 的索引是否满足需求？

27.说一下 mysql 常用的引擎？

28.说一下 mysql 的行锁和表锁？

29.说一下乐观锁和悲观锁？

30.mysql 问题排查都有哪些手段？

31.count(*)，count(1)和count(字段) 的区别

32.平常用到了什么索引优化，如何优化limit，如何优化

35.哪些情况会引起索引的失效

36.多表查询怎么优化

37.聚集索引和非聚集索引知道吗？什么情况用聚集索引什么情况用非聚集索引

39.如何定位一个慢查询，一个服务有多条SQL你怎么快速定位

40.在 oracle 数据库中需要查询出前 8 条记录的 sql 语句怎么写？

41.如果有很多数据插入MYSQL 你会选择什么方式?

42.如果查询很慢，你会想到的第一个方式是什么？索引是干嘛的?

43.怎么看是否用到了了某个索引？

44.like %aaa%会使用索引吗? like aaa%呢?

45.drop、truncate、delete的区别？

46.你们数据库是否支持emoji表情，如果不支持，如何操作?

47.你们的数据库单表数据量是多少？一般多大的时候开始出现查询性能急剧下降？

48.查询死掉了，想要找出执行的查询进程用什么命令？找出来之后一般你会干嘛？

49.读写分离是怎么做的？你认为中间件会怎么来操作？这样操作跟事务有什么关系？

50.分库分表有没有做过？线上的迁移过程是怎么样的？如何确定数据是正确的？

51. 你建过索引吗? 建索引的原则

52. 查看SQL执行计划

1.id

2.select_type

3.table

4.type

5.possible_keys

6.key

7.key_len

8.ref

9.rows

10.extra

53. 有十万条数据, 写SQL语句查询其中某字段较大值的几条数据

54. 子查询与关联查询的区别

55. 为什么要使用索引？索引这么多优点，为什么不对表中的每一个列创建一个索引呢？索引是如何提高查询速度的？说一下使用索引的注意事项？Mysql索引主要使用的两种数据结构？什么是覆盖索引?

你可能感兴趣的:(11.数据库技术)