数据库基础面试第二弹

1. 乐观锁和悲观锁的理解及使用

乐观锁和悲观锁是在并发编程中使用的两种并发控制机制,用于解决多线程或多进程环境下的数据一致性问题。

1. 悲观锁(Pessimistic Locking):
  悲观锁的思想是假设并发访问会导致冲突,因此在访问共享资源之前,悲观锁会将资源锁定,确保其他线程无法修改资源。悲观锁的典型应用是数据库中的行级锁,使用SELECT...FOR

UPDATE语句锁定查询结果。

使用悲观锁的过程如下:

  • 当一个线程要访问共享资源时,它会先尝试获取锁。
  • 如果锁已经被其他线程获取,则当前线程会被阻塞,直到锁被释放。
  • 当线程获得了锁之后,它可以安全地访问共享资源,其他线程无法修改该资源。
  • 当线程完成操作后,释放锁,其他线程可以获取到锁并访问资源。

悲观锁的优点是保证了数据的一致性,但是它的缺点是在高并发环境下,锁的竞争会导致性能下降。

2. 乐观锁(Optimistic Locking):
乐观锁的思想是假设并发访问不会导致冲突,因此在线程访问共享资源之前,不会加锁。相反,乐观锁会在更新资源时,检查在此期间是否有其他线程修改了资源。

使用乐观锁的过程如下:

  • 当一个线程要更新共享资源时,它首先会读取资源的版本号或标识。
  • 在进行更新之前,线程会检查资源的版本号是否发生了变化。
  • 如果资源的版本号没有变化,线程会更新资源,并更新版本号。
  • 如果资源的版本号发生了变化,表示有其他线程已经修改过资源,当前线程的操作可能会产生冲突。
  • 在发生冲突时,可以选择进行回滚操作或者重试整个过程。

  乐观锁的优点是在无冲突的情况下,不需要进行加锁操作,从而提高了并发性能。然而,如果冲突频繁发生,会导致大量的回滚和重试操作,降低性能。

总的来说,悲观锁适合对于冲突频繁发生的场景,可以保证数据的一致性;而乐观锁适合对于冲突较少发生的场景,可以提高并发性能。选择使用哪种锁要根据具体的应用场景和性能需求进行

权衡。

乐观锁与悲观锁例子:

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

SELECT stock FROM inventory WHERE product_id =  FOR UPDATE;

```

在上述代码中,使用 `FOR UPDATE` 子句来锁定库存行,确保其他并发操作无法修改库存数量。

START TRANSACTION;  -- 开启事务

SELECT stock FROM inventory WHERE product_id =  FOR UPDATE;  -- 获取并锁定库存行

-- 检查库存是否足够

IF stock >=  THEN

    UPDATE inventory SET stock = stock -  WHERE product_id = ;  -- 更新库存

    COMMIT;  -- 提交事务

    -- 库存更新成功,继续后续操作

ELSE

    ROLLBACK;  -- 回滚事务

    -- 库存不足,处理相应逻辑,如提示用户库存不足

END IF;

```

2. 聚集索引和非聚集索引的区别:

聚集索引(Clustered Index)和非聚集索引(Non-clustered Index)是数据库中常用的索引类型,它们在索引的组织方式和数据访问方式上存在一些区别。

聚集索引:

  • 聚集索引定义了数据表的物理排序方式。每个表只能有一个聚集索引,它决定了表中数据行的物理存储顺序。如果一个表有聚集索引,那么数据行将按照聚集索引的排序顺序存储在磁盘上。
  • 聚集索引的叶子节点包含了整个数据行的信息,因此当使用聚集索引进行数据查询时,可以直接通过索引找到所需的数据行。
  • 由于每个表只能有一个聚集索引,一般情况下,聚集索引会选择主键作为索引键。

非聚集索引:

  • 非聚集索引是基于表中的列创建的索引,它存储了索引键和指向对应数据行的指针。一个表可以有多个非聚集索引。
  • 非聚集索引的叶子节点不包含完整的数据行,而是包含了索引键和指向对应数据行的指针。当使用非聚集索引进行数据查询时,首先通过索引找到对应的数据行的指针,然后再通过指针获取完整的数据行。
  • 非聚集索引可以加快数据的查找速度,尤其是在涉及到过滤和排序的查询操作中。

区别总结:

  • 聚集索引决定了数据行的物理存储顺序,而非聚集索引只是提供了数据行的逻辑顺序。
  • 聚集索引的叶子节点包含完整的数据行,而非聚集索引的叶子节点只包含索引键和指向数据行的指针。
  • 一个表只能有一个聚集索引,但可以有多个非聚集索引。

在实际使用中,根据具体的查询需求和数据特点,可以根据需要选择适当的索引类型,以提高数据库的查询性能和数据访问效率。

创建聚集索引和非聚集索引的示例:

1

2

3

4

5

6

7

8

CREATE CLUSTERED INDEX idx_Orders_OrderID ON Orders (OrderID);

上述语句创建了一个名为 "idx_Orders_OrderID" 的聚集索引,它基于 "Orders" 表的 "OrderID" 列。

CREATE NONCLUSTERED INDEX idx_Customers_Email ON Customers (Email);

上述语句创建了一个名为 "idx_Customers_Email" 的非聚集索引,它基于 "Customers" 表的 "Email" 列。

3.  为什么索引用B+树,而不用普通的二叉树

  1. 磁盘访问效率: B+树是一种多叉树,它具有分支因子(即子节点的最大数量)更高的特点。相比之下,二叉树每个节点只有两个子节点。在磁盘上,每次读取或写入的开销是非常昂贵的操作,因此减少磁盘访问次数可以提高索引的性能。B+树的高分支因子意味着在相同高度的情况下,它可以存储更多的键值对,减少了磁盘I/O次数。而二叉树的分支因子较低,可能需要更多的磁盘访问来定位目标数据。

  2. 顺序访问性能: B+树的叶子节点使用链表连接起来,形成一个有序的链表结构。这使得范围查询和顺序访问非常高效。例如,在数据库中,如果需要查询某个范围内的数据(如按时间排序的记录),B+树可以利用有序的叶子节点链表进行快速定位和遍历。而在二叉树中,由于没有有序链表结构,需要进行中序遍历才能获取有序数据,这会增加额外的开销。

  3. 索引的稳定性: B+树作为一种自平衡树结构,对于插入和删除操作具有较好的稳定性。当在B+树中进行插入或删除操作时,只需要对树的部分节点进行修改,而不需要像二叉树那样进行全局的重新平衡。这种特性使得B+树更适合于高效地维护索引结构。

  4. 缓存利用: 现代计算机系统通常都有层次化的缓存结构,其中内存缓存(如CPU缓存)的访问速度远高于磁盘。B+树由于具有高的分支因子,可以存储更多的键值对在每个节点中,因此在搜索过程中可以利用更好地利用缓存,减少内存访问的次数。而二叉树由于分支因子较低,可能需要更多的内存访问来获取相同数量的键值对。

综上所述,B+树相对于普通的二叉树具有更好的磁盘访问效率、顺序访问性能、稳定性和缓存利用,使其成为了广泛应用于索引结构的一种理想选择。

4. Hash索引和B+树索引区别:

Hash索引和B+树索引是两种常见的索引结构,它们在实现原理、适用场景和性能方面存在一些区别。

实现原理:

  • Hash索引: Hash索引使用散列函数将索引键转换为存储位置的散列码。散列码经过映射后直接指向存储数据的位置,因此在访问数据时具有固定的时间复杂度(O(1))。
  • B+树索引: B+树索引是一种多叉树结构,具有根节点、内部节点和叶子节点。每个节点包含多个键值对,通过比较键值来导航到下一个节点。B+树索引通过在树中进行有序查找来定位数据,因此访问时间的复杂度与树的高度相关(通常为O(log n))。

适用场景:

  • Hash索引: Hash索引适用于等值查询,即根据精确的索引键值查找数据。它对于相等比较非常快速,但不适用于范围查询或排序操作。
  • B+树索引: B+树索引适用于范围查询、排序操作和模糊查询。由于B+树的有序性,它可以支持按顺序遍历数据和快速定位范围内的数据。

数据访问性能:

  • Hash索引: Hash索引具有固定的访问时间复杂度(O(1)),因此在等值查询方面非常高效。但是,由于散列函数的散列冲突可能导致链表的形成,这可能会影响性能,尤其是在高负载情况下。
  • B+树索引: B+树索引的访问时间复杂度与树的高度相关,通常为O(log n)。尽管每次访问可能需要多次磁盘I/O,但B+树索引在范围查询和顺序访问方面具有良好的性能。

存储空间利用:

  • Hash索引: Hash索引通常需要预先分配足够的散列槽位,以防止散列冲突。这可能会导致存储空间的浪费,尤其是在数据分布不均匀的情况下。
  • B+树索引: B+树索引在内部节点上存储键值对和子节点指针,而叶子节点上存储键值对和指向数据的指针。相比之下,B+树索引通常可以更好地利用存储空间。

综上所述,Hash索引适用于等值查询,具有固定的访问时间,但不支持范围查询和排序操作。B+树索引适用于范围查询、排序操作和模糊查询,具有较好的顺序访问性能和稳定性,但访问时间复杂度与树的高度相关。选择使用哪种索引结构取决于具体的应用需求和数据访问模式。

5. 索引不适合哪些场景以及有哪些优缺点:

索引在大多数情况下可以显著提高数据库查询的性能,但并不适合所有场景。以下是索引不适合的一些场景以及索引的一些优点和缺点:

索引不适合的场景:

  1. 低基数列: 当列中的唯一值较少时,例如性别列只有两个可能的取值(男或女),建立索引可能不会带来明显的性能提升。在这种情况下,扫描整个表的代价可能比使用索引更低。
  2. 频繁更新的列: 如果一个列经常被更新,索引的维护成本会很高。每次更新列的值时,可能需要更新索引数据结构,这会增加写操作的开销。频繁更新的列可能会导致索引失去效益,甚至降低性能。
  3. 小表: 对于非常小的表,建立索引可能没有太大意义。在小表中,全表扫描的代价可能相对较低,而使用索引进行查找可能会增加额外的开销。

索引的优点:

  1. 加速查询: 索引可以大大加速查询操作,特别是在大型表中。通过使用索引,数据库引擎可以快速定位满足查询条件的数据行,减少了全表扫描的需要。
  2. 支持排序和聚合操作: 索引可以使排序和聚合操作更高效。通过使用有序索引,数据库引擎可以避免对整个表进行排序,从而提高操作的性能。
  3. 优化连接操作: 对于连接操作(如JOIN),索引可以帮助加速数据的查找和匹配,减少连接操作的成本。

索引的缺点:

  1. 占用存储空间: 索引需要占用额外的存储空间。对于大型表和多个索引的情况,索引可能占据相当大的存储空间。
  2. 增加写操作的开销: 当插入、更新或删除数据时,索引需要进行相应的维护操作,这会增加写操作的开销。如果频繁进行写操作,索引的维护成本可能会成为性能瓶颈。
  3. 索引选择和调优困难: 在设计索引时,需要根据实际查询模式和数据访问模式进行权衡和选择。选择不当的索引或过多的索引可能会导致性能下降,而调优索引可能需要经验和测试。

综上所述,索引在大多数情况下是数据库性能优化的重要工具,但在某些场景下可能不适用或需要谨慎使用。正确的索引设计和调优可以提高查询性能,而错误的使用可能会导致额外的开销和性能下降。

6.最左前缀匹配原则是什么

最左前缀匹配原则是数据库索引设计中的一个重要原则,它指出在使用复合索引(Composite Index)时,索引将按照索引键的顺序进行匹配和检索,并且只能利用索引的最左前缀来进行匹配。

具体来说,如果一个复合索引包含多个列(例如(A, B, C)),那么在查询时,最左前缀匹配原则要求查询条件必须从索引的最左侧开始,并且连续地匹配到索引的某个位置为止。也就是说,查询条件可以是(A)、(A, B)或者(A, B, C),但不能是(B)、(C)或者(B, C)。

遵循最左前缀匹配原则的好处是可以最大程度地利用索引的有序性,提高查询的效率。由于索引按照键的顺序存储,因此在查询时只需定位到满足最左前缀条件的索引位置,而不需要扫描整个索引。

举个例子,假设有一个复合索引 (A, B, C),如果查询条件是(A = 1),那么索引可以用于加速查询,因为最左前缀 (A) 匹配成功。但如果查询条件是(B = 2),即使索引中包含了列 B,也无法利用索引进行加速,因为最左前缀不匹配。

需要注意的是,最左前缀匹配原则并不意味着只有最左侧的列可以使用索引,而是强调索引的有序性和连续性。在某些情况下,可以通过创建单列索引或调整索引顺序来更好地利用索引。

最后感谢每一个认真阅读我文章的人,礼尚往来总是要有的,虽然不是什么很值钱的东西,如果你用得到的话可以直接拿走:

这些资料,对于【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴上万个测试工程师们走过最艰难的路程,希望也能帮助到你!

你可能感兴趣的:(软件测试,数据库,面试,java,软件测试,自动化测试,功能测试,程序人生)