无锡公司做网站,wordpress无法导入xml,前端外包网,网站建设四个阶段MySQL面试题 MySQL 存储引擎架构了解吗#xff1f;CHAR 和 VARCHAR 的区别是什么#xff1f;索引是越多越好嘛#xff1f;MySQL数据库中空值#xff08;null#xff09;和空字符串#xff08;#xff09;的区别#xff1f;SQL 中 on 条件与 where 条件的区别#xff1… MySQL面试题 MySQL 存储引擎架构了解吗CHAR 和 VARCHAR 的区别是什么索引是越多越好嘛MySQL数据库中空值null和空字符串的区别SQL 中 on 条件与 where 条件的区别Explain执行计划Explain执行计划结果参数的含义数据库的存储引擎数据库的3范式为什么用B树不用B树用了索引还是很慢可能是什么原因左连接、右连接、内连接的区别MySQL中如何定位慢查询?那这个SQL语句执行很慢, 如何分析呢了解过索引吗什么是索引索引的底层数据结构了解过嘛 ?B树和B树的区别是什么呢什么是聚簇索引什么是非聚簇索引二级索引 ?知道什么是回表查询嘛 ?知道什么叫覆盖索引嘛 ?MYSQL超大分页怎么处理 ?索引创建原则有哪些什么情况下索引会失效 ?sql的优化的经验创建表的时候你们是如何优化的呢那在使用索引的时候是如何优化呢你平时对sql语句做了哪些优化呢事务的特性是什么可以详细说一下吗并发事务带来哪些问题怎么解决这些问题呢MySQL的默认隔离级别是Binlog、undo log和redo log的区别事务中的隔离性是如何保证的呢(你解释一下MVCC)MySQL主从同步原理 你们项目用过MySQL的分库分表吗那你之前使用过水平分库吗 MySQL 存储引擎架构了解吗
MySQL 存储引擎采用的是 插件式架构 支持多种存储引擎我们甚至可以为不同的数据库表设置不同的存储引擎以适应不同场景的需要。存储引擎是基于表的而不是数据库。
并且你还可以根据 MySQL 定义的存储引擎实现标准接口来编写一个属于自己的存储引擎。这些非官方提供的存储引擎可以称为第三方存储引擎区别于官方存储引擎。像目前最常用的 InnoDB 其实刚开始就是一个第三方存储引擎后面由于过于优秀其被 Oracle 直接收购了。
CHAR 和 VARCHAR 的区别是什么
CHAR 和 VARCHAR 是最常用到的字符串类型两者的主要区别在于CHAR 是定长字符串VARCHAR 是变长字符串。
索引是越多越好嘛
索引并不是越多越好索引固然可以提⾼相应的 select 的效率但同时也降低了 insert 及 update 的效率因为 insert 或 update 时有可能会重建索引所以怎样建索引需要慎重考虑视具体情况⽽定。⼀个表的索引数最好不要超过6个若太多则应考虑⼀些不常使⽤到的列上建的索引是否有必要。
MySQL数据库中空值null和空字符串‘’的区别
空字符串(’’)的长度是0是不占用空间的而的NULL的长度是NULL其实它是占用空间的。当字段不为NULL时也可以插入空字符串NULL值查询使用is null/is not null查询而空字符串(’’)可以使用或者!、、等算术运算符。使用 COUNT(字段) 统计会过滤掉 NULL 值但是不会过滤掉空字符串。
SQL 中 on 条件与 where 条件的区别 1、on 条件是在生成临时表时使用的条件它不管 on 中的条件是否为真都会返回左边表中的记录。 2、where 条件是在临时表生成好后再对临时表进行过滤的条件。这时已经没有 left join 的含义必须返回左边表的记录了条件不为真的就全部过滤掉。
Explain执行计划 Explain是 SQL 分析工具中非常重要的一个功能它可以模拟优化器执行查询语句帮助我们理解查询是如何执行的分析查询执行计划可以帮助我们发现查询瓶颈优化查询性能。如下 ① 表的读取顺序 ② SQL执行时查询操作类型 ③可以使用哪些索引 ④ 实际使用哪些索引 ⑤每张表有多少行记录被扫描 ⑥SQL语句性能分析 Explain执行计划结果参数的含义 idid越大先执行id相同则由上往下执行;select_type:查询的类型,主要用于区别普通查询,联合查询,子查询等复杂查询table:显示一行数据是属于哪张表的type查询类型从最好到最差依次是:systemconsteq_refrefrangeindexAll,一般情况下,得至少保证达到index级别,最好能达到ref。possible_keys显示可能应用在这张表中的索引,一个或多个,查询到的索引不一定是真正被用到的key实际使用的索引,如果为null,则没有使用索引,因此会出现possible_keys列有可能被用到的索引,但是key列为null,表示实际没用索引。key-length表示索引中使用的字节数,而通过该列计算查询中使用的 索引长度,在不损失精确性的情况下,长度越短越好,keylen显示的值为索引字段的最大可能长度,并非实际使用长度ref 显示索引的哪一列被使用了rows 全表扫描时表示需要扫描表的行数估计值索引扫描时表示扫描索引的行数估计值值越小越好不是结果集中的行数ExtraExtra 列表示 SQL 执行查询的一些额外信息。
数据库的存储引擎
常用的存储引擎有以下
● Innodb引擎Innodb引擎提供了对数据库ACID事务的支持。并且还提供了行级锁和外键的约束。它的设计的目标就是处理大数据容量的数据库系统。MySQL默认值的存储引擎。 ● MyIASM引擎不提供事务的支持也不支持行级锁和外键查询效率高储存空间小。
InnoDB表的数据是存储在磁盘中真正处理数据的过程发生在内存中所以需要把磁盘中的数据加载到内存中。如果是处理写入请求还需要把内存中的内容刷新到磁盘上。
InnoDB 采取的方式是将数据划分为若干个页以页作为磁盘和内存之间交互的基本单位。InnoDB 中页的大小一股为16KB。也就是在一般情况下一次最少从磁盘中读取 16KB 的内容到内存中一次最少把内存中的 16KB 内容刷新到磁盘中。
如何查找一条数据 1、先在B数中找到记录所在的页 2、把页加载入内存 3、通过 Page Directory 进行二叉查找。因为 Page Directory 是稀疏的所有只能找到大概位置 4、在步骤3的基础上继续根据记录偏移量一行一行的查找
数据库的3范式
第一范式原子性数据库表中的所有字段值都是不可再分的原子值第二范式唯一性数据库表中的每一列都和主键相关而不能只与主键的某一部分相关第三范式独立性确保数据表中的每一列数据都和主键直接相关而不能间接相关消除传递依赖(非主键值不依赖于另一个非主键值)
为什么用B树不用B树
我认为有四点
B树的磁盘读写代价更低B树非叶子节点不存放数据只存放指针扫描的数据更多B树的查询效率更加稳定B树只在叶子节点存放数据所以查询的路径长度相同B树更便于遍历B树只需要扫描一遍叶子节点就可以B树更适合基于范围的查询 B树都在叶子节点存储数据且顺序排列并且叶子节点是一个双向链表
用了索引还是很慢可能是什么原因
选错索引当存在多个索引时mysql的优化器会选择一个所以可能导致选错。数据分布不均匀如果数据分布不匀,就可能导致某些索弓|节点的数据量很大而另外一些节点的数据量很少从而使查询性能下降。sql语句存在问题数据库设计不合理
左连接、右连接、内连接的区别
左连接是查询左侧表中的所有记录以及右侧表中与之匹配的记录 而右连接是查询右侧表中的所有记录以及左侧表中与之匹配的记录 内连接是查询两张表中有交集的部分
MySQL中如何定位慢查询?
我们当时做压测的时候有的接口非常的慢接口的响应时间超过了2秒以上因为我们当时的系统部署了运维的监控系统Skywalking 在展示的报表中可以看到是哪一个接口比较慢并且可以分析这个接口哪部分比较慢这里可以看到SQL的具体的执行时间所以可以定位是哪个sql出了问题。 如果项目中没有这种运维的监控系统其实在MySQL中也提供了慢日志查询的功能可以在MySQL的系统配置文件中开启这个慢日志的功能并且也可以设置SQL执行超过多少时间来记录到一个日志文件中我记得上一个项目配置的是2秒只要SQL执行的时间超过了2秒就会记录到日志文件中我们就可以在日志文件找到执行比较慢的SQL了。
那这个SQL语句执行很慢, 如何分析呢
如果一条sql执行很慢的话我们通常会使用mysql自动的执行计划explain来去查看这条sql的执行情况比如在这里面可以通过key和key_len检查是否命中了索引如果本身已经添加了索引也可以判断索引是否有失效的情况第二个可以通过type字段查看sql是否有进一步的优化空间是否存在全索引扫描或全盘扫描第三个可以通过extra建议来判断是否出现了回表的情况如果出现了可以尝试添加索引或修改返回字段来修复
了解过索引吗什么是索引
索引在项目中还是比较常见的它是帮助MySQL高效获取数据的数据结构主要是用来提高数据检索的效率降低数据库的IO成本同时通过索引列对数据进行排序降低数据排序的成本也能降低了CPU的消耗。
索引的底层数据结构了解过嘛 ?
MySQL的默认的存储引擎InnoDB采用的B树的数据结构来存储索引选择B树的主要的原因是第一阶数更多路径更短第二个磁盘读写代价B树更低非叶子节点只存储指针叶子阶段存储数据第三是B树便于扫库和区间查询叶子节点是一个双向链表
B树和B树的区别是什么呢
B数 B数
第一在B树中非叶子节点和叶子节点都会存放数据而B树的所有的数据都会出现在叶子节点在查询的时候B树查找效率更加稳定
第二在进行范围查询的时候B树效率更高因为B树都在叶子节点存储并且叶子节点是一个双向链表
什么是聚簇索引什么是非聚簇索引二级索引 ? 举个栗子
聚簇索引主要是指数据与索引放到一块B树的叶子节点保存了整行数据有且只有一个一般情况下主键在作为聚簇索引的。
非聚簇索引值的是数据与索引分开存储B树的叶子节点保存对应的主键可以有多个一般我们自己定义的索引都是非聚簇索引。 w
知道什么是回表查询嘛 ?
这个和聚簇索引和非聚簇索引是有关系的回表的意思就是通过二级索引找到对应的主键值然后再通过主键值找到聚集索引中所对应的整行数据这个过程就是回表。
知道什么叫覆盖索引嘛 ?
覆盖索引是指select查询语句使用了索引在返回的列必须在索引中全部能够找到如果我们使用id查询它会直接走聚集索引查询一次索引扫描直接返回数据性能高。
如果按照二级索引查询数据的时候返回的列中没有创建索引有可能会触发回表查询尽量避免使用select *尽量在返回的列中都包含添加索引的字段。
MYSQL超大分页怎么处理 ?
超大分页一般都是在数据量比较大时我们使用了limit分页查询并且需要对数据进行排序这个时候效率就很低我们可以采用覆盖索引和子查询来解决。 先分页查询数据的id字段确定了id之后再用子查询来过滤只查询这个id列表中的数据就可以了。 因为查询id的时候走的覆盖索引所以效率可以提升很多。
索引创建原则有哪些
这个情况有很多不过都有一个大前提就是表中的数据要超过10万以上我们才会创建索引并且添加索引的字段是查询比较频繁的字段一般也是像作为查询条件排序字段或分组的字段这些。
还有就是我们通常创建索引的时候都是使用复合索引来创建一条sql的返回值尽量使用覆盖索引如果字段的区分度不高的话我们也会把它放在组合索引后面的字段。
如果某一个字段的内容较长我们会考虑使用前缀索引来使用当然并不是所有的字段都要添加索引这个索引的数量也要控制因为添加索引也会导致新增改的速度变慢。
什么情况下索引会失效 ?
比如第一个是索引在使用的时候没有遵循最左匹配法则 第二个是如果在添加索引的字段上进行了运算操作或者类型转换也都会导致索引失效。 第三个是字符串不加单引号造成索引失效。 第四个是以%开头的like模糊查询索引失效如果%在前面索引失效%在后面索引不失效。 第五个是如果使用了复合索引中间使用了范围查询右边的条件索引也会失效。 第六个是查询条件中有or,即使有部分条件带索引也会失效。
所以通常情况下想要判断出这条sql是否有索引失效的情况可以使用explain执行计划来分析。
sql的优化的经验
我觉得可以分为几个方面 1、使用合适的索引通过在经常查询的字段上创建索引可以加快查询速度。 2、优化查询语句尽量避免使用SELECT *只选择需要的字段尽量避免在字段开头模糊查询多表关联以小表为驱动尽量避免null值的判断多次插入改为批量插入。 3、优化数据库结构合理设计数据库表结构避免过多的冗余字段和表关联、使用合适的数据类型。 4、业务方面对于频繁查询的结果可以进行缓存减少数据库查询的次数。 建表的时候、使用索引、sql语句的编写、主从复制读写分离还有一个是如果量比较大的话可以考虑分库分表。
创建表的时候你们是如何优化的呢
这个我们主要参考的阿里出的那个开发手册《嵩山版》就比如在定义字段的时候需要结合字段的内容来选择合适的类型如果是数值的话像tinyint、int 、bigint这些类型要根据实际情况选择。如果是字符串类型也是结合存储的内容来选择char和varchar或者text类型
那在使用索引的时候是如何优化呢
当表中的数据要超过10万以上创建索引 字段是查询比较频繁的字段一般也是像作为查询条件排序字段或分组的字段创建索引 通常创建索引的时候都是使用复合索引来创建一条sql的返回值尽量使用覆盖索引如果字段的区分度不高的话我们也会把它放在组合索引后面的字段。
如果某一个字段的内容较长我们会考虑使用前缀索引来使用【当然并不是所有的字段都要添加索引这个索引的数量也要控制因为添加索引也会导致新增改的速度变慢。】
你平时对sql语句做了哪些优化呢
1、尽量避免在字段开头模糊查询 2、SELECT语句务必指明字段名称不要直接使用select * 3、还有就是要注意SQL语句避免造成索引失效的写法如果是聚合查询尽量用union all代替union union会多一次过滤效率比较低 4、如果是表关联的话尽量使用innerjoin 不要使用用left join right join如必须使用 一定要以小表为驱动。 5、尽量避免进行null值的判断 6、尽量避免在where条件中等号的左侧进行表达式 7、多次插入改为批量插入
事务的特性是什么可以详细说一下吗
ACID分别指的是原子性、一致性、隔离性、持久性 我举个例子 A向B转账500转账成功A扣除500元B增加500元原子操作体现在要么都成功要么都失败
在转账的过程中数据要一致A扣除了500B必须增加500
在转账的过程中隔离性体现在A像B转账不能受其他事务干扰
在转账的过程中持久性体现在事务提交后要把数据持久化可以说是落盘操作
并发事务带来哪些问题 第一是脏读 当一个事务正在访问数据并且对数据进行了修改而这种修改还没有提交到数据库中这时另外一个事务也访问了这个数据因为这个数据是还没有提交的数据那么另外一个事务读到的这个数据是“脏数据”依据“脏数据”所做的操作可能是不正确的。
第二是不可重复读比如在一个事务内多次读同一数据。在这个事务还没有结束时另一个事务也访问该数据。那么在第一个事务中的两次读数据之间由于第二个事务的修改导致第一个事务两次读取的数据可能不太一样。这就发生了在一个事务内两次读到的数据是不一样的情况因此称为不可重复读。
第三是幻读Phantom read幻读与不可重复读类似。它发生在一个事务T1读取了几行数据接着另一个并发事务T2插入了一些数据时。在随后的查询中第一个事务T1就会发现多了一些原本不存在的记录就好像发生了幻觉一样所以称为幻读。
怎么解决这些问题呢MySQL的默认隔离级别是
解决方案是对事务进行隔离 MySQL支持四种隔离级别分别有
第一个是未提交读read uncommitted它解决不了刚才提出的所有问题一般项目中也不用这个。 第二个是读已提交read committed它能解决脏读的问题的但是解决不了不可重复读和幻读。 第三个是可重复读repeatable read它能解决脏读和不可重复读但是解决不了幻读这个也是mysql默认的隔离级别。 第四个是串行化serializable它可以解决刚才提出来的所有问题但是由于让是事务串行执行的性能比较低。所以我们一般使用的都是mysql默认的隔离级别:可重复读。
Binlog、undo log和redo log的区别 其中redo log日志记录的是数据页的物理变化服务宕机可用来同步数据 而undo log 不同它主要记录的是逻辑日志当事务回滚时通过逆操作恢复原来的数据比如我们删除一条数据的时候就会在undo log日志文件中新增一条insert语句如果发生回滚就执行逆操作
Binlog是MySQL用于记录数据库中的所有DDL语句和DML语句的一种二进制日志。它记录了所有对数据库结构和数据的修改操作如INSERT、 UPDATE和DELETE等。 binlog主要用来对数据库进行数据备份、灾难恢复和数据复制等操作。binlog的格式分为基于语句的格式和基于行的格式还可以用来做主从同步。
redo log保证了事务的持久性undo log保证了事务的原子性和一致性。
事务中的隔离性是如何保证的呢(你解释一下MVCC)
事务的隔离性是由锁和mvcc实现的。
其中mvcc的意思是多版本并发控制。指维护一个数据的多个版本使得读写操作没有冲突它的底层实现主要是分为了三个部分第一个是隐藏字段第二个是undo log日志第三个是readView读视图
隐藏字段是指在mysql中给每个表都设置了隐藏字段有一个是trx_id(事务id)记录每一次操作的事务id是自增的另一个字段是roll_pointer(回滚指针)指向上一个版本的事务版本记录地址 undo log主要的作用是记录回滚日志存储老版本数据在内部会形成一个版本链在多个事务并行操作某一行记录记录不同事务修改数据的版本通过roll_pointer指针形成一个链表 readView解决的是一个事务查询选择版本的问题在内部定义了一些匹配规则和当前的一些事务id判断该访问那个版本的数据不同的隔离级别快照读是不一样的最终的访问的结果不一样。如果是rc隔离级别每一次执行快照读时生成ReadView如果是rr隔离级别仅在事务中第一次执行快照读时生成ReadView后续复用
MySQL主从同步原理
MySQL主从复制的核心就是二进制日志(DDL数据定义语言语句和 DML数据操纵语言语句)它的步骤是这样的
第一主库在事务提交时会把数据变更记录在二进制日志文件 Binlog 中。
第二从库读取主库的二进制日志文件 Binlog 写入到从库的中继日志 Relay Log 。
第三从库再执行中继日志中的事件将改变写入它自己的数据。
你们项目用过MySQL的分库分表吗
因为我们都是微服务开发每个微服务对应了一个数据库是根据业务进行拆分的这个其实就是垂直拆分。
并发高分库数据量大分表
那你之前使用过水平分库吗
这个是使用过的我们当时的业务是(xxx)一开始我们也是单库后来这个业务逐渐发展业务量上来的很迅速其中(xx)表已经存放了超过1000万的数据我们做了很多优化也不好使性能依然很慢所以当时就使用了水平分库。
我们一开始先做了3台服务器对应了3个数据库由于库多了需要分片我们当时采用的mycat来作为数据库的中间件。数据都是按照id自增取模的方式来存取的。
当然一开始的时候那些旧数据我们做了一些清洗的工作我们也是按照id取模规则分别存储到了各个数据库中好处就是可以让各个数据库分摊存储和读取的压力解决了我们当时性能的问题。
后记 美好的一天到此结束下次继续努力欲知后续请看下回分解写作不易感谢大家的支持
