MySQL的高可用方案主要有以下几种： 主从复制：这是最常见的高可用方案。主库负责处理写操作，并将数据变更记录到binlog日志。从库将主库的binlog复制到自己的中继日志，然后执行中继日志中的事件，以达到与主库数据一致的目的。当主库出现故障时，可以将从库提升为新的主库，实现服务的高可用。 集群：
Published on 2024-04-22
MySQL使用B+树作为索引的底层结构有以下几个主要原因： 良好的平衡性：B+树是一种自平衡的树结构，不论是在插入、删除还是查询操作中，它都能保持相对较好的平衡状态。这使得B+树能够快速定位到目标数据，提高查询效率。 顺序访问性：B+树的所有叶子节点是按照索引键的顺序排序的。这使得范围查询和顺序访问
Published on 2024-04-22
1.数据准备 -- 1.创建表： drop table user_login_log; CREATE TABLE user_login_log ( id INT PRIMARY KEY AUTO_INCREMENT, user_id VARCHAR(64) NOT NULL, ip V
Published on 2024-04-22
深分页问题是 MySQL 中常见的性能问题，当你尝试获取大量数据的后续页面时，性能会显著下降。这是因为 MySQL 需要先扫描到指定的偏移量，然后再返回数据。 例如，以下查询可能会非常慢： SELECT * FROM table ORDER BY id LIMIT 1000000, 10; 这是因为
Published on 2024-04-22
MySQL锁升级是指在并发事务执行过程中，当某个事务无法满足当前所需的锁级别时，系统会自动将该事务的锁级别升级为更高级别的锁。 通常情况下，MySQL 会根据事务的需求和操作的对象自动选择合适的锁级别。然而，在某些情况下，事务无法获取到所需的锁级别，就会触发锁升级。 例如以下两种常见的锁升级场景：
Published on 2024-04-22
自增主键的特点是当表中每新增一条记录时，主键值会根据自增步长自动叠加，通常会将自增步长设置1，也就是说自增主键值是连续的。那么MySQL自增主键值一定会连续吗？今天这篇文章就来说说这个问题，看看什么情况下自增主键会出现不连续？ 1.数据准备 drop TABLE increnment_test; -
Published on 2024-04-22
使用数据库的自增主键，虽然在很多情况下都很方便，但也可能遇到一些问题： 插入性能问题：对于非常高并发的插入操作，自增主键可能会成为性能瓶颈。因为每次插入新记录时，都需要获取一个新的自增ID，这个操作是串行的，无法并发执行。 主键耗尽：
Published on 2024-04-22
在数据库中，Undo Log通常用于实现事务的回滚操作。当事务执行更新操作时，数据库会将相应的旧数据记录在Undo Log中，用于回滚事务时还原到事务开始前的状态。以下是Undo Log回滚事务的一般步骤： 首先，获取事务的回滚指针或Undo Log的起始位置。 从Undo Log的末尾开始逆向扫描
Published on 2024-04-22
这一讲我们来深入分析一下MySQL是如何通过MVCC机制来实现隔离性。 上一讲和大家聊到，隔离性本质上是因为同时存在多个并发事务可能会导致脏读、幻读等情况。 要解决并发问题只有一种方案就是加锁。当然，锁不可避免的会导致性能下降，但是，锁也有乐观和悲观之分，上一讲我们聊到的，隔离级别中的串行化就是一种
Published on 2024-04-22
MySQL 的主从复制原理如下： 首先，主库将变更写入 binlog 日志。 从库连接到主库后，有一个 IO 线程负责将主库的 binlog 日志复制到自己本地，并写入到中继日志中。 然后，从库中有一个 S
Published on 2024-04-22
