JAVA面试部分——后端-数据库前篇

5.1 mysql中char和varchar的区别，varchar（100）中的一百的含义，能存放多少汉字？

在MySQL中，CHAR和VARCHAR都是用来存储字符串的数据类型，但它们之间存在一些主要区别。

1. 存储方式：CHAR是固定长度的，而VARCHAR是可变长度的。这意味着CHAR会根据你设定的长度存储字符串，即使实际长度小于设定值，而VARCHAR只存储实际字符数，不会额外占用空间。

2. 空间占用：由于CHAR是固定长度，所以它在存储时会按照设定的长度进行分配，例如如果你设定长度为20，即使实际存储的字符串只有5个字符，也会占用20个字符的空间。而VARCHAR是按实际字符数来分配空间，所以它只会占用实际字符数所占的空间。

3. 处理效率：因为CHAR是固定长度，所以在处理效率上通常会比VARCHAR更快。如果你的字符串长度固定，或者你知道它不会超过某个特定长度，使用CHAR可能会更有效。

总的来说，选择CHAR还是VARCHAR主要取决于你的数据和需求。如果你的字符串长度基本固定，或者长度很短，使用CHAR可能更合适。如果你的字符串长度变化较大，或者需要存储大量数据，使用VARCHAR可能更节省空间和性能。

5.2 Mysql：左查询的特点，左右查询的区别

在 MySQL 中，左查询（LEFT JOIN）和右查询（RIGHT JOIN）是 SQL 中用于连接表的不同方式。

左查询（LEFT JOIN）的特点：

• 左查询会返回左表中的所有记录，即使右表中没有匹配的记录也会显示左表中的数据。

• 如果左表中的记录在右表中没有匹配的数据，对应的右表列则会显示为 NULL。

• 左查询语法：SELECT * FROM 左表 LEFT JOIN 右表 ON 连接条件

左查询与右查询的区别：

• 左查询以左表为基准，返回左表中的所有记录，即使右表中没有匹配的记录。

• 右查询（RIGHT JOIN）以右表为基准，返回右表中的所有记录，即使左表中没有匹配的记录。不过在实践中，右查询并不常用，可以使用左查询代替来达到相同的效果。

• 如果使用左查询和右查询的表顺序颠倒，则可以达到相同的效果，只是基准表和被关联表会颠倒，结果会有所不同。

通常情况下，左查询（LEFT JOIN）更为常见和实用，因为它能够保留左表中的所有记录，即使右表中没有匹配的数据，依然可以显示出左表的信息，并将未匹配的列显示为 NULL。

5.3 where和having的区别

WHERE和HAVING在数据库查询中都起着重要的作用，但它们在使用上有一些区别：

1. 使用的语句不同：WHERE用于SELECT语句中，而HAVING通常用于SELECT语句的GROUP BY子句中。

2. 搜索条件的位置：WHERE在执行语句前进行搜索条件的筛选，而HAVING是在执行语句后进行筛选，因此WHERE先执行，HAVING后执行。

3. 表达式：WHERE子句的表达式只能与单个列比较，而HAVING可以与集合函数或表达式比较。

4. 聚合函数的使用：WHERE不能使用聚合函数，因为聚合函数通常在HAVING子句中使用。

5. 子句的限制：WHERE子句不能与GROUP BY子句一起使用，但HAVING可以。同时，HAVING子句不能独立使用，必须与GROUP BY子句一起使用。

总之，WHERE和HAVING在数据库查询中都起着筛选数据的作用，它们的使用取决于具体的需求和使用的语句。

5.4 数据库中, drop、delete与trunCate的区别?

在数据库中，DROP、DELETE 和 TRUNCATE 是用于移除数据或对象的不同命令，它们有以下区别：

1. DROP：

   • DROP 用于删除数据库中的对象，如表、视图、索引等。

   • DROP 删除的是整个对象及其定义，包括对象本身以及其相关的数据、索引、触发器等，是一个 DDL（数据定义语言）命令。

   • 举例：DROP TABLE table_name;

2. DELETE：

   • DELETE 用于删除表中的记录（行）。

   • DELETE 删除的是表中的数据行，但保留表的结构，不会删除表本身。

   • DELETE 是一个 DML（数据操作语言）命令，可以带有 WHERE 子句，用于指定删除的条件。

   • 举例：DELETE FROM table_name WHERE condition;

3. TRUNCATE：

   • TRUNCATE 用于快速删除表中的所有记录。

   • TRUNCATE 与 DELETE 的不同之处在于，TRUNCATE 删除表中的所有数据行，但保留表的结构，不激活触发器，速度通常比 DELETE 更快。

   • TRUNCATE 是一个 DDL（数据定义语言）命令，无法带有 WHERE 子句。

   • 举例：TRUNCATE TABLE table_name;

主要区别在于：

• DROP 用于删除整个对象及其定义。

• DELETE 用于删除表中的数据行。

• TRUNCATE 用于快速删除表中的所有数据行。

5.5 sql执行顺序

SQL 的执行顺序通常按照以下顺序进行：

1. FROM：

   • SQL 语句的第一个关键字是 FROM，它指定要查询的表。

   • 在执行时，首先从 FROM 子句中指定的表中获取数据。

2. WHERE：

   • WHERE 子句用于筛选满足特定条件的行。

   • 在 WHERE 子句中，通过条件过滤出满足条件的行。

3. GROUP BY：

   • GROUP BY 子句用于按指定列对结果进行分组。

   • 在这一步，将符合条件的行分组。

4. HAVING：

   • HAVING 子句用于筛选分组后的数据。

   • 与 WHERE 类似，但 HAVING 是在分组后对组进行过滤。

5. SELECT：

   • SELECT 用于选择要查询的列。

   • 查询结果根据指定的列生成。

6. ORDER BY：

   • ORDER BY 子句用于对结果进行排序。

   • 根据指定的列对结果进行排序。

以上是一般情况下 SQL 语句的执行顺序。在实际应用中，也有一些特例，例如子查询、连接查询等可能会改变执行顺序。

5.6 索引的数据结构有哪些

在数据库中，常见的索引数据结构主要有以下几种：

1. B-Tree 索引：

   • 最常见的索引类型之一，适用于大多数数据库系统。

   • B-Tree 索引是一种平衡树结构，它能够快速定位到叶节点，从而实现高效的查询。

2. Hash 索引：

   • 使用哈希表结构实现的索引类型。

   • Hash 索引适用于等值查询，但对范围查询的效率较低。

   • 常用于内存数据库，对于存储在磁盘上的数据库来说，哈希索引的效果可能不如 B-Tree 索引。

3. 全文索引：

   • 用于对文本内容进行搜索的索引类型。

   • 全文索引支持关键字搜索、模糊搜索等。

4. R-Tree 索引：

   • 主要用于空间数据（如地理空间数据）的索引。

   • R-Tree 索引适合用于多维数据的范围查询和空间查询。

5. 位图索引：

   • 使用位图数据结构实现的一种索引类型。

   • 位图索引适用于具有少量不同值的列，对于频繁更新的列不太适用。

每种索引结构都有其特定的应用场景和优劣势，选择合适的索引类型需要考虑到数据库中数据的特点以及查询需求。

5.7 索引的特点？

索引在数据库中有以下特点：

1. 加速检索：索引能够加快数据的检索速度，特别是在大型数据集上进行查询时，可以大幅提升查询效率。

2. 提高性能：通过索引，数据库系统可以更快地定位到符合查询条件的数据行，减少了全表扫描的需求，从而提高了数据库的性能。

3. 唯一性约束：索引可以唯一标识某列或某些列的值，实现唯一性约束，保证数据的唯一性。

4. 支持排序：某些类型的索引可以帮助查询结果按照指定顺序返回，提供排序功能。

5. 占用存储空间：索引需要额外的存储空间来存储索引数据结构，这可能会增加数据库的存储开销。

6. 影响写操作效率：索引的存在会影响写操作（插入、更新、删除）的效率，因为每次写操作都需要维护索引结构。

7. 选择合适的列：选择适当的列创建索引是很重要的，过多或不必要的索引会增加系统负担并占用额外的存储空间。

8. 数据更新开销：对于频繁更新的列，索引会增加数据更新的开销，因为每次更新都需要更新索引。

因此，在设计索引时需要考虑到查询频率、数据特点和业务需求，合理地创建索引以平衡查询效率和写操作效率。

5.8 说一下InnDB 的索引结构？

InnoDB 存储引擎的索引结构主要基于 B+Tree（Balanced Tree，平衡树）。

具体来说，InnoDB 的索引结构有以下特点：

1. 聚簇索引（Clustered Index）：

   • InnoDB 使用聚簇索引，这意味着索引本身就是数据的存储结构。

   • 聚簇索引将数据存储在索引的叶子节点上，因此叶子节点中存储了完整的数据行。

   • 在主键上创建的索引就是聚簇索引，默认情况下，如果没有显式指定主键，则会使用一个名为 PRIMARY 的隐藏字段作为主键。

2. 辅助索引（Secondary Index）：

   • InnoDB 也支持辅助索引，不同于聚簇索引，辅助索引的叶子节点中存储的是主键值，而非完整的数据行。

   • 通过辅助索引可以快速定位到对应的主键值，再通过主键值找到完整的数据行。

3. B+Tree 结构：

   • InnoDB 的索引采用 B+Tree 结构，B+Tree 是一种平衡树结构，能够保持树的平衡并提供高效的检索性能。

   • B+Tree 的叶子节点形成一个有序链表，可以很快地进行范围查询和顺序遍历。

4. 自适应哈希索引：

   • InnoDB 存储引擎还提供自适应哈希索引，在特定情况下会自动创建。

   • 自适应哈希索引用于加速某些查询，主要针对一些热点数据。

InnoDB 的索引结构使得它能够快速定位和检索数据，同时支持事务处理和并发操作，使得它成为许多 MySQL 数据库中首选的存储引擎。

5.8 如何判断一个sql有没有做索引？

EXPLAIN执行情况 关键字加到sql语句前。

5.9 什么时候索引失效，为什么失效？

1. 列类型不匹配：如果查询中使用的列类型与索引列的类型不匹配，例如在字符串类型的列上使用了数值比较，那么索引将无法正常工作。

2. 函数操作：如果在查询中使用了函数操作，例如在索引列上使用了函数操作或者使用了自定义函数，那么索引也会失效。

3. 索引列值为空：如果查询条件中使用了IS NULL或者IS NOT NULL操作，而索引列上存在NULL值，那么索引将无法正常工作。

4. 运算符不匹配：如果查询中使用的运算符与索引定义的不同，例如在索引列上使用了LIKE查询，而索引的数据类型为数字或日期类型，那么索引将无法正常工作。

5. 类型转换：如果查询中使用了某种类型的转换，例如在查询中将字符串转换为数字，那么索引将无法正常工作。

6. 表达式：如果查询条件中有复杂的表达式，那么可能无法使用索引。

7. NULL值：如果索引中包含NULL值，那么在查询时使用索引的列时，如果查询条件使用了NULL，索引将不再有效。

8. OR语句：当使用OR语句时，索引可能会失效。

5.10 回表你有没有了解？

回表是一种数据库查询优化技术，用于减少在数据库查询中执行多次查询的次数，从而提高查询效率。

回表是在使用覆盖索引或组合索引时，当查询的某个字段不在索引中而下一个字段有索引时，使用回表技术可以将不在索引中的字段的结果进行回表查询。通过这种方式，只需要执行一次查询就能获取到所有需要的数据，而不需要执行多次查询。

回表技术适用于以下情况：

1. 查询的某个字段不在索引中，但下一个字段有索引。

2. 查询的某个字段没有索引，但该字段是组合索引的一部分。

使用回表技术可以提高查询效率，减少查询次数，但需要注意的是，回表操作可能会增加查询的I/O开销，因此需要根据具体情况选择是否使用回表技术。

5.11 什么是索引回表，如何避免？

索引回表是一种数据库查询策略，用于处理在数据库中查询某个特定值但只知道其部分或模糊的信息的情况。通过先定位主键值，然后根据主键值扫描整行数据，以找到具体的行记录。

避免索引回表的方法是使用覆盖索引。覆盖索引是一种特殊类型的索引，其中包含了查询所需的所有数据，因此无需回表获取数据。将被查询的字段建立到联合索引里去，这样就能避免索引回表。

5.12 sql 优化

SQL 优化是针对数据库查询语句的性能和效率进行提升的一系列技术和方法。这些优化技巧可以帮助数据库更高效地执行查询，减少资源消耗，并加快查询速度。以下是一些常见的 SQL 优化技巧：

1. 合理使用索引：

   • 为频繁查询的列创建合适的索引，但不要过度索引，因为过多索引会增加写操作的开销。

   • 考虑联合索引以支持多列查询。

2. 避免全表扫描：

   • 尽量避免使用 SELECT * 来查询全部列，只选择需要的列。

   • 使用 WHERE 子句和条件语句来缩小检索范围。

3. 优化查询语句：

   • 编写简洁而高效的 SQL 查询语句，避免复杂的嵌套查询和不必要的子查询。

   • 考虑使用 JOIN 替代子查询，合理利用 JOIN 的不同类型。

4. 避免使用函数：

   • 避免在 WHERE 子句中对列进行函数操作，因为这会导致数据库无法使用索引。

   • 尽量在应用层处理数据，而不是在数据库层使用函数操作。

5. 合理使用缓存：

   • 对于频繁访问但不经常变化的数据，考虑使用缓存来提高访问速度。

6. 定期优化和分析：

   • 定期分析数据库性能，查看慢查询日志，找出潜在的性能瓶颈。

   • 根据数据库的使用情况和特点，定期进行性能优化，包括索引优化、表结构调整等。

7. 分区表：

   • 对大表进行分区，可以加快查询速度，特别是对于历史数据的查询。

8. 避免使用 SELECT DISTINCT：

   • 如果可能的话，尽量避免使用 SELECT DISTINCT，尝试使用其他方法去重。

9. 合理的数据库设计：

   • 合理的数据库表设计能够避免一些性能问题，如范式设计、表字段的合理规划等。

SQL 优化需要根据具体的数据库、表结构和业务需求来制定，不同情况下需要采用不同的优化手段。同时，进行优化时需要谨慎，充分测试和评估优化后的性能变化，确保优化方案有效且不会带来其他问题。

5.13 数据库优化

数据库优化是提高数据库性能和效率的过程，主要目标是通过合理的设计、配置和调整，提升数据库的查询速度、响应时间和吞吐量。这包括多个方面的工作：

1. 索引优化：

   • 设计合适的索引以加快查询速度，但不要过度索引。

   • 定期检查索引的使用情况，移除不必要的或者很少使用的索引。

2. 查询优化：

   • 编写高效的 SQL 查询语句，避免全表扫描和性能低下的查询。

   • 避免在 WHERE 子句中对字段进行函数操作，以允许数据库使用索引。

3. 表结构优化：

   • 优化表的设计，合理拆分或合并表，避免过度规范化或反规范化。

   • 使用合适的数据类型来减少存储空间和提高性能。

4. 硬件优化：

   • 针对大型数据库，考虑使用更快速、更高性能的硬件，如 SSD 硬盘、更多内存等。

5. 缓存优化：

   • 利用缓存技术，例如使用缓存服务器、内存数据库或应用程序级缓存，减少对数据库的访问。

6. 连接池优化：

   • 合理配置连接池参数，以提高连接的复用率，减少连接创建和销毁的开销。

7. 性能监控和调优：

   • 使用数据库性能监控工具，如慢查询日志、系统监控等，及时发现和解决性能瓶颈。

8. 分区表和分库分表：

   • 对于大型数据表，考虑使用分区表或分库分表技术，提高查询性能和管理效率。

9. 定期备份和维护：

   • 定期进行数据库备份和恢复测试，保证数据的安全性和可靠性。

10. 版本升级和优化器更新：

    • 定期升级数据库版本，以获得性能优化和 bug 修复。

数据库优化需要根据具体的应用场景和需求进行，不同的数据库有不同的优化方法，需要不断地进行测试和评估，确保优化的效果和稳定性。同时，数据库优化是一个持续不断的过程，随着业务的发展和变化，需要不断地优化和调整以适应新的需求。

5.14 数据库事务概念？

数据库事务是一系列数据库操作的集合，这些操作要么全部成功执行（提交），要么全部失败并回滚（撤销），保证数据库的一致性和完整性。

事务具有以下四个特性，通常简称为 ACID 特性：

1. 原子性（Atomicity）：事务中的所有操作要么全部执行成功，要么全部失败回滚，不允许部分操作成功而部分操作失败。

2. 一致性（Consistency）：事务在执行前后，数据库从一个一致的状态转换到另一个一致的状态，不会破坏数据库的完整性约束。

3. 隔离性（Isolation）：事务之间相互隔离，各个事务对彼此之间的操作是相互独立的，不会互相影响。

4. 持久性（Durability）：一旦事务被提交，其对数据库的修改将是永久性的，即使系统发生故障也不会丢失。

事务的出现主要是为了解决并发访问数据库时的数据一致性问题。通过对事务的管理和控制，数据库可以保证多个用户同时访问数据库时的数据一致性和完整性。数据库事务通常由 BEGIN TRANSACTION（或者 START TRANSACTION）开始，然后由 COMMIT 提交或者 ROLLBACK 回滚来结束。

5.15 事务的隔离级别？

事务的隔离级别主要有四种，由低到高分别为Read Uncommitted、Read Committed、Repeatable Read和Serializable。这些级别主要用来解决并发操作时可能出现的数据读取问题和数据更新问题。

1. Read Uncommitted（读未提交）：一个事务可以读取另一个未提交事务的数据。这种隔离级别可能导致脏读问题，即一个事务读取了另一个事务修改但还未提交的数据。

2. Read Committed（读已提交）：一个事务要等到另一个事务提交后才能读取数据。这种隔离级别解决了脏读问题，但可能导致不可重复读问题，即一个事务在多次读取同一数据时，由于另一个事务的修改导致其读取到的数据不同。

3. Repeatable Read（可重复读）：该级别下，事务在开始时锁定一些行，在事务结束之前，这些行不会被其他事务所更改。这样就可以避免不可重复读的问题。然而，如果其他事务尝试修改或删除被锁定的行，将会被阻塞直到当前事务完成。

4. Serializable（序列化）：这是最高的隔离级别，事务串行化顺序执行，避免了脏读、不可重复读和幻读问题。但这种级别效率低下，比较消耗数据库性能。

请注意，对于不同的事务数据库系统，对这四种隔离级别的支持可能有所不同。在使用时需要根据具体的需求和性能要求来选择合适的隔离级别。文章来源地址https://www.toymoban.com/news/detail-792253.html

到了这里，关于JAVA面试部分——后端-数据库前篇的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！