本篇内容主要讲解“MySQL的基础问题有哪些”，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让小编来带大家学习“MySQL的基础问题有哪些”吧!
第一范式：字段原子性，第二范式：行唯一，有主键列，第三范式：每列和主键列都相关。
实际应用中会通过冗余少量字段来少关联表，提升查询效率。
MySQL数据库本身被堵住了，比如：系统或网络资源不够
SQL语句被堵住了，比如：表锁，行锁等，导致存储引擎不执行对应的SQL语句
确实是索引使用不当，没有走索引
表中数据的特点导致的，走了索引，但回表次数庞大
对于count(*)、count(常数)、count(主键)形式的count函数来说，优化器可以选择扫描成本最小的索引执行查询，从而提升效率，它们的执行过程是一样的。
而对于count(非索引列)来说，优化器选择全表扫描，说明只能在聚集索引的叶子结点顺序扫描。
count(二级索引列)只能选择包含我们指定的列的索引去执行查询，可能导致优化器选择的索引执行的代价并不是最小。
1）如果数据量比较大,用物理备份xtrabackup。定期对数据库进行全量备份,也可以做增量备份。
2）如果数据量较少,用mysqldump或者mysqldumper，再利用binlog来恢复或者搭建主从的方式来恢复数据，可以从以下几个点来恢复：
DML误操作语句：可以通过flashback，先解析binlog event,然后在进行反转。
DDL语句误操作：只能通过全量备份+应用binlog的方式来恢复数据。一旦数据量比较大,那么恢复时间就特别长。
rm 删除：使用备份跨机房，或者最好是跨城市保存。
DELETE语句执行删除的过程是每次从表中删除一行，并且同时将该行的删除操作作为事务记录在日志中保存以便进行进行回滚操作。
TRUNCATE TABLE 则一次性地从表中删除所有的数据并不把单独的删除操作记录记入日志保存，删除行是不能恢复的。并且在删除的过程中不会激活与表有关的删除触发器，执行速度快。
drop语句将表所占用的空间全释放掉。
MySQL 是“边读边发的”，这就意味着，如果客户端接收得慢，会导致 MySQL 服务端由于结果发不出去，这个事务的执行时间变长。
服务端并不需要保存一个完整的结果集。取数据和发数据的流程都是通过一个next_buffer来操作的。
内存的数据页是在 Buffer Pool (BP) 中管理的。
InnoDB 管理 Buffer Pool 使用改进的 LRU 算法，是用链表来实现的。在 InnoDB 实现上，按照 5:3 的比例把整个 LRU 链表分成了 young 区域和 old 区域，确保大批量加载冷数据时不会冲掉热点数据。
用id优化：先找到上次分页的最大ID,然后利用id上的索引来查询,类似于select * from user where id>1000000 limit 100。
用覆盖索引优化：Mysql的查询完全命中索引的时候,称为覆盖索引,是非常快的,因为查询只需要在索引上进行查找,之后可以直接返回,而不用再回表拿数据.因此我们可以先查出索引的ID,然后根据Id拿数据。
在业务允许的情况下限制页数
添加合适索引：对作为查询条件和order by的字段建立索引，对于多个查询字段的考虑建立组合索引，同时注意组合索引字段的顺序,将最常用作限制条件的列放在最左边，依次递减，索引不宜太多，一般5个以内。
优化表结构：数字型字段优于字符串类型，数据类型更小通常更好，尽量使用 NOT NULL
优化查询语句：分析SQl执行计划，是否命中索引等，如果SQL很复杂，优化SQL结构，如果表数据量太大，考虑分表
在执行show processlist的结果里，看到了几千个连接，指的是并发连接。
而"当前正在执行"的语句，才是并发查询。
并发连接数多影响的是内存。
并发查询太高对CPU不利。一个机器的CPU核数有限，线程全冲进来，上下文切换的成本就会太高。
需要注意的是，在线程进入锁等待以后，并发线程计数减一，所以等行锁或者间隙锁时的线程是不算在计数范围内的。也就是说进入锁等待的线程不吃CPU，从而避免整个系统锁死。
相同的数据时，不会做update更新。
不过对不同的binlog格式，处理的日志方式有所不同：
1）基于row模式时，server层匹配到要更新的记录，发现新值和旧值一致，不做更新，就直接返回，也不记录binlog。
2）基于 statement 或者 mixed格式时，MySQL执行 update 语句，并把更新语句记录到binlog。
datetime 的日期范围是 1001——9999 年；timestamp 的时间范围是 1970——2038 年
datetime 存储时间与时区无关；timestamp 存储时间与时区有关，显示的值也依赖于时区
datetime 的存储空间为 8 字节；timestamp 的存储空间为 4 字节
datetime 的默认值为 null；timestamp 的字段默认不为空(not null)，默认值为当前时间(current_timestamp)
「读未提交」（Read Uncommitted）最低级别，任何情况都无法保证
「读已提交」（Read Committed）可避免脏读的发生
「可重复读」（Repeatable Read）可避免脏读、不可重复读的发生
「串行化」（Serializable）可避免脏读、不可重复读、幻读的发生
Mysql默认的事务隔离级别是「可重复读」(Repeatable Read)
kill query + 线程 id，表示终止这个线程中正在执行的语句
kill connection + 线程 id，这里 connection 可缺省，表示断开这个线程的连接
根据叶子节点的内容，索引类型分为主键索引和非主键索引。
主键索引的叶子节点存的是整行数据。在 InnoDB 里，主键索引也被称为聚簇索引（clustered index）。
非主键索引的叶子节点内容是主键的值。在 InnoDB 里，非主键索引也被称为二级索引（secondary index）。
聚集索引：聚集索引就是以主键创建的索引，聚集索引在叶子节点存储的是表中的数据。
非聚集索引：非主键创建的索引，在叶子节点存储的是主键和索引列，使用非聚集索引查询出数据时，拿到叶子上的主键再去查到想要查找的数据。(拿到主键再查找这个过程叫做回表)。
覆盖索引：假设所查询的列，刚好都是索引对应的列，不用再回表查，那么这个索引列就叫覆盖索引。
哈希索引能够以 O(1) 的速度处理单个数据行的增删改查，但是面对范围查询或者排序时就会导致全表扫描的结果。
B树可以在非叶结点中存储数据，由于所有的节点都可能包含目标数据，我们总是要从根节点向下遍历子树查找满足条件的数据行，这个特点带来了大量的随机 I/O，造成性能下降。
B+树所有的数据行都存储在叶节点中，而这些叶节点可以通过『指针』依次按顺序连接，当我们在如下所示的 B+ 树遍历数据时可以直接在多个子节点之间进行跳转，这样能够节省大量的磁盘 I/O 时间。
二叉树：树的高度不均匀，不能自平衡，查找效率跟数据有关（树的高度），并且IO代价高。
红黑树：树的高度随着数据量增加而增加，IO代价高。
在InnoDB里，索引B+ Tree的叶子节点存储了整行数据的是主键索引，也被称之为聚簇索引，即将数据存储与索引放到了一块，找到索引也就找到了数据。
而索引B+Tree的叶子节点存储了主键的值的是非主键索引，也被称之为非聚簇索引、二级索引。
第一次索引一般是顺序IO，回表的操作属于随机IO。需要回表的次数越多，即随机IO次数越多，我们就越倾向于使用全表扫描 。
不一定，这涉及到查询语句所要求的字段是否全部命中了索引，如果全部命中了索引，那么就不必再进行回表查询。一个索引包含（覆盖）所有需要查询字段的值，被称之为“覆盖索引”。
最左前缀原则就是最左优先，在创建多列索引时，要根据业务需求，where子句中使用最频繁的一列放在最左边。
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的顺序可以任意调整。
=和in可以乱序，比如a = 1 and b = 2 and c = 3 建立（a，b，c）索引可以任意顺序，MySQL的查询优化器会帮你优化成索引可以识别的形式。
满足最左前缀原则的时候，最左前缀可以用于在索引中定位记录。
在 MySQL 5.6 之前，只能从ID开始一个个回表。到主键索引上找出数据行，再对比字段值。
而 MySQL 5.6 引入的索引下推优化（index condition pushdown)， 可以在索引遍历过程中，对索引中包含的字段先做判断，直接过滤掉不满足条件的记录，减少回表次数。
如果表使用自增主键，那么每次插入新的记录，记录就会顺序添加到当前索引节点的后续位置，当一页写满，就会自动开辟一个新的页。如果使用非自增主键（如果身份证号或学号等），由于每次插入主键的值近似于随机，因此每次新纪录都要被插到现有索引页得中间某个位置， 频繁的移动、分页操作造成了大量的碎片，得到了不够紧凑的索引结构，后续不得不通过OPTIMIZE TABLE（optimize table）来重建表并优化填充页面。
「原子性」：是使用 undo log 来实现的，如果事务执行过程中出错或者用户执行了rollback，系统通过undo log日志返回事务开始的状态。
「持久性」：使用 redo log 来实现，只要redo log日志持久化了，当系统崩溃，即可通过redo log把数据恢复。
「隔离性」：通过锁以及 MVCC,使事务相互隔离开。
「一致性」：通过回滚、恢复，以及并发情况下的隔离性，从而实现一致性。
InnoDB 存储引擎：B+ 树索引的叶子节点保存数据本身；
MyISAM 存储引擎：B+ 树索引的叶子节点保存数据的物理地址；
InnoDB，其数据文件本身就是索引文件，相比MyISAM，索引文件和数据文件是分离的，其表数据文件本身就是按B+Tree组织的一个索引结构，树的节点data域保存了完整的数据记录，这个索引的key是数据表的主键，因此InnoDB表数据文件本身就是主索引，这被称为“聚簇索引”或者聚集索引，而其余的索引都作为辅助索引，辅助索引的data域存储相应记录主键的值而不是地址，这也是和MyISAM不同的地方。
根据叶子节点的内容，索引类型分为主键索引和非主键索引。
主键索引的叶子节点存的是整行数据。在 InnoDB 里，主键索引也被称为聚簇索引（clustered index）。
非主键索引的叶子节点内容是主键的值。在 InnoDB 里，非主键索引也被称为二级索引（secondary index）。
背景：B+ 树提供的这个快速定位能力，来源于同一层兄弟节点的有序性，所以说破坏了这个有序性，大概率就失效了，具体有如下几种情况：
对索引使用左或者左右模糊匹配：也就是 like %xx 或者 like %xx% 这两种方式都会造成索引失效。原因在于查询的结果可能是「陈林、张林、周林」等之类的，所以不知道从哪个索引值开始比较，于是就只能通过全表扫描的方式来查询。
对索引使用函数/对索引进行表达式计算：因为索引保存的是索引字段的原始值，而不是经过函数计算后的值，自然就没办法走索引了。
对索引隐式类型转换：相当于用了新函数
WHERE 子句中的 OR：的含义就是两个只要满足一个即可，因此只有一个条件列是索引列是没有意义的，只要有条件列不是索引列，就会进行全表扫描。
停机扩容（不推荐）
双写迁移方案：设计好扩容后的表结构方案，然后对单库和分库实现双写，观察一周没问题后，关闭单库的读流量，再观察一段时间，持续稳定后，关闭单库的写流量，平滑切换到分库分表中。
Server层按顺序执行sql的步骤为：
客户端请求 -> 连接器（验证用户身份，给予权限） -> 查询缓存（存在缓存则直接返回，不存在则执行后续操作）-> 分析器（对SQL进行词法分析和语法分析操作） -> 优化器（主要对执行的sql优化选择最优的执行方案方法） -> 执行器（执行时会先看用户是否有执行权限，有才去使用这个引擎提供的接口）-> 去引擎层获取数据返回（如果开启查询缓存则会缓存查询结果）。
MySQL会为每个线程分配一个内存（sort_buffer）用于排序该内存大小为sort_buffer_size。
如果排序的数据量小于sort_buffer_size，排序将会在内存中完成。
如果排序数据量很大，内存中无法存下这么多数据，则会使用磁盘临时文件来辅助排序，也称外部排序。
在使用外部排序时，MySQL会分成好几份单独的临时文件用来存放排序后的数据，然后在将这些文件合并成一个大文件。
MVCC(Multiversion concurrency control) 就是同一份数据保留多版本的一种方式，进而实现并发控制。在查询的时候，通过read view和版本链找到对应版本的数据。
作用：提升并发性能。对于高并发场景，MVCC 比行级锁开销更小。
MVCC 的实现依赖于版本链，版本链是通过表的三个隐藏字段实现。
1）DB_TRX_ID：当前事务 id，通过事务 id 的大小判断事务的时间顺序。
2）DB_ROLL_PRT：回滚指针，指向当前行记录的上一个版本，通过这个指针将数据的多个版本连接在一起构成undo log版本链。
3）DB_ROLL_ID：主键，如果数据表没有主键，InnoDB 会自动生成主键。
只要 redolog 和 binlog 保证持久化磁盘就能确保 MySQL 异常重启后数据恢复 binlog 写入机制。
redolog确保系统异常后，丢失的数据可以重做，binlog将数据进行归档，确保丢失的数据可以恢复。
事务执行前先写redolog，事务执行过程中，先把日志写到 binlog cache 里，事务提交的时候，再把 binlog cache 写到 binlog 文件中。
数据项删除之后InnoDB标记 page A 会被标记为可复用
delete 命令把整个表的数据删除呢？结果就是，所有的数据页都会被标记为可复用。但是磁盘上，文件不会变小。
经过大量增删改的表，都是可能是存在空洞的。这些空洞也占空间所以，如果能够把这些空洞去掉，就能达到收缩表空间的目的。
重建表，就可以达到这样的目的。可以使用 alter table A engine=InnoDB 命令来重建表。
row格式的binlog记录的操作行的主键id以及每个字段的真实值，所以不会出现主备操作数据不一致的情况。
statement：记录的源SQL语句
mixed：前两种混合，为什么还需要有mixed格式的文件，因为有些 statement 格式的 binlog 可能会导致主备不一致，所以要使用 row 格式。但 row 格式的缺点是，很占空间。MySQL 就取了个折中方案，MySQL 自己会判断这条 SQL 语句是否可能引起主备不一致，如果有可能，就用 row 格式，否则就用 statement 格式。
原则 1：加锁的基本单位是 next-key lock，next-key lock 是前开后闭区间。
原则 2：查找过程中访问到的对象才会加锁
优化 1：索引上的等值查询，给唯一索引加锁的时候，next-key lock 退化为行锁。
优化 2：索引上的等值查询，向右遍历时且最后一个值不满足等值条件的时候，next-key lock 退化为间隙锁
一个 bug：唯一索引上的范围查询会访问到不满足条件的第一个值为止。
「脏读」: 脏读指的是读到了其他事务未提交的数据，未提交意味着这些数据可能会回滚，也就是可能最终不会存到数据库中，也就是不存在的数据。读到了并不一定最终存在的数据，这就是脏读。
「不可重复读」: 不可重复读指的是在一个事务内，最开始读到的数据和事务结束前的任意时刻读到的同一批数据出现不一致的情况。
「幻读」: 幻读，并不是说两次读取获取的结果集不同，幻读侧重的方面是某一次的 select 操作得到的结果的数据状态无法支撑后续的业务操作。更为具体一些：select 某记录是否存在，不存在，准备插入此记录，但执行 insert 时发现此记录已存在，无法插入，此时就发生了幻读。
从锁的类别上来讲,有共享锁和排他锁。
1）共享锁: 又叫做读锁. 当用户要进行数据的读取时,对数据加上共享锁.共享锁可以同时加上多个。
2）排他锁: 又叫做写锁. 当用户要进行数据的写入时,对数据加上排他锁.排他锁只可以加一个,他和其他的排他锁,共享锁都相斥。
锁的粒度取决于具体的存储引擎,InnoDB实现了行级锁,页级锁,表级锁。
他们的加锁开销从大大小,并发能力也是从大到小。
Master的更新事件(update、insert、delete)会按照顺序写入bin-log中。当Slave连接到Master的后,Master机器会为Slave开启binlog dump线程,该线程会去读取bin-log日志。
Slave连接到Master后,Slave库有一个I/O线程 通过请求binlog dump thread读取bin-log日志,然后写入从库的relay log日志中。
Slave还有一个 SQL线程,实时监控 relay-log日志内容是否有更新,解析文件中的SQL语句,在Slave数据库中去执行。
异步复制：Mysql主从同步 默认是异步复制的。就是上面三步中,只有第一步是同步的(也就是Mater写入bin log日志),就是主库写入binlog日志后即可成功返回客户端，无须等待binlog日志传递给从库的过程。
同步复制：对于同步复制而言，Master主机将事件发送给Slave主机后会触发一个等待，直到所有Slave节点（如果有多个Slave）返回数据复制成功的信息给Master。
半同步复制：对于半同步复制而言，Master主机将事件发送给Slave主机后会触发一个等待，直到其中一个Slave节点（如果有多个Slave）返回数据复制成功的信息给Master。
主节点如果执行一个很大的事务，那么就会对主从延迟产生较大的影响
网络延迟，日志较大，slave数量过多
主上多线程写入，从节点只有单线程同步
机器性能问题，从节点是否使用了“烂机器”
锁冲突问题也可能导致从机的SQL线程执行慢
大事务：将大事务分为小事务，分批更新数据
减少Slave的数量，不要超过5个，减少单次事务的大小
Mysql 5.7之后，可以使用多线程复制，使用MGR复制架构
在磁盘、raid卡、调度策略有问题的情况下可能会出现单个IO延迟很高的情况，可用iostat命令查看DB数据盘的IO情况，再进一步判断
针对锁问题可以通过抓去processlist以及查看information_schema下面和锁以及事务相关的表来查看。
bin log是Mysql数据库级别的文件，记录对Mysql数据库执行修改的所有操作，不会记录select和show语句。
redo log中记录的是要更新的数据，比如一条数据已提交成功，并不会立即同步到磁盘，而是先记录到redo log中，等待合适的时机再刷盘，为了实现事务的持久性。
undo log用于数据的撤回操作，它保留了记录修改前的内容。通过undo log可以实现事务回滚，并且可以根据undo log回溯到某个特定的版本的数据，实现MVCC。
到此，相信大家对“MySQL的基础问题有哪些”有了更深的了解，不妨来实际操作一番吧！这里是亿速云网站，更多相关内容可以进入相关频道进行查询，关注我们，继续学习！
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
