（秋招 春招）软件开发 软件测试面试题——数据库部分_数据库多表连接查询中,ybt用于返回包括右表中的所联结字段相等的记录(1)

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

InnoDB：支持事务和行级锁，是innodb的最大特色。行锁大幅度提高了多用户并发操作的新能。但是InnoDB的行锁，只是在WHERE的主键是有效的，非主键的WHERE都会锁全表的。

如果表的读操作远远多于写操作时，并且不需要事务的支持的，可以将 MyIASM 作为数据库引擎的首选。

9.说一下 mysql 的锁

从数据操作的类型（读、写）分：

读锁（共享锁）：针对同一份数据，多个读操作可以同时进行而不会互相影响；

写锁（排它锁）：当前写操作没有完成前，它会阻断其他写锁和读锁。

从对数据操作的颗粒度：

表锁；行锁

表锁（偏读）：偏向MyISAM存储引擎，开销小，加锁快，无死锁，锁定粒度大，发生锁冲突的概率最高，并发最低。

对MyISAM的表的读操作（加读锁），不会阻塞其他进程对同一表的读请求，但会阻塞对同一表的写请求。只有当读锁释放后，才会执行其他进程的写操作。

对MyISAM的表的写操作（加写锁），会阻塞其他进程对同一表的读和写操作，只有当写锁释放后，才会执行其他进程的读写操作。

简而言之，就是读锁会阻塞写，但不会阻塞读，而写锁则会把读和写都阻塞。

行锁（偏写）：偏向InnoDB存储引擎，开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低，并发度也最高。

Innodb存储引擎由于现了行级锁定,虽然在锁定机制的实现方面所带来的性能损耗可能比表级锁定会要更高一些,但是在整体并发处理能力方面要远远优于 MyISAM的表级锁定的当系统并发量较高的时候, Innodb的整体性能和MyISAM相比就会有比较明显的优势了。但是, Innodb的行级锁定同样也有其脆弱的面,当我们使用不当的时候,可能会让Innodb的整体性能表现不仅不能比MyISAM高甚至可能会更差.

10.数据库的索引有了解吗，它的优点及应用场景

索引是排好序的快速查找数据结构。

优势：

类似大学图书馆建书目索引，提高数据检索效率，降低数据库的IO成本；

通过索引列对数据进行排序，降低数据排序成本，降低了CPU的消耗。

劣势：

实际上索引也是一张表，该表保存了主键和索引字段，并指向实体表的记录,所以索引列也是要占用空间的；

虽然索引大大提高了查询速度，同时却会降低更新表的速度,如果对表INSERT,UPDATE和DELETE。因为更新表时，MySQL不仅要不存数据，还要保存一下索引文件每次更新添加了索引列的字段，都会调整因为更新所带来的键值变化后的索引信息。

索引只是提高效率的一个因素，如果你的MySQL有大数据量的表，就需要花时间研究建立优秀的索引，或优化查询语句。

分类：

单值索引：即一个索引只包含单个列，一个表可以有多个单列索引。

唯一索引：索引列的值必须唯一，但允许有空值。

复合索引：即一个索引包含多个列。

应用场景：

哪些情况需要创建索引？

主键自动建立唯一索引；

频繁作为查询的条件的字段应该创建索引；

查询中与其他表关联的字段，外键关系建立索引；

频繁更新的字段不适合创建索引，因为每次更新不单单是更新了记录还会更新索引，加重IO负担；

Where条件里用不到的字段不创建索引；

单键/组合索引的选择问题，who？（在高并发下倾向创建组合索引）；

查询中排序的字段，排序字段若通过索引去访问将大大提高排序的速度；

查询中统计或者分组字段。

哪些情况不需要创建索引？

表记录太少；

经常增删改的表；

数据重复且分布平均的表字段，因此应该只为最经常查询和最经常排序的数据列建立索引。

备注：因为如果你给一列创建了索引，那么对该列进行增删改的时候，都会先访问这一列的索引，若是增，则在这一列的索引内以新填入的这个字段名的值为名创建索引的子集，若是改，则会把原来的删掉，再添入一个以这个字段名的新值为名创建索引的子集，若是删，则会把索引中以这个字段为名的索引的子集删掉，所以，会对增删改的执行减缓速度，所以，若是这张表增删改多而查询较少的话，就不要创建索引了。更新太频繁地字段不适合创建索引。不会出现在where条件中的字段不该建立索引。

11.如何优化查询

i. 全值匹配我最爱

ii. 最佳左前缀法则，如果索引了多例，要遵守最左前缀法则。指的是查询从索引的最左前列开始并且不跳过索引中的列。

iii. 不在索引列上做任何操作（计算、函数、（自动or手动）类型转换），会导致索引失效而转向全表扫描

iv. 存储引擎不能使用索引中范围条件右边的列

v. 尽量使用覆盖索引（只访问索引的查询（索引列和查询列一致）），减少select*

vi. mysql在使用不等于（！=或者<>）的时候无法使用索引会导致全表扫描

vii. is null,is not null 也无法使用索引

viii. like以通配符开头（’$abc…’）mysql索引失效会变成全表扫描操作。问题：解决like’%字符串%'索引不被使用的方法？？可以使用主键索引；使用覆盖索引，查询字段必须是建立覆盖索引字段；当覆盖索引指向的字段是varchar(380)及380以上的字段时，覆盖索引会失效！

ix. 字符串不加单引号索引失效

x. 少用or,用它连接时会索引失效

【优化总结口诀】

全值匹配我最爱，最左前缀要遵守；带头大哥不能死，中间兄弟不能断；

索引列上少计算，范围之后全失效；LIKE百分写最右,覆盖素引不写星；

不等空值还有or，索引失效要少用；VAR引号不可丢,SQL高级也不难!

12.索引有哪些数据结构，分别有什么优缺点

Hash索引结构的特殊性，其检索效率非常高，索引的检索可以一次定位;

B+树索引需要从根节点到枝节点，最后才能访问到叶节点这样多次的IO访问;

那为什么大家不都用Hash索引而还要使用B+树索引呢？

Hash索引

Hash索引仅仅能满足"=",“IN"和”<=>"查询，不能使用范围查询,因为经过相应的Hash算法处理之后的Hash值的大小关系，并不能保证和Hash运算前完全一样；

Hash索引无法被用来避免数据的排序操作，因为Hash值的大小关系并不一定和Hash运算前的键值完全一样；

Hash索引不能利用部分索引键查询，对于组合索引，Hash索引在计算Hash值的时候是组合索引键合并后再一起计算Hash值，而不是单独计算Hash值，所以通过组合索引的前面一个或几个索引键进行查询的时候，Hash索引也无法被利用；

Hash索引在任何时候都不能避免表扫描，由于不同索引键存在相同Hash值，所以即使取满足某个Hash键值的数据的记录条数，也无法从Hash索引中直接完成查询，还是要回表查询数据；

Hash索引遇到大量Hash值相等的情况后性能并不一定就会比B+树索引高。

B+Tree索引

MySQL中，只有HEAP/MEMORY引擎才显示支持Hash索引。

常用的InnoDB引擎中默认使用的是B+树索引，它会实时监控表上索引的使用情况，如果认为建立哈希索引可以提高查询效率，则自动在内存中的“自适应哈希索引缓冲区”建立哈希索引（在InnoDB中默认开启自适应哈希索引），通过观察搜索模式，MySQL会利用index key的前缀建立哈希索引，如果一个表几乎大部分都在缓冲池中，那么建立一个哈希索引能够加快等值查询。

B+树索引和哈希索引的明显区别是：

如果是等值查询，那么哈希索引明显有绝对优势，因为只需要经过一次算法即可找到相应的键值；当然了，这个前提是，键值都是唯一的。如果键值不是唯一的，就需要先找到该键所在位置，然后再根据链表往后扫描，直到找到相应的数据；

如果是范围查询检索，这时候哈希索引就毫无用武之地了，因为原先是有序的键值，经过哈希算法后，有可能变成不连续的了，就没办法再利用索引完成范围查询检索；

同理，哈希索引没办法利用索引完成排序，以及like ‘xxx%’ 这样的部分模糊查询（这种部分模糊查询，其实本质上也是范围查询）；

哈希索引也不支持多列联合索引的最左匹配规则；

B+树索引的关键字检索效率比较平均，不像B树那样波动幅度大，在有大量重复键值情况下，哈希索引的效率也是极低的，因为存在所谓的哈希碰撞问题。

在大多数场景下，都会有范围查询、排序、分组等查询特征，用B+树索引就可以了。

13.gtid方式的主从复制和普通方式的主从复制的区别（优点）

1）普通主从复制：

普通主从复制主要是基于二进制日志文件位置的复制，因此主必须启动二进制日志记录并建立唯一的服务器ID，复制组中的每个服务器都必须配置唯一的服务器ID。如果您省略server-id（或者明确地将其设置为其默认值0），则主设备将拒绝来自从设备的任何连接。

2） GTID 主从：

MySQL 5.6 的新特性之一，全局事务标识符（GTID）是创建的唯一标识符，并与在源（主）服务器上提交的每个事务相关联。此标识符不但是唯一的，而且在给定复制设置中的所有服务器上都是唯一的。所有交易和所有GTID之间都有一对一的映射关系 。它由服务器ID以及事务ID组合而成。这个全局事务ID不仅仅在原始服务器上唯一，在所有存在主从关系 的mysql服务器上也是唯一的。正是因为这样一个特性使得mysql的主从复制变得更加简单，以及数据库一致性更可靠。一个GTID在一个服务器上只执行一次，避免重复执行导致数据混乱或者主从不一致。

基于gtid复制的好处

保证同一个事务在某slave上绝对只执行一次，没有执行过的gtid事务总是会被执行。

不用像传统复制那样保证binlog的坐标准确，因为根本不需要binlog以及坐标。

故障转移到新的master的时候很方便，简化了很多任务。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化的资料的朋友，可以戳这里获取

[外链图片转存中…(img-6GTVIgVL-1715637611150)]

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化的资料的朋友，可以戳这里获取