MySQL（2）-CSDN博客

本文链接：https://blog.csdn.net/ripchen/article/details/129317439

索引的类型？

从数据结构角度
- 1.树索引
- 2.Hash索引
从物理存储角度
- 1.聚集索引
- 2.非聚集索引
从逻辑角度
- 1.普通索引
- 2.唯一索引
- 3.主键索引
- 4.联合索引

列值为NULL时，查询是否会用到索引

在MySQL里NULL值的列也是走索引的。尽量避免设置列值为空，不然会使索引、索引统计和值更加复杂。

什么情况索引会失效

索引列参与表达式计算：
SELECT ‘sname’ FROM ‘stu’ WHERE ‘age’ +10 = 30
函数运算：
SELECT ‘sname’ FROM ‘stu’ WHERE LEFT(‘date’,4)<1990;
%词语%-模糊查询
SELECT * FROM ‘manong’ WHERE ‘uname’ LIKE ‘码农%’ --------走索引
SELECT * FROM ‘manong’ WHERE ‘uname’ LIKE ‘%码农%’ ---------不走索引
字符串与数字比较不走索引
CREATE TABLE ‘a’(‘a’ char(10))
EXPLAIN SELECT * FROM ‘a’ WHERE ‘a’==“1” -------------走索引
EXPLAIN SELECT * FROM ‘a’ WHERE ‘a’==1 -------------不走索引，同样也是使用了函数运算
查询条件中有or，即使其中有条件带索引也不会使用。即就是要求使用的所有字段，都必须建立索引
select * from dept where danme = ‘xxx’ or loc= ‘xx’ or deptno = 45;
正则表达式不使用索引
MySQL内部优化器会对SQL语句进行优化，如果优化器估计使用全表扫描要比使用索引快，则不使用索引。

MySQL的行锁和表锁

MyISAM只支持表锁，InnoDB支持表锁和行锁，默认为行锁

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

MySQL 问题排查都有哪些手段？

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

MySQL主从复制流程是怎样的？

http://t.csdn.cn/SLVnt

在实际的生产中，为了解决MySQL的单点故障已经提高MySQL的整体服务性能，一般都会采用主从复制。比如，在复制的业务系统中，有一句sql执行后导致锁表，并且这条sql的执行时间比较长，那么此时sql执行的期间导致服务不可用，这样就会严重影响用户的体验度。
主从复制中分为主服务器和从服务器，主服务器复制写，从服务器负责读。MySQL的主从复制的过程是一个异步的过程。
这样读写分离的过程能使整体的服务性提高，即使写操作时间很长，也不会影响读操作。
具体的实现呢，就是Master上面的binlog dump线程，该线程负责将master的binlog event传到slave。
然后Slave上面的IO线程，该线程负责接收Master传过来的binlog，并写入relay log
然后是Slave上面的SQL线程，该线程负责读取relay log并执行
如果是多线程复制，无论是5.6库级别的假多线程还是MariaDB或者5.7的真正多线程复制，SQL线程只做coordinator，只负责把relay log中的binlog读出来然后交给worker线程，woker线程负责具体binlog event 的执行。

主从同步的延迟原因及解决方法

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

MySQL的redolog、undolog、binlog都是干什么的？

binlog 归档日志（二进制日志）
作用：用于复制，在主从复制中，从库利用主库上的binlog进行重播，实现主从同步。用于数据库的基于时间点的还原。
内容：逻辑格式的日志，可以简单认为就是执行过的事务的sql语句。但又不完全是sql语句这么简单，而是包括了执行的sql语句（增删改）反向的信息，也就意味着delete对应着delete本身和其反向的insert；update对应着update执行前后版本的信息；insert对应着delete和insert本身的信息。
binlog有三种模式：
1.Statement（基于SQL语句的复制）
2.Row（基于行的复制）
3.Mixed（混合模式）
redo log重做日志
作用：确保事务的持久性。防止在发生故障的时间点，还有脏页未写入磁盘，在重启mysql服务的时候，根据redo log进行重做，从而达到事务的持久性这一特性。
内容：物理格式的日志，记录的是物理数据页面的修改的信息，其redo log是顺序写入redo log file 的物理文件中去的。
undo log回滚日志
作用：保存了事务发生之前的数据的一个版本，可以用于回滚，同时可以提供多版本并发控制下的读（MVCC），也即非锁定读
内容：逻辑格式的日志，在执行undo 的时候，仅仅是将数据从逻辑上恢复至事务之前的状态，而不是从物理页面上操作实现的，这一点是不同于redo log的。