explain select * from film order by name;

7.mysql事务的隔离级别,会有哪些问题?通常如何解决?项目中是否有修改过隔离级别，还有对MVCC的使用?

SET TRANSACTION ISOLATION LEVEL <隔离级别>;//设置隔离级别

mysql隔离级别分别是读取未提交,读取已提交,可重复读取,序列化（串行化）四个级别,相对的会产生的问题是脏读,不可重复读,幻读。对于脏读问题,通常出现在读取未提交隔离级别下,在事务2中会查询到事务1还未提交的数据,可以通过提高隔离级别的方式解决该问题,也可以给相应数据加锁解决，以下是加锁演示:

mysql> begin;
Query OK, 0 rows affected (0.00 sec)mysql> select * from products where id = 1 for update;
+----+------------+---------+-------+
| id | name       | price   | stock |
+----+------------+---------+-------+
|  1 | HUAWEI P40 | 3299.00 |   100 |
+----+------------+---------+-------+
1 row in set (0.00 sec)mysql> update products set stock = stock - 1 where id = 1;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0mysql> commit;
Query OK, 0 rows affected (0.01 sec)

mysql> begin;
Query OK, 0 rows affected (0.00 sec)mysql> select * from products where id = 1 for update;
+----+------------+---------+-------+
| id | name       | price   | stock |
+----+------------+---------+-------+
|  1 | HUAWEI P40 | 3299.00 |    99 |
+----+------------+---------+-------+
1 row in set (12.87 sec)mysql> commit;
Query OK, 0 rows affected (0.00 sec)

可以看到的是事务依然是查询到了修改的数据,但是这并不属于脏读,而是mysql事务中查询语句加锁之后的当前磁盘数据读取,如果是未加锁的可能会是快照读取,读取的是事务开启前的数据。

不可重复读取:

对于不可重读读取,是在读取已提交的情况下,事务1修改了数据,并已经提交数据,此时按照事务的一致性特点,事务2是不能读取事务开启前不一样的数据的即,此时事务2只能读取到事务开启前的数据.要保证事务的一致性,我们需要提高事务的隔离级别到可重复读

幻读:

对于幻读问题,主要是在新增的数据情况下,事务1查询数据是否存在,不存在则新增数据,事务2一样查询数据是否存在,不存在则一样新增数据,因为mysql对于新增,修改,删除语句是默认加锁的,事务2必然会进入锁等待,等到事务1提交后会发现数据已存在导致数据新增失败,但是查询明明是不存在的,这就是幻读.这个问题我们可以通过将隔离级别提升到串行化解决，也可以给查询的数据加个间隙锁,即锁住一块区域的数据,使查询阶段就进入到锁等待,锁的查询会是磁盘此时实际的数据读取,事务1提交后是能够查询到数据的,这样就能够不去新增数据了。

下面是演示:

事务1:

mysql> begin;
Query OK, 0 rows affected (0.00 sec)mysql> select * from products where id > 1 and id < 10 for update;
+----+------------+----------+-------+
| id | name       | price    | stock |
+----+------------+----------+-------+
|  2 | HUAWEI P50 |  4999.00 |   100 |
|  3 | HUAWEI P60 | 10000.00 |   100 |
|  5 | HUAWEI P60 | 10000.00 |   100 |
+----+------------+----------+-------+
3 rows in set (0.00 sec)mysql> rollback;
Query OK, 0 rows affected (0.00 sec)

事务2:

mysql> begin;
Query OK, 0 rows affected (0.00 sec)mysql> select * from products where id > 1 and id < 10 for update;
+----+------------+----------+-------+
| id | name       | price    | stock |
+----+------------+----------+-------+
|  2 | HUAWEI P50 |  4999.00 |   100 |
|  3 | HUAWEI P60 | 10000.00 |   100 |
|  5 | HUAWEI P60 | 10000.00 |   100 |
+----+------------+----------+-------+
3 rows in set (48.11 sec)mysql> rollback;
Query OK, 0 rows affected (0.00 sec)

乐观锁的一种运用情况：MVCC

8.mysql都有什么锁，死锁判定原理和具体场景，死锁怎么解决?

MySQL有三种锁的级别：页级、表级、行级。

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

死锁: 是指两个或两个以上的进程在执行过程中。因争夺资源而造成的一种互相等待的现象,若无外力作用,它们都将无法推进下去。此时称系统处于死锁状态或系统产生了死锁,这些永远在互相等竺的进程称为死锁进程。

表级锁不会产生死锁.所以解决死锁主要还是针对于最常用的InnoDB。

死锁的关键在于：两个(或以上)的Session加锁的顺序不一致。

那么对应的解决死锁问题的关键就是：让不同的session加锁有次序。

死锁的解决办法?

1.查出的线程杀死 kill SELECT trx_MySQL_thread_id FROM information_schema.INNODB_TRX;

2.设置锁的超时时间 Innodb 行锁的等待时间，单位秒。可在会话级别设置，RDS 实例该参数的默认值为 50（秒）。

生产环境不推荐使用过大的 innodb_lock_wait_timeout参数值 该参数支持在会话级别修改，方便应用在会话级别单独设置某些特殊操作的行锁等待超时时间，如下：

set innodb_lock_wait_timeout=1000; —设置当前会话 Innodb 行锁等待超时时间，单位秒。

9.水平分表与垂直分表

1.垂直切分

垂直切分常见有垂直分库和垂直分表两种。

垂直分库就是根据业务耦合性，将关联度低的不同表存储在不同的数据库。做法与大系统拆分为多个小系统类似，按业务分类进行独立划分。与"微服务治理"的做法相似，每个微服务使用单独的一个数据库。如图：

垂直分表是基于数据库中的"列"进行，某个表字段较多，可以新建一张扩展表，将不经常用或字段长度较大的字段拆分出去到扩展表中。在字段很多的情况下（例如一个大表有100多个字段），通过"大表拆小表"，更便于开发与维护，也能避免跨页问题，MySQL底层是通过数据页存储的，一条记录占用空间过大会导致跨页，造成额外的性能开销。另外数据库以行为单位将数据加载到内存中，这样表中字段长度较短且访问频率较高，内存能加载更多的数据，命中率更高，减少了磁盘IO，从而提升了数据库性能。

垂直切分的优点：

• 解决业务系统层面的耦合，业务清晰

• 与微服务的治理类似，也能对不同业务的数据进行分级管理、维护、监控、扩展等

• 高并发场景下，垂直切分一定程度的提升IO、数据库连接数、单机硬件资源的瓶颈

缺点：

• 部分表无法join，只能通过接口聚合方式解决，提升了开发的复杂度

• 分布式事务处理复杂

• 依然存在单表数据量过大的问题（需要水平切分）

2.水平切分

当一个应用难以再细粒度的垂直切分，或切分后数据量行数巨大，存在单库读写、存储性能瓶颈，这时候就需要进行水平切分了。

水平切分分为库内分表和分库分表，是根据表内数据内在的逻辑关系，将同一个表按不同的条件分散到多个数据库或多个表中，每个表中只包含一部分数据，从而使得单个表的数据量变小，达到分布式的效果。如图所示：

库内分表只解决了单一表数据量过大的问题，但没有将表分布到不同机器的库上，因此对于减轻MySQL数据库的压力来说，帮助不是很大，大家还是竞争同一个物理机的CPU、内存、网络IO，最好通过分库分表来解决。

水平切分的优点：

• 不存在单库数据量过大、高并发的性能瓶颈，提升系统稳定性和负载能力

• 应用端改造较小，不需要拆分业务模块

缺点：

• 跨分片的事务一致性难以保证

• 跨库的join关联查询性能较差

• 数据多次扩展难度和维护量极大

10.你们那个xxxx项目的分库分表是根据什么规则做的呢？分完之后的处理做了哪些？

  我们的项目是根据业务做了垂直的分库，将整个系统的分为了用户，商品，订单        ，其中我主要负责的是订单模块，在这里我对订单表根据hash取模处理去进行分表，具体是使用雪花算法去生成一个唯一的值之后进行hash的处理，随后在对分片数进行取模，当时我们是分了64张表，这里是对64取模。

在分表完成之后，我遇到了如下困难：

1. 分表之后新库和老库的数据迁移问题

2. 订单表数据的查询问题

3. 日后业务增长之后，扩容的问题

对此我做了如下处理：

• 数据迁移问题

  1. 导出老库中的数据，同时在业务中新库与老库同时写入新的订单数据

  2. 配置mycat的分库分表规则

  3. 通过mycat在系统的低峰期将数据导入到新库中，当时我们是千万的数据，时间大概在10-15分钟就完成了

  4. 做数据验证，这里我们是通过在用户平时的查询中来做的，在用户查询的同时，会查询两个库的数据，去做对比，如果老库中的数据比新库多，会通过老库去补全新库的数据

• 查询问题

  对于分库之后的连表查询问题，我们是采用了mycat去配置一个全局表，做数据的冗余，同时有创建一张异构索引表，记录用户的id以及用户的订单id，按照用户的id去进行hash取模分表，然后在用户查询数据的时候，先根据用户id查询出这个用户的订单id，然后在根据订单id去订单库查询数据

• 扩容问题

  与前面的数据迁移一致，分库分表本质就是在做扩容，从一到多，从多到更多

11.主从原理

使用主从的原因:

1. 实现服务器负载均衡

       即可以通过在主服务器和从服务器之间切分处理客户查询的负荷，从而得到更好的客户相应时间。通常情况下，数据库管理员会有两种思路。

          一是在主服务器上只实现数据的更新操作。包括数据记录的更新、删除、新建等等作业。而不关心数据的查询作业。数据库管理员将数据的查询请求全部 转发到从服务器中。这在某些应用中会比较有用。如某些应用，像基金净值预测的网站。其数据的更新都是有管理员更新的，即更新的用户比较少。而查询的用户数 量会非常的多。此时就可以设置一台主服务器，专门用来数据的更新。同时设置多台从服务器，用来负责用户信息的查询

          二是在主服务器上与从服务器切分查询的作业。在这种思路下，主服务器不单单要完成数据的更新、删除、插入等作业，同时也需要负担一部分查询作业。而从服务器的话，只负责数据的查询。当主服务器比较忙时，部分查询请求会自动发送到从服务器重，以降低主服务器的工作负荷。

2. 通过复制实现数据的异地备份

       可以定期的将数据从主服务器上复制到从服务器上，这无疑是先了数据的异地备份。在传统的备份体制下，是将数据备份在本地。此时备份 作业与数据库服务器运行在同一台设备上，当备份作业运行时就会影响到服务器的正常运行。有时候会明显的降低服务器的性能。同时，将备份数据存放在本地，也 不是很安全。如硬盘因为电压等原因被损坏或者服务器被失窃，此时由于备份文件仍然存放在硬盘上，数据库管理员无法使用备份文件来恢复数据。这显然会给企业 带来比较大的损失。

3. 提高数据库系统的可用性

       数据库复制功能实现了主服务器与从服务器之间数据的同步，增加了数据库系统的可用性。当主服务器出现问题时，数据库管理员可以马上让从服务器作为主服务器，用来数据的更新与查询服务。然后回过头来再仔细的检查主服务器的问题。此时一般数据库管理员也会采用两种手段。

          一是主服务器故障之后，虽然从服务器取代了主服务器的位置，但是对于主服务器可以采取的操作仍然做了一些限制。如仍然只能够进行数据的查询，而 不能够进行数据的更新、删除等操作。这主要是从数据的安全性考虑。如现在一些银行系统的升级，在升级的过程中，只能够查询余额而不能够取钱。这是同样的道 理。

          二是从服务器真正变成了主服务器。当从服务器切换为主服务器之后，其地位完全与原先的主服务器相同。此时可以实现对数据的查询、更新、删除等操 作。为此就需要做好数据的安全性工作。即数据的安全策略，要与原先的主服务器完全相同。否则的话，就可能会留下一定的安全隐患

原理：

1. master服务器将数据的改变都记录到二进制binlog日志中，只要master上的数据发生改变，则将其改变写入二进制日志；

2. salve服务器会在一定时间间隔内对master二进制日志进行探测其是否发生改变，如果发生改变，则开始一个I/O Thread请求master二进制日志

3. 同时主节点为每个I/O线程启动一个dump线程，用于向其发送二进制日志，并保存至从节点本地的中继日志中

4. 从节点将启动SQL线程从中继日志中读取二进制日志，在本地重放，使得其数据和主节点的保持一致

5. 最后I/O Thread和SQL Thread将进入睡眠状态，等待下一次被唤醒.

   需要理解：

   1）从库会生成两个线程,一个I/O线程,一个SQL线程;

   2）I/O线程会去请求主库的binlog,并将得到的binlog写到本地的relay-log(中继日志)文件中;*

   3）主库会生成一个log dump线程,用来给从库I/O线程传binlog;

   4）SQL线程,会读取relay log文件中的日志,并解析成sql语句逐一执行;

   复制流程：

   1. master将操作语句记录到binlog日志中

   2. salve服务器会在一定时间间隔内对master二进制日志进行探测其是否发生改变，如果发生改变

   3. salave开启两个线程：IO线程和SQL线程

      1）*IO线程：*负责读取master的binlog内容到中继日志relay log里；

      2）*SQL线程：*负责从relay log日志里读出binlog内容，并更新到slave的数据库里（保证数据一致）

12.主从延迟

2、说说自己对于 MySQL 常见的两种存储引擎：MyISAM与InnoDB的理解？

InnoDB 引擎：InnoDB 引擎提供了对数据库 acid 事务的支持，并且还提供了行级锁和外键的约束，它的设计的目标就是处理大数据容量的数据库系统。MySQL 运行的时候，InnoDB 会在内存中建立缓冲池，用于缓冲数据和索引。但是该引擎是不支持全文搜索，同时启动也比较的慢，它是不会保存表的行数的，所以当进行 select count() from table 指令的时候，需要进行扫描全表。由于锁的粒度小，写操作是不会锁定全表的,所以在并发度较高的场景下使用会提升效率的。

MyIASM 引擎：MySQL 的默认引擎，但不提供事务的支持，也不支持行级锁和外键。因此当执行插入和更新语句时，即执行写操作的时候需要锁定这个表，所以会导致效率会降低。不过和 InnoDB 不同的是，MyIASM 引擎是保存了表的行数，于是当进行 select count() from table 语句时，可以直接的读取已经保存的值而不需要进行扫描全表。所以，如果表的读操作远远多于写操作时，并且不需要事务的支持的，可以将 MyIASM 作为数据库引擎的首选。