MySQL

事务隔离级别有哪几种？

MySQL支持 4 种事务隔离级别，这些隔离级别定义了事务之间的可见性和并发控制方式。

• READ UNCOMMITTED（读未提交）：这是最低的隔离级别。在该级别下，事务可以读取未提交事务的数据，可能会导致脏读、不可重复读和幻像读问题。一般情况下不建议使用此级别。
• READ COMMITTED（读已提交）：在这个级别下，事务只能读取已经提交的数据，可以避免脏读，但仍可能出现不可重复读和幻像读问题。
• REPEATABLE READ（可重复读）：这是MySQL默认的隔离级别。在该级别下，事务能够读取和锁定事务开始时的数据快照，从而避免了脏读和不可重复读。但幻像读问题仍然可能出现。
• SERIALIZABLE（串行化）：这是最高的隔离级别。在该级别下，事务完全隔离，不会发生脏读、不可重复读和幻像读。但它也是最慢的级别，因为它会在读取数据时对数据进行锁定，阻止其他事务的并发操作。
  

如果不考虑隔离性，可能会引发如下问题：

• 脏读（Dirty Read）：脏读指的是一个事务读取了另一个事务尚未提交的数据。如果另一个事务在最终没有提交的情况下回滚了，那么读取的数据就是无效的。脏读可能导致不一致的数据和不准确的查询结果。
• 幻读（Phantom Read）：幻读是指在同一事务内的两次查询中，第二次查询发现了更多的数据行，这是由于在两次查询之间有另一个事务插入了新的数据行。幻读与不可重复读不同之处在于，不可重复读是由于已提交事务的更新导致的数据不一致，而幻读是由于新插入的数据导致的数据不一致。
• 不可重复读（Non-Repeatable Read）：不可重复读是指在同一事务内的两次查询中，第二次查询发现了不同的数据。这是由于在两次查询之间有另一个事务修改了数据并提交了事务。不可重复读可能导致事务内部的一致性问题，因为事务在两次查询之间看到了不一致的数据。

MySQL的常用的存储引擎有哪些？特点是什么，分别适合什么场景下使用

MySQL的表类型由存储引擎决定，主要包括：myisam、innodb、memory等

• innodb 存储引擎：支持事务和外键，行级锁
• myisam 存储引擎：不支持事务和外键，支持全文搜索，添加速度快，表级锁
• memory 存储引擎：不支持事务和外键，表级锁，数据存储在内存中（关闭了MySQL服务，数据丢失，但是表结构还在）， 执行速度很快（没有IO读写），默认支持索引（hash表）
  

如何选择存储引擎

1. 如果不需要事务，读多写少的业务，选择 myisam。
2. 如果需要支持事务和数据完整性和外键约束等要求，选择 innodb。
3. memory存储引擎将表数据存储在内存中，因此速度非常快。但它的数据是临时的，重启MySQL后数据会丢失，适用于临时数据存储或缓存。（经典用法：用户的在线状态）

MySQL有数据缓存吗？原理是怎么样的？

MySQL具有数据缓存机制，其中包括查询缓存和innodb缓冲池（Buffer Pool）。
MySQL的数据库缓存机制默认是开启的，但不同部分的缓存可以根据配置进行调整。

不同存储引擎对数据缓存的支持程序可能不同。一般来说，innodb存储引擎具有较强的缓冲机制，而其他存储引擎比如myisam也支持一些缓存机制。

• innodb缓冲池：innodb存储引擎默认启用了缓冲池，用于缓存表数据和索引。可以通过配置innodb_buffer_pool_size参数来控制缓冲池的大小。
  • 原理：用于存储数据库表数据和索引的内存缓存区域。当查询需要访问表数据或索引时，MySQL会先检查缓冲池中是否有相应的数据页。如果有，将从内存中获取数据，而不是从磁盘读取，以提高查询性能。
  • 作用：提高查询性能，因为内存访问比磁盘访问快的多。可以显著减少 IO 操作。特别是在大型数据库中。缓冲池还可以存储最常用的数据，以减少磁盘访问的需求。
  • 数据一致性保护措施：默认情况下，innodb存储引擎已经采取了一些措施来确保数据的一致性。
• 查询缓存：在MySQL8.0 版本已被弃用。因为它在高并发和写入频繁的数据库中可能引发性能问题。在较早的MySQL版本中，可以通过设置query_cache_type和query_cache_size参数来启用和配置查询缓存。
  • 原理：是MySQL的查询结果缓存，会存储已经执行过的查询的结果集。当一个查询执行时，MySQL会检查查询缓存是否已经有了相同查询的结果，如果有，就直接返回缓存中的结果，而不执行实际的查询。以减少查询的执行时间，提高性能。
  • 问题：可以提供性能，但存在限制。比如：如果数据库中的数据发生了变化，查询缓存可能导致脏数据的返回。因此，在高并发、频繁写入的数据库中不太适用。
• 键缓存：MySQL支持键缓存，用于缓存表的索引。可以使用key_buffer_size参数来配置键缓存的大小。

如何避免缓存带来的脏数据问题？

1. 合理配置缓冲区大小：确保为缓冲池和其他缓冲区分配合理的大小，以适应数据库的工作负载和可用内存。不要过分依赖缓存，否则可能导致脏数据问题。
2. 使用事务隔离级别：通过配置适当的事务隔离级别，减少脏读和不可重复读的可能性，从而提高数据一致性。
3. 定期刷新缓存：在高并发的写入场景中，定期刷新缓存可以确保数据的一致性。使用innodb_flush_method等参数来配置刷新策略。
4. 监控性能和缓存命中率：通过监视数据库性能和缓存命中率，及时发现性能问题和缓存引起的脏数据问题。

InnoDB的缓冲池默认是开启的吗？基本原理是什么？会有脏数据的问题吗？

InnoDB的缓冲池是默认启用的，而且在大多数情况下，使用默认配置的InnoDB缓冲池不会导致脏数据问题。
默认情况下，InnoDB存储引擎已经采取了一些措施来确保数据的一致性，即使在默认的事务隔离级别下也应该是安全的。

以下是一些有关InnoDB缓冲池和脏数据的重要考虑因素：

1. 默认配置：默认情况下，InnoDB使用行级锁和可重复读（REPEATABLE READ）的事务隔离级别。这意味着InnoDB在默认情况下已经配置为尽量减少脏数据的风险。
2. 缓冲池管理：InnoDB缓冲池会根据需要自动管理，它会将频繁访问的数据页加载到内存中，并根据LRU（最近最少使用）算法来替换不常使用的数据页。这有助于提高性能，并减少脏数据的可能性。
3. 脏数据问题：脏数据问题通常出现在高并发写入的情况下，当多个事务同时修改相同数据时，可能会导致脏数据。但默认的InnoDB配置和事务隔离级别通常会确保数据的一致性，尽管可能会导致一些性能开销。

InnoDB存储引擎使用了一种称为写前日志（Write-Ahead Logging，WAL）的机制来确保数据的一致性和持久性。具体操作流程如下：

1. 当有数据更新操作时，InnoDB首先将这个更新操作记录在事务的写前日志（redo log）中。这个写前日志是磁盘上的一个特殊文件。
2. 同时，InnoDB会将数据修改操作应用到内存中的缓冲池（Buffer Pool），从而提高读取和写入性能。这意味着数据的修改首先是在内存中的缓冲池中进行的。
3. 为了确保数据的持久性，InnoDB在适当的时机将缓冲池中的数据异步刷新到磁盘。这个操作通常发生在后台线程中，而不会阻塞用户事务。
4. 当事务提交时，InnoDB将事务的写前日志记录标记为已提交，从而使这个事务的修改在崩溃恢复时可以被应用。

这个操作流程保证了数据的持久性和一致性，即使在数据修改过程中出现了崩溃或故障。这是InnoDB存储引擎的核心特性，确保了数据在事务隔离下的一致性。

在这个过程中，InnoDB使用了行级锁来确保多个事务之间的并发性。每个数据行都可以被多个事务并发访问，而行级锁会确保数据的一致性。如果多个事务尝试同时修改相同的数据行，InnoDB会使用锁机制来协调它们的访问，以避免数据损坏和不一致。

总之，InnoDB存储引擎通过使用写前日志、内存缓冲池、异步刷新到磁盘以及行级锁等机制，来确保数据的一致性和持久性，即使在高并发和崩溃情况下也能保持数据的完整性。这是InnoDB在事务隔离下操作的基本原理。

Redo Log（重做日志） 和 Bin Log（二进制日志）的区别是什么？

Redo Log（重做日志）和Binary Log（二进制日志） 是MySQL中两种不同的日志文件，它们有不同的目的和用途。

• Redo Log（重做日志）：
  • 目的：Redo Log是InnoDB存储引擎特有的一种日志，其主要目的是确保事务的持久性。它记录了每个事务所做的修改操作，以便在数据库发生故障或崩溃时进行恢复。Redo Log用于保证数据的一致性和完整性。
  • 持久性：Redo Log是持久性的，它通常存储在磁盘上，并且不会轻易被删除。
  • 格式：Redo Log是二进制格式，记录了事务的修改操作，但不包含SQL语句。
• Binary Log（二进制日志）：
  • 目的：Binary Log用于记录数据库的所有变更操作，包括数据修改、DDL语句、数据导入等。它的主要目的是实现数据复制和恢复，以便在不同服务器之间同步数据或进行数据恢复。
  • 持久性：Binary Log通常也是持久性的，但它可以配置为自动删除旧日志以减少磁盘空间占用。
  • 格式：Binary Log可以以文本格式或二进制格式存储，它包含了SQL语句或二进制事件。

主要区别在于目的和内容：
* Redo Log 是InnoDB存储引擎用来确保事务持久性和一致性的日志，它记录了事务的修改操作，是二进制格式，通常不包含SQL语句。
* Binary Log 用于数据复制和恢复，它记录了数据库的所有变更操作，包括数据修改、DDL语句等，可以以文本或二进制格式存储。

MySQL的查询缓存默认是开启的吗？

自 MySQL 5.7.20 版本起，查询缓存（Query Cache）已被弃用，并且从 MySQL 8.0.20 版本开始，查询缓存已完全删除，不再可用。
在这之前的 MySQL 版本中，查询缓存默认是启用的，但随着时间的推移，它被认为不再适合高性能和高并发的数据库系统，因此被弃用并删除。

MySQL的sql注入怎么解决？

SQL注入是一种常见的数据库攻击，它可以允许攻击者执行恶意SQL查询或修改数据库数据。为了防止SQL注入，可以采取以下措施：

1. 使用参数化查询：最有效的防止SQL注入的方法是使用参数化查询，也叫预编译语句或绑定变量。在参数化查询中，SQL查询中的参数值是作为参数传递给数据库，而不是通过字符串拼接直接插入SQL查询中。这样可以防止恶意输入作为SQL代码执行。
   示例（使用Golang的database/sql包）：

   query := "SELECT * FROM users WHERE username = ? AND password = ?"
   rows, err := db.Query(query, username, password)
   

2. 输入验证和过滤：对用户输入进行验证和过滤，确保只允许合法的字符和数据。这可以通过正则表达式或其他验证方法来实现。
3. 避免拼接SQL查询：避免使用字符串拼接来构建SQL查询，因为这样容易受到注入攻击。使用参数化查询或ORM（对象关系映射）工具来构建和执行数据库查询。
4. 限制数据库用户权限：数据库用户应该被授予最小必要的权限。不要为应用程序使用的数据库用户授予过多的权限，以降低潜在攻击的影响。
5. 错误信息处理：不要向用户显示详细的数据库错误信息，因为攻击者可能会利用这些信息来发起攻击。将错误信息记录到服务器日志而不是向用户显示。
6. 定期更新和维护：定期更新数据库管理系统以获得最新的安全性修复和补丁。同时，确保应用程序的依赖项也是最新的，包括数据库驱动程序。
7. 安全编码实践：编写安全的代码，包括防止SQL注入。审查和审计应用程序代码以识别潜在的漏洞。
8. 使用Web应用程序防火墙（WAF）：WAF可以检测和阻止常见的注入攻击尝试，为应用程序提供额外的保护层。

Redis