1。Binlog是什么，有什么用？（数据库被kill掉了怎么办？）1.binLog：数据恢复主从复制MySQLServer层还有一个日志文件叫binlog，所有存储引擎都可以使用。Binlog以事件的形式记录了所有的DDL和DML语句（因为它记录的是操作而不是数据值，属于逻辑日志），可用于主从复制和数据恢复。凌晨1点程序员全量备份1点---9点和10点数据文件全部删除恢复1点到9点数据恢复：不同于RedoLog的crashrecovery，数据恢复是基于业务的数据，比如删除数据库跑路，crashrecovery是断电重启。什么是预读？磁盘读写不是按需读取，而是按页读取，一次至少读取一页数据（一般为4K），但是Mysql的数据页是16K，如果以后要读取的数据在页面，就可以节省后续的磁盘IO，提高效率。什么是缓冲池？性能优化的一点是缓存表数据和索引数据，将磁盘上的数据加载到缓冲池中，避免每次访问都要磁盘IO，加快访问速度。BufferPool的内存淘汰策略LRU策略冷热分区的LRU链表会被拆分成两部分，一部分是热数据，一部分是冷数据。冷数据占3/8，热数据占5/8。数据页第一次加载时，放在LRU链表的什么位置？什么时候将冷数据区的缓存页放入热数据区？MySQL设定了一个规则。innodb_old_blocks_time参数中，默认值为1000，即1000毫秒。意思是只有当数据页加载到缓存中，1秒后再次访问缓存页时，才会将缓存页放在LRU链表的热点数据区头部。为什么是1秒？因为通过预读机制和全表扫描加载的数据页通常在1秒内完成加载，然后再访问，都在1秒内完成。它们会被存放在冷数据区，等待磁盘被清空。基本上不太可能有机会被放到热点数据区，除非1秒后有人访问，说明以后可能有人访问，就会被放到热点数据区的头部。RedoLog和BufferPoolcrashrecovery的关系基本可以保证。由系统自动完成的InnoDB引入了一个名为重做日志（redolog）的日志文件。我们将所有对内存数据的修改操作写入日志文件。如果服务器出现故障，我们从这个日志文件中读取数据并恢复数据——用它来实现事务持久化。redolog有什么特点？1、记录修改后的值，属于物理日志。2、redolog的大小是固定的，之前的内容会被覆盖，所以不能用于数据回滚/数据恢复。3、redolog是InnoDB存储引擎实现的，并不是所有的存储引擎都有。3、Mysql的架构是什么样的（一??条查询语句是如何执行的？）A500B800C1000小表驱动大表查询缓存（QueryCache）MySQL内部自带缓存模块。默认关闭。主要原因是MySQL内置缓存的应用场景有限。第一个是它要求SQL语句必须完全相同。二是当表中任意一条数据发生变化时，该表中的所有缓存都会失效。在MySQL5.8中，查询缓存已被删除。解析和预处理（Parser&Preprocessor）接下来我们应该做什么？如果你执行随机字符串fkdljasklf，服务器报1064错误：[Err]1064-你的SQL语法有错误；检查与您的MySQL服务器版本对应的手册，了解在“fkdljasklf”附近使用的正确语法第1行的服务器如何知道我键入的内容是错误的？或者，当我输入语法完全正确的SQL，但表名不存在时，它如何发现？这是MySQL的Parser解析器和Preprocessor预处理模块。这一步主要是对SQL语句进行词法语法分析和语义分析。词法分析词法分析是将一个完整的SQL语句分解成单个的单词。例如一条简单的SQL语句：selectnamefromuserwhereid=1;它将被分成8个符号，记录每个符号的类型，开始和结束的位置。语法分析的第二步是语法分析。语法分析会检查SQL的语法，比如单引号是否闭合，然后根据MySQL定义的语法规则，根据SQL语句生成一个数据结构。我们称这种数据结构为解析树。如果预处理器（Preprocessor）的表名不正确，预处理器处理时会报错。它检查生成的解析树，解析解析器无法解析的语义。例如，它检查表名和列名是否存在，并检查名称和别名以确保没有歧义。查询优化器和查询执行计划什么是优化器？问题：一条SQL语句的执行方式只有一种吗？还是数据库最终执行的SQL和我们发送的SQL是一样的？答案是否定的。SQL语句可以以多种方式执行。但是如果有这么多执行方法，那么这些执行方法是怎么得到的呢？最终选择哪一个？根据什么标准来选择？这就是MySQL的查询优化器模块（Optimizer）。查询优化器的目的是根据解析树生成不同的执行计划，然后选择一个最优的执行计划。MySQL使用基于成本的优化器。使用成本最低的执行计划。.使用以下命令查看查询成本：showstatuslike'Last_query_cost';--意思是需要随机读取几个4K的数据页来完成查找。如果我们想知道优化器是如何工作的，它会生成若干个执行计划，每个执行计划的成本是多少，我们应该怎么做？优化器是如何得到执行计划的？https://dev.mysql.com/doc/internals/en/optimizer-tracing.html首先我们需要启用优化器跟踪（默认情况下关闭）：SHOWVARIABLESLIKE'optimizer_trace';设置optimizer_trace="enabled=on";注意打开这个开关会消耗性能，因为它需要将优化分析的结果写入表中，所以不要轻易打开，或者查看后关闭（改成off）。然后我们执行一个SQL语句，优化器会生成一个执行计划：selectt.tcidfromteachert,teacher_contacttcwheret.tcid=tc.tcid;此时系统表中已经记录了优化器分析的过程，我们可以查询：select*frominformation_schema.optimizer_trace\Gexpanded_query是优化后的SQL语句。所有执行计划都列在considered_execution_plans中。记得关掉它：setoptimizer_trace="enabled=off";?显示像“optimizer_trace”这样的变量；优化器能做什么？MySQL的优化器可以处理哪些类型的优化？例如：1、当我们对多个表进行关联查询时，以哪个表的数据作为参考表。2.select*fromuserwherea=1andb=2andc=3，如果c=3有100个结果，b=2有200个结果，a=1有300个结果，你怎么看？首先执行哪个过滤器？3.如果条件中存在一些恒等式或不等式，是否可以去掉？4、查询数据，是否可以直接从索引中获取值。5、count()、min()、max()，例如是否可以直接从索引中获取值。6.其他。优化器得到的结果优化器最终会将解析树变成查询执行计划，这是一种数据结构。当然，这个执行计划一定是最优执行计划吗？不一定，因为MySQL可能不会涵盖所有的执行计划。MySQL提供了执行计划的工具。我们可以通过在SQL语句前加上EXPLAIN来查看执行计划信息。EXPLAIN从id=1的用户中选择名称；4.一条更新语句要经过那些过程5.为什么Mysql使用B+树作为索引B树B+树可以显着减少IO次数，提高效率B+树的查询效率更稳定，因为数据是放在叶子结点B+树可以提高范围查询的效率，因为叶子结点指向下一个叶子结点B+树采用顺序读6.磁盘的顺序读和随机读有什么区别？（这个可能让你在大厂聊一聊，问的方式有很多）1.磁盘2.磁头3.主轴4.集成电路板磁盘如何完成单次IO？单次IO时间=寻道时间+轮转延迟+传输时间7.索引使用原则（如何使用索引才是合理的）我们容易有一个误区，就是在经常使用的查询条件上建索引，越多索引越好，是这样吗？羊毛布？列的离散性（sàn）第一个称为列的离散性。我们来看看列的离散度公式：不同值的个数：总行数越接近1，离散度越高，越接近0，离散度越高lowcount(distinct(column_name)):count(*)，列的总不同值和所有数据行的比例。在数据行数相同的情况下，分子越大，列的离散度越高。联合索引的最左匹配前面我们说过，索引是针对单列创建的，但是有时候我们在多条件查询的时候，也会创建联合索引。例如：查询成绩时，必须同时输入身份证和考号。联合索引是B+Tree中的一种复合数据结构，按照从左到右的顺序（姓名在左，电话在右）构建一棵搜索树。从这张图可以看出，name是有序的，phone是无序的。当名称相同时，电话会被排序。这时候，当我们使用wherename='jim'andphone='136xx'查询数据时，B+Tree会先比较name来决定下一次查找的方向，left还是right。如果名称相同，则比较手机。但是如果查询条件没有名字，你不知道第一步要查哪个节点，因为建搜索树时名字是第一个比较因素，所以没有使用索引。如何创建联合索引有一天我们的DBA来找我说我们的项目中有两个查询非常慢。按照我们的想法，一个查询创建一个索引，所以我们为这两个SQL创建了两个索引。你认为这是正确的做法吗？在user_innodb(name)上创建索引idx_name；在user_innodb(name,phone)上创建索引idx_name_phone；我们在创建联合索引时，根据最左匹配原则，在使用左字段名查询时，也可以使用索引，所以第一个索引是完全没有必要的。相当于建立了两个联合索引（name），（name，phone）。如果我们创建一个三个字段的索引index(a,b,c)，相当于创建三个索引：index(a)index(a,b)index(a,b,c)withwhereb=?在哪里b=？和c=?不能使用索引。这就是MySQL中联合索引的最左匹配原则。覆盖索引和回表什么叫回表：不需要回表就叫覆盖索引聚集索引：id二级索引：name非主键索引，我们先通过索引找到主键索引的键值，然后通过主键值查找索引如果没有数据，则比基于主键索引的查询多扫描一棵索引树。这个过程称为返回表。在辅助索引中，无论是单列索引还是联合索引，如果选择的数据列只能从索引中获取，不需要从数据区读取，此时使用的索引是称为覆盖索引，它避免返回表面。Extra中的值为“Usingindex”，表示使用覆盖索引。8、索引的创建和使用因为索引对于提高查询性能有着巨大的作用，所以我们的目标是尽可能的使用索引。在什么领域建立索引？1、在(on)字段上创建索引，用于where判断、顺序排序和join。2、索引数量不宜过多。-浪费空间，更新速度较慢。3、不要为性别等歧视性低的字段建立索引。-色散太低，导致扫描线太多。4.不要使用频繁更新的值作为主键或索引。——分页5.随机无序的值不推荐作为主键索引，比如身份证、UUID。——无序，拆分6.创建复合索引，而不是修改单列索引。索引什么时候失效？1.索引列上使用函数（replace\SUBSTR\CONCAT\sumcountavg）和表达式。2.字符串没有被引用，发生隐式转换。3.%在like条件之前。4.负查询NOTLIKE不能是HashIndex##MyiSAM和Innodbmyiindexmyd数据我们表中的数据是按照聚集索引的顺序排列的本文由博客发布平台OpenWrite发布！
