数据库

数据库
- MySQL
- Redis
  - Redis 中常见的数据类型有哪些？

数据库

MySQL

什么是关系型数据库范式？

数据库范式（Normalization）是数据库设计中的一套规则，用于组织数据库中的数据，以减少数据冗余，提高数据的完整性和一致性。范式提供了一种系统化的方法来设计数据库结构，使得数据冗余最小化，并避免某些常见的数据库操作问题，如插入异常、删除异常和更新异常。

1.第一范式（1NF）

要求：数据库表中的所有字段值必须是不可再分的原子值。换句话说，每一列中的数据应当是不可分割的单一值。

示例：

假设有一张表 Student：

StudentID	Name	PhoneNumber
1	Alice	123-4567
2	Bob	234-5678, 345-6789

在这里，PhoneNumber列包含多个电话号码（234-5678, 345-6789），这不符合第一范式。要将其转换为1NF，应将每个电话号码分成单独的记录。

转换后：

StudentID	Name	PhoneNumber
1	Alice	123-4567
2	Bob	234-5678
2	Bob	345-6789

2.第二范式（2NF）

要求：在满足第一范式的基础上，数据库表中的每个非主属性必须完全依赖于整个主键，而不能依赖主键的一部分。适用于复合主键的表。

示例：

假设有一张表 OrderDetail，主键是由 OrderID 和 ProductID 组成：

OrderID	ProductID	Quantity	ProductName
101	1	10	Laptop
101	2	5	Mouse

在这个表中，ProductName依赖于ProductID而不是整个复合主键（OrderID + ProductID），这违反了第二范式。

解决方法：将表拆分为两个表，使得每个非主属性完全依赖于主键。

转换后：

OrderDetail 表：

OrderID	ProductID	Quantity
101	1	10
101	2	5

Product 表：

ProductID	ProductName
1	Laptop
2	Mouse

3.第三范式（3NF）

要求：在满足第二范式的基础上，表中的非主属性不应相互依赖，即任何非主属性都不依赖于其他非主属性。

示例：

假设有一张表 Employee：

EmployeeID	Name	DepartmentID	DepartmentName
1	John	101	HR
2	Jane	102	IT

在这个表中，DepartmentName依赖于DepartmentID，而DepartmentID又依赖于EmployeeID，因此DepartmentName间接依赖于主键EmployeeID，这违反了第三范式。

解决方法：将表进一步拆分。

转换后：

Employee 表：

EmployeeID	Name	DepartmentID
1	John	101
2	Jane	102

Department 表：

DepartmentID	DepartmentName
101	HR
102	IT

MySQL 为什么使用 B+ 树来作索引，对比 B 树它的优点和缺点是什么？

MySQL 使用 B+ 树作为索引结构，是因为它非常适合数据库这种需要高效读写和范围查询的场景。B+ 树在结构上对 B 树进行了一些优化，从而更好地支持磁盘存储和数据查询。

B+ 树对比 B 树的主要优点

1. 所有数据都存储在叶子节点

B 树：数据既可以存储在内部节点（非叶子节点），也可以存储在叶子节点。
B+ 树：数据只存储在叶子节点，内部节点仅用于索引。

优点：

查询效率一致：在 B+ 树中，所有查询都需要找到叶子节点，路径长度相同，性能更稳定。而 B 树在数据存储在非叶子节点时可能提前结束查询，导致查询路径不一致。
空间利用率更高：由于内部节点仅存储索引（而不是数据），B+ 树的每个内部节点能容纳更多索引值，树的高度更低。

2. 叶子节点形成有序链表

B 树：叶子节点之间没有指针连接。
B+ 树：所有叶子节点通过指针串成一个双向有序链表。

优点：

范围查询效率高：有序链表使得范围查询和排序变得高效，只需在叶子节点中遍历即可。
顺序访问更快：叶子节点链表可以直接顺序访问，提高批量处理数据的性能。

3. 磁盘 I/O 性能更优

B 树：内部节点同时存储索引和数据，单个节点的信息量较大，导致一次磁盘 I/O 可能需要加载更多无关的数据。
B+ 树：内部节点仅存储索引，单个节点更小，因此一次磁盘 I/O 能加载更多的索引，减少树的高度，降低磁盘 I/O 次数。

优点总结：

更少的磁盘访问：B+ 树结构对大规模数据的访问更友好，尤其在磁盘 I/O 成本高的情况下。
优化缓存性能：由于内部节点更小，更多的节点可以存储在内存中，提高缓存命中率。

B+ 树的缺点

尽管 B+ 树在索引场景中有诸多优点，但它也有一些不足：

写性能略逊于 B 树：

B+ 树在插入和删除操作时，可能会对叶子节点链表进行维护，导致写操作开销比 B 树略高。
B 树可以直接在内部节点存储数据，减少了插入或删除过程中对叶子节点的依赖。

叶子节点存储更大：

由于所有数据都存储在叶子节点，B+ 树的叶子节点占用的存储空间比 B 树大。

设计复杂性增加：

B+ 树需要维护叶子节点的链表结构，导致其实现比 B 树稍微复杂。

为什么 MySQL 优先选择 B+ 树

读操作占主导

数据库场景下，查询操作的频率通常远高于写操作。B+ 树的查询效率高且稳定，更适合高频查询场景。

范围查询需求高

在数据库中，范围查询（如 WHERE age BETWEEN 20 AND 30）非常常见，B+ 树的叶子节点链表结构使得范围查询可以高效地连续扫描数据。

降低磁盘 I/O

由于数据库处理的是海量数据，内存不足以完全容纳整个索引，索引查询往往涉及大量磁盘访问。B+ 树更小的内部节点和更低的树高有效减少了磁盘 I/O 次数。

更好的排序和批量访问支持

B+ 树的叶子节点链表结构对排序、分页以及批量数据读取有天然的优势，而这些都是数据库的常见操作。

MySQL索引有哪些？

MySQL数据库中的索引有以下几种类型：

1. 普通索引（Normal Index）

特点：普通索引是最基本的索引类型，没有任何限制条件。

作用：加速查询速度。

创建方式：

CREATE INDEX index_name ON table_name
(column_name);

2. 唯一索引（Unique Index）

特点：唯一索引要求索引列中的所有值都是唯一的，但允许有一个空值 (NULL)。

作用：确保数据唯一性，同时也能加速查询。

CREATE UNIQUE INDEX index_name ON table_name(column_name);

3. 主键索引（Primary Key Index）

特点：主键索引是一种特殊的唯一索引，不允许有空值 (NULL)，一个表只能有一个主键索引。

作用：唯一标识表中的每一行数据，同时加速查询。

创建方式：

ALTER TABLE table_name ADD PRIMARY KEY (column_name);

或在创建表时定义：

CREATE TABLE table_name (
    column_name data_type PRIMARY KEY
);

4. 全文索引（Full-Text Index）

特点：全文索引用于加速对大文本的搜索，适用于 CHAR、VARCHAR 和 TEXT 字段。

作用：用于全文搜索功能，主要用于查找文本字段中的关键词。

创建方式：

CREATE FULLTEXT INDEX index_name ON table_name(column_name);

注意：MySQL的全文索引用于MyISAM和InnoDB引擎，且从MySQL 5.6版本开始支持InnoDB引擎。

5. 复合索引(联合索引)（Composite Index）

特点：复合索引是指在多个列上创建的索引。

作用：用于加速基于多个列的查询，遵循“最左前缀”原则。

CREATE INDEX index_name ON table_name(column1, column2);

6. 空间索引（Spatial Index）

特点：空间索引用于加速地理空间数据的查询，适用于MySQL的 Geometry 数据类型。

作用：主要用于地理信息系统（GIS）应用中的位置数据查询。

创建方式：

CREATE SPATIAL INDEX index_name ON table_name(column_name);

注意：空间索引仅适用于MyISAM表，并且从MySQL 5.7开始支持InnoDB。

7. 哈希索引（Hash Index）

特点：哈希索引用于加速精确匹配查询，不能用于范围查询。

作用：提高等值查询的速度。

注意：MySQL并没有直接创建哈希索引的语法，但在某些存储引擎中，如Memory引擎中，哈希索引是默认的。

CREATE TABLE my_table (
    id INT PRIMARY KEY,
    name VARCHAR(50)
) ENGINE=MEMORY;

CREATE INDEX idx_name ON my_table(name);

不同类型的索引有不同的适用场景，合理使用可以极大提升数据库的查询性能。

全文索引怎么使用？解决什么问题

全文索引（Full-Text Index）是MySQL中的一种特殊索引类型，专门用于处理文本字段的复杂搜索需求，特别是在长文本中查找特定单词或短语。它主要解决的问题是高效地进行全文搜索，即在大量文本数据中快速找到包含某个关键词的记录。

1. 全文索引的适用场景 长文本搜索：用于在包含大量文本数据的字段中查找特定的词或短语，如博客文章、产品描述、用户评论等。模糊匹配：适合用于需要搜索关键词而非精确匹配的场景，如搜索含有“database”和“mysql”这两个词的所有记录。多关键词搜索：可以搜索多个关键词，并根据相关性排序结果，如搜索含有“mysql”和“optimization”的记录，并根据这些词在文本中的出现频率和位置排序。

2. 全文索引的创建 MySQL的全文索引通常应用于 CHAR、VARCHAR 和 TEXT 数据类型的列。要使用全文索引，首先需要在相关列上创建全文索引。

CREATE TABLE articles (
    id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
    title VARCHAR(255),
    body TEXT,
    FULLTEXT (title, body)
);

也可以在已经存在的表上添加全文索引：

ALTER TABLE articles ADD FULLTEXT(title, body);

全文搜索查询

MySQL提供了 MATCH ... AGAINST 语法来执行全文搜索。

基本搜索：

SELECT * FROM articles 
WHERE MATCH(title, body) AGAINST('database');

布尔模式搜索：

布尔模式允许使用布尔运算符，如+（必须包含）、-（必须不包含）、*（通配符）等：

SELECT * FROM articles 
WHERE MATCH(title, body) AGAINST('+mysql -optimization' IN BOOLEAN MODE);

自然语言模式：

自然语言模式是默认的搜索模式，MySQL根据关键词的相关性返回匹配结果：

SELECT * FROM articles 
WHERE MATCH(title, body) AGAINST('mysql optimization');

带有查询扩展的自然语言模式：查询扩展模式在给定的查询词之外，还考虑全文索引中其他相关的词来扩展查询：

SELECT * FROM articles 
WHERE MATCH(title, body) AGAINST('mysql optimization' WITH QUERY EXPANSION);

3. 全文索引解决的问题

提高搜索效率：全文索引使得在大量文本数据中查找关键词的速度显著提高，相比LIKE操作符的模糊匹配更加高效。支持自然语言查询：能够根据关键词在文本中的相关性对结果进行排序，适用于搜索引擎类型的查询需求。支持复杂搜索逻辑：通过布尔模式支持复杂的查询逻辑，如必须包含某些词语或排除某些词语。

4 注意事项

最低词长度：默认情况下，MySQL的全文索引忽略长度少于4个字符的单词。这可以通过更改MySQL配置文件中的 ft_min_word_len 参数来调整。

停止词：MySQL会忽略一些常见的“停止词”（如"a", "the", "is"等），这些词通常在搜索中没有意义。这可以通过调整配置来禁用或修改。存储引擎：全文索引在MyISAM和InnoDB引擎上都可以使用，但在InnoDB上支持是从MySQL 5.6版本开始的。

总结

全文索引是MySQL中用于处理复杂文本搜索需求的强大工具。它能够快速、高效地在大规模文本数据中查找特定关键词，并根据关键词在文本中的相关性对结果进行排序。这在构建搜索引擎、内容管理系统和其他需要文本搜索功能的应用中非常有用。

你对binlog日志和redolog日志了解吗？解释以下这两个日志的作用以及两阶段提交

Binlog日志

作用：

复制：Binlog（Binary Log）是MySQL的二进制日志文件，主要用于数据库复制（replication）。它记录了对数据库执行的所有修改操作（如INSERT、UPDATE、DELETE），以便在主从复制中从库可以重放这些操作，从而保持与主库的一致性。
数据恢复：在灾难恢复时，可以通过重放Binlog日志来恢复数据。备份恢复后，可以使用Binlog日志将数据库状态恢复到特定时间点，确保数据完整性和一致性。

Redo日志

作用：

数据持久化：Redo Log是InnoDB存储引擎的重做日志，用于记录事务的修改操作。这些操作会首先写入Redo Log，然后再写入数据文件。即使在系统崩溃时，也可以通过Redo Log将未完成的事务重做，从而保证数据的持久性。
性能优化：由于Redo Log采用顺序写入的方式，相对于随机写入的磁盘操作速度更快。这种方式提高了数据库的写入性能，因为修改操作可以先写入Redo Log，再批量刷新到数据文件中。

两阶段提交（Two-Phase Commit）

两阶段提交是用来保证事务在分布式系统或多个存储引擎之间的一致性的方法。MySQL使用两阶段提交来协调Binlog和Redo Log的写入，以确保在系统崩溃后，数据仍然保持一致。两阶段提交过程如下：

1.预提交阶段（Prepare Phase）：

事务执行过程中，所有的修改操作首先写入Redo Log的缓存区，但此时并不会提交。
Redo Log的状态设置为准备提交（prepare）。
同时，事务的修改操作记录在Binlog缓存中，但不立即写入磁盘。

2.提交阶段（Commit Phase）：

确认所有参与的存储引擎（或分布式系统的节点）都准备好提交。
将Binlog缓存中的日志刷新到磁盘，确保Binlog记录持久化。
将Redo Log的状态从准备提交修改为已提交，并刷新到磁盘，完成实际的数据提交操作。

两阶段提交的作用

两阶段提交的主要作用是保证数据的一致性和持久性。通过在两个独立的日志系统（Binlog和Redo Log）之间协调提交操作，可以确保即使在系统崩溃的情况下，也能通过重放日志恢复数据，从而保持数据库的一致性。具体来说：

数据一致性：两阶段提交确保了在Binlog和Redo Log之间的原子性操作，即要么两者都成功，要么都失败，从而防止数据不一致的情况。
持久性保证：通过先将Redo Log写入磁盘，再写入Binlog，保证了在系统崩溃后可以通过Redo Log进行恢复，而不会丢失数据。

这种机制在数据库系统中非常重要，因为它有效地解决了数据在分布式系统或多存储引擎环境中的一致性问题。

列举MySQL的四个隔离级别，并解释每个级别的区别以及可能产生的问题

MySQL 的事务隔离级别定义了事务之间的可见性和一致性，决定了在并发环境中事务的行为。MySQL 支持四种标准的隔离级别，每种级别在数据一致性和并发性之间有所权衡。以下是这四个隔离级别的详细解释以及它们可能产生的问题：

1.读未提交（READ UNCOMMITTED）

描述：

这是最低的隔离级别。在这个级别下，一个事务可以读取其他事务未提交的数据。

可能产生的问题：

脏读（Dirty Read）：事务 A 修改了数据但还未提交，事务 B 可以读取到这些未提交的数据。若事务 A 回滚，事务 B 读取到的数据就是无效的。

适用场景：

对数据一致性要求不高，且需要最大限度的并发性。例如，日志记录或缓存数据的应用场景。

2.读已提交（READ COMMITTED）

描述：

在这个隔离级别下，一个事务只能读取其他事务已提交的数据。即使其他事务已经提交，事务在读取数据时也不能读取到其他事务尚未提交的数据。

可能产生的问题：

不可重复读（Non-repeatable Read）：事务 A 在执行某个查询时读取了一些数据，随后事务 B 对这些数据进行了修改并提交。事务 A 再次执行相同的查询时会得到不同的结果。

适用场景：

数据一致性要求较高但仍需保持较高的并发性。适用于对数据读操作一致性有一定要求的场景。

3.可重复读（REPEATABLE READ）

描述：

在这个隔离级别下，事务在开始后读取的数据在事务期间内不会被其他事务修改，保证了每次查询的数据都是一致的。

可能产生的问题：

幻读（Phantom Read）：事务 A 执行一个范围查询时读取到的数据在事务 A 内部是稳定的。但如果事务 B 在事务 A 执行期间插入或删除了数据，这会导致事务 A 再次执行相同的查询时发现结果集有所不同。

适用场景：

需要保证在事务内对数据的读操作具有一致性，适用于大多数需要确保读取数据一致性的业务逻辑。

4.串行化（SERIALIZABLE）

描述：

这是最高的隔离级别，事务完全隔离。事务被强制序列化执行，即事务之间没有任何交叉，确保数据的一致性。

可能产生的问题：

性能开销：由于事务之间完全隔离，可能会导致事务执行的性能开销显著增加，特别是在高并发环境中。

适用场景：

数据一致性要求极高的场景，如金融交易等关键业务流程。适用于对数据完整性和一致性要求严格的应用场景。

总结

读未提交（READ UNCOMMITTED）：最低的隔离级别，可能会产生脏读。
读已提交（READ COMMITTED）：避免了脏读，但可能会出现不可重复读。
可重复读（REPEATABLE READ）：避免了脏读和不可重复读，但可能会出现幻读。
串行化（SERIALIZABLE）：最高的隔离级别，避免了脏读、不可重复读和幻读，但可能会导致性能降低。根据实际的业务需求，可以选择适当的隔离级别来平衡数据一致性和系统性能。

MySQL可重复读完全解决了幻读问题吗？

MySQL InnoDB引擎的默认隔离级别是可重复读，根据不同的查询方式，分别提出了避免幻读的方案：

针对快照读，通过MVCC方式解决
针对当前读，通过next-key lock(记录锁+间隙锁)方式解决了幻读。

但是，可重复读不能彻底解决幻读，但是可以很大程度上避免幻读发生。例如事务A更新了一条事务B插入的记录，那么事务A前后两次查询到的记录条目就不一样了，所以就会发生幻读。

MySQL的同步方式

复制模式	工作原理	优点	缺点	适用场景
异步复制	主库执行完写操作后立即返回，不等待从库确认	延迟低，性能高，主库吞吐量大	主库和从库可能数据不一致，有数据丢失风险	对性能要求高，数据一致性要求相对较低
半同步复制	主库至少等待一个从库确认已接收到日志	较好的数据一致性，性能比同步复制高	主库需要等待从库确认，可能有轻微延迟	数据一致性要求较高，但不至于极端要求强一致性
同步复制	主库等待所有从库确认已接收到并应用日志	数据一致性最高，主从库数据完全同步	延迟高，性能低，主库压力大	强一致性要求的系统，如金融、交易等

mysql的where和having有什么区别

where和having工作流程中的位置, SQL 查询的执行顺序如下：

从 FROM 子句中选择表。
应用 WHERE 子句过滤原始数据行。
根据 GROUP BY 子句进行分组（如果存在）。
使用聚合函数对每个分组进行计算（如 SUM, AVG）。
应用 HAVING 子句过滤分组后的结果。
返回最终结果集。

WHERE作用于原始数据, HAVING作用于分组后的聚合结果。

1.WHERE 示例

假设我们有一个 orders 表，包含以下数据：

order_id	customer	amount
1	Alice	100
2	Bob	200
3	Alice	150
4	Carol	300

查询：获取金额大于 150 的订单。

SELECT * 
FROM orders
WHERE amount > 150;

结果：

order_id	customer	amount
2	Bob	200
4	Carol	300

WHERE 在分组和聚合计算之前过滤每一行数据。

2.HAVING 示例

查询：每个客户的订单总金额，并筛选总金额大于等于 250 的客户。

SELECT customer, SUM(amount) AS total_amount
FROM orders
GROUP BY customer
HAVING total_amount >= 250;

customer	total_amount
Alice	250
Carol	300

分析：

GROUP BY 按客户分组。
使用 SUM 计算每个分组的总金额。
HAVING 过滤聚合结果中总金额大于 250 的分组。

3.WHERE 和 HAVING 的联合使用

可以在同一个查询中同时使用 WHERE 和 HAVING：

WHERE：过滤原始数据，减少参与分组和聚合的数据量。
HAVING：过滤分组后的聚合结果。

只考虑金额大于 100 的订单，统计每个客户的订单总金额，并筛选总金额大于 200 的客户。

SELECT customer, SUM(amount) AS total_amount
FROM orders
WHERE amount > 100
GROUP BY customer
HAVING total_amount > 200;

customer	total_amount
Carol	300

分析：

WHERE：先过滤掉 amount <= 100 的订单。
GROUP BY：对剩下的数据按客户分组。
HAVING：对分组后的聚合结果筛选出 total_amount > 200 的分组

MySQL的MVCC机制

https://zgjsxx.github.io/posts/database/mysql/mysql_mvcc.htmlopen in new window

MySQL回表是什么？

在MySQL中，回表（Covering Index 或 Index Lookup）指的是查询在执行过程中，通过索引来查找数据，若索引本身不包含查询所需的所有列的数据时，需要回到表中去读取完整的记录。换句话说，回表是指通过索引查找记录时，如果索引中的数据不完全，MySQL需要通过索引中的主键（或聚簇索引）再次去查询数据表，来获取缺失的信息。

1.回表的过程

当查询涉及到的列不完全由索引覆盖时，MySQL会：

1.首先通过索引找到满足查询条件的记录位置（如行号、主键值）。
2.然后再通过这些位置或主键值去数据表中查询完整的行数据。

这种操作就是回表，因为MySQL通过索引找到了数据行的“指针”，然后再去回到数据表中获取完整的记录。

2.为什么会发生回表

查询的列不在索引中：当索引只包含查询的部分列时，查询需要的数据列不在索引中，因此需要去数据表中查找。
查询的列超出了索引的覆盖范围：有时候索引的前缀可以覆盖查询条件，但不包括所有查询列，因此仍然需要访问表来获取完整数据。

3.回表的例子

假设有以下数据表 employees：

CREATE TABLE employees (
    id INT PRIMARY KEY,
    name VARCHAR(100),
    age INT,
    salary DECIMAL(10, 2)
);

创建了一个非唯一的索引：

CREATE INDEX idx_name_age ON employees (name, age);

查询1：只涉及索引列

SELECT name, age FROM employees WHERE name = 'John';

这个查询会使用 idx_name_age 索引，因为查询的列 name 和 age 都在索引中，索引本身就能包含查询所需的所有数据，因此不会回表。

查询2：涉及非索引列

SELECT name, age, salary FROM employees WHERE name = 'John';

这个查询也会使用 idx_name_age 索引来查找满足条件的记录，但因为 salary 不在索引中，所以查询的结果需要通过回表去表中查找 salary 列的数据。也就是说，MySQL会先通过 idx_name_age 索引找到符合 name = 'John' 的记录，然后再根据主键值去回表查询 salary 列。

4.如何避免回表

覆盖索引（Covering Index）：如果索引包含查询所需的所有列，那么查询就不需要回表。可以通过在索引中包含更多列来避免回表。

比如，如果创建一个包括 name、age 和 salary 的复合索引，就可以避免回表：

CREATE INDEX idx_name_age_salary ON employees (name, age, salary);

使用合适的索引：在设计索引时，如果知道某些查询会频繁执行，可以根据查询的字段来设计合适的复合索引，使得查询所需要的列都包含在索引中，从而避免回表。

5.回表的性能影响

回表增加I/O：回表意味着MySQL在执行查询时，除了读取索引，还需要再访问表中的数据，这会导致额外的磁盘I/O。对于大表和复杂查询，回表可能会显著影响查询性能。
避免回表：通过合理的索引设计，避免不必要的回表操作，能显著提高查询效率，尤其是当查询涉及多个列时。

6. 解释回表

使用 EXPLAIN 命令可以查看MySQL在查询中是否使用了回表：

EXPLAIN SELECT name, age, salary FROM employees WHERE name = 'John';

如果查询需要回表，EXPLAIN 的输出中会显示 Using index（表示使用了索引），但是也可能会看到 Extra 列中标注有 Using index 和 Using where，表示索引没有覆盖所有查询列，因此需要回表。

7.回表的总结

回表是指通过索引查询时，若索引不包含查询列的数据，MySQL会再回到数据表中获取这些列的值。
避免回表的方法之一是设计覆盖索引，使索引包含所有查询所需的列。
回表会增加额外的I/O操作，影响查询性能，因此合理设计索引非常重要。

Redis

Redis 中常见的数据类型有哪些？

在 Redis 中，常见的数据类型主要有 6 种，每种类型都有其特定的用途和操作方式。理解这些数据类型的特性和如何使用它们，是高效使用 Redis 的基础。以下是 Redis 中常见的 6 种数据类型及其详细介绍：

1.字符串（String）

描述

Redis 中最基本的数据类型，类似于键值对中的值。一个字符串类型的值可以包含任何数据，例如字符串、整数、浮点数等，最大长度为 512MB。
字符串是 Redis 中最常见的数据类型，几乎所有的操作都支持字符串类型。

操作

SET key value：设置一个字符串值。
GET key：获取一个字符串值。
INCR key：将字符串值按整数递增。
APPEND key value：将值追加到字符串末尾。示例

SET name "Redis"
GET name
INCR counter
APPEND name " is awesome!"

使用场景

缓存一些简单的数值、字符串。
作为计数器（例如：访问量统计、订单号生成）。
用于存储 JSON 字符串或其他结构化数据的序列化结果。

2.哈希（Hash）

描述

哈希是一种键值对集合，可以用来表示对象。它类似于一个字典（或映射），每个哈希由多个字段和它们对应的值组成。
适合存储对象数据，例如用户信息、商品信息等。

操作

HSET key field value：为哈希表中的字段设置值。
HGET key field：获取哈希表中指定字段的值。
HGETALL key：获取哈希表中所有字段和值。
HDEL key field：删除哈希表中的字段。

示例

HSET user:1000 name "Alice" age "30"
HGET user:1000 name
HGETALL user:1000

使用场景

存储对象或结构化数据（例如：用户信息、商品详情）。
用于存储频繁更新的字段，避免每次都对整个对象进行操作。

3.列表（List）

描述

列表是一种简单的字符串列表，可以在头部或尾部推送元素，支持按顺序存储元素（类似于链表）。
列表是有序的，可以用于实现消息队列、任务列表等场景。

操作

LPUSH key value：将元素添加到列表的左端（头部）。
RPUSH key value：将元素添加到列表的右端（尾部）。
LPOP key：移除并返回列表的左端元素。
RPOP key：移除并返回列表的右端元素。
LRANGE key start stop：返回列表中指定范围的元素。

示例

LPUSH queue "task1"
RPUSH queue "task2"
LPOP queue
LRANGE queue 0 -1

使用场景

消息队列：生产者将任务推送到列表，消费者从列表中取出任务。
实现顺序处理任务、活动流、实时日志等场景。

4.集合（Set）

描述

集合是一个无序的字符串集合，支持高效的集合操作，如求交集、并集和差集等。
集合中的元素是唯一的，不允许重复。

操作

SADD key member：向集合添加成员。
SREM key member：从集合中移除成员。
SMEMBERS key：返回集合中的所有成员。
SISMEMBER key member：判断元素是否是集合的成员。
SINTER key1 key2：返回两个集合的交集。
SUNION key1 key2：返回两个集合的并集。示例 bash 复制代码 SADD fruits "apple" "banana" "cherry" SMEMBERS fruits SISMEMBER fruits "banana" SINTER fruits another_set 使用场景实现社交网络中的好友关系、标签、推荐系统等。用于去重操作（例如：去重用户、IP 地址等）。

有序集合（Sorted Set）描述有序集合是一个类似于集合的数据结构，不同之处在于每个元素都关联一个分数（score），并根据分数自动排序。支持按分数范围或排名查询，非常适合用于排行榜、排名、时间序列等应用。操作 ZADD key score member：将成员添加到有序集合中。 ZRANGE key start stop：返回有序集合中指定范围内的成员，按分数从低到高排序。 ZREVRANGE key start stop：返回有序集合中指定范围内的成员，按分数从高到低排序。 ZREM key member：从有序集合中移除成员。 ZRANK key member：返回成员在有序集合中的排名（按分数排序）。示例 bash 复制代码 ZADD leaderboard 100 "Alice" 200 "Bob" 150 "Charlie" ZRANGE leaderboard 0 -1 ZREVRANGE leaderboard 0 1 使用场景排行榜：比如游戏成绩、社交媒体中用户点赞数。事件排序：例如按时间戳排序的日志、任务的优先级排序等。
位图（Bitmap）描述位图实际上是一种特殊的字符串类型，可以用来存储位信息（每个值是 0 或 1），非常适合做布尔值的快速统计与查询。通过位操作（设置位、清除位、查询位等）来操作大量的布尔值数据，通常用于位计数和布隆过滤器。操作 SETBIT key offset value：设置位图指定偏移量的值。 GETBIT key offset：获取位图指定偏移量的值。 BITCOUNT key：计算位图中值为 1 的位数。 BITOP AND key destkey key1 key2：对多个位图执行按位与操作。示例 bash 复制代码 SETBIT users 1000 1 GETBIT users 1000 BITCOUNT users 使用场景用户签到：记录用户是否签到。实现布隆过滤器，检查某个元素是否存在于集合中。

数据库

# 数据库

# MySQL

# 什么是关系型数据库范式？

# MySQL 为什么使用 B+ 树来作索引，对比 B 树它的优点和缺点是什么？

# MySQL索引有哪些？

# 全文索引怎么使用？解决什么问题

# 你对binlog日志和redolog日志了解吗？解释以下这两个日志的作用以及两阶段提交

# 列举MySQL的四个隔离级别，并解释每个级别的区别以及可能产生的问题

# MySQL可重复读完全解决了幻读问题吗？

# MySQL的同步方式

# mysql的where和having有什么区别

# MySQL的MVCC机制

# MySQL回表是什么？

# Redis

# Redis 中常见的数据类型有哪些？

数据库

MySQL

什么是关系型数据库范式？

MySQL 为什么使用 B+ 树来作索引，对比 B 树它的优点和缺点是什么？

MySQL索引有哪些？

全文索引怎么使用？解决什么问题

你对binlog日志和redolog日志了解吗？解释以下这两个日志的作用以及两阶段提交

列举MySQL的四个隔离级别，并解释每个级别的区别以及可能产生的问题

MySQL可重复读完全解决了幻读问题吗？

MySQL的同步方式

mysql的where和having有什么区别

MySQL的MVCC机制

MySQL回表是什么？

Redis

Redis 中常见的数据类型有哪些？