SQL基础
InnoDB存储引擎
存储引擎常用的命令
show engines; # 查看所支持的所有存储引擎
show variables like '%storage_engine%'; # 查看默认的存储引擎
SET DEFAULT_STORAGE_ENGINE=MyISAM; # 设置默认存储引擎
#创建表时指定存储引擎
create table tableNmae{
...
}engine = 指定的存储引擎名;
#修改表存储引擎
alter table tableName engine = 指定的存储引擎名;
# 查看表的存储引擎
show create table `user`;
InnoDB是MySQL的默认事务性引擎,支持
锁:行级锁、适合高并发操作
索引:B+数索引、集群索引
缓存:缓存数据和索引
外键
MyISAM是非事务性引擎,支持
锁:表锁
索引:B+树索引、全文索引
缓存:只缓存索引
不支持外键
索引
普通索引、主键索引、唯一索引、联合索引、前缀索引
为什么选择B+树?
平衡性:能够保证任何节点到根节点的路径长度相同
范围查询的高效性:B+树的范围查询是更好的,相比于B树
磁盘I/O优化:B+树父节点只存储索引,相比于B树可以加载更多的索引节点,这样就减少了I/O次数。
多级索引:B+树的结构允许通过多级索引进行高效的范围查询
插入和删除操作的平衡性:对于节点的插入删除操作能够保持层数的平衡
存储密度高:B+树与B树相比可以存储更多的键。
较低的内存消耗:与哈希表相比,B+树的内存消耗较低,并且不会因为哈希冲突而导致性能下降。哈希表适合等值查询,但在范围查询和排序查询方面表现较差。
可靠性和恢复性:B+树结构简单而高度可靠,容易实现日志和恢复机制,确保在系统崩溃后能够快速恢复数据一致性。
聚簇索引和主键索引的区别
在InnoDB中,聚簇索引相当于主键索引,而具体来说聚簇索引和主键索引是不同的,聚簇索引是基于数据结构存储顺序的索引,主键索引是基于唯一性约束的索引。
主键索引和唯一索引的区别
主键索引是一种特殊的唯一索引。
主键索引不能存null,而唯一索引可以存null
唯一索引和普通索引的区别
普通索引不限制唯一性,同时普通索引由于可以使用change buffer的特性,所以可以减少I/O次数。
事务
事务特性
ACID:原子性、一致性、隔离性、持久性
原子性:redo、undo日志保证
一致性:通过外键约束以及约束的控制。
隔离性:多版本并发控制 + 锁机制
持久性:Binlog和Redo保证。
并发问题等级
脏写、脏读、不可重复读、幻读
隔离级别
读未提交、读已提交、可重复读、串行化
锁
读锁(共享锁)
读锁也叫共享锁,如果对某行数据执行写锁,那么这行数据可以进行读取,但是不能进行修改,即不能获得写锁(排他锁)。
可以在保持高并发的读操作、以及保持了数据的一致性,但是可能会导致读写冲突,导致读操作死锁。
demo
- 创建示例表并插入数据
CREATE TABLE items (
id INT PRIMARY KEY,
name VARCHAR(100),
quantity INT
);
INSERT INTO items (id, name, quantity) VALUES (1, 'item1', 100);
- 事务1:获取共享锁并读取数据
打开一个MySQL客户端会话,并执行以下SQL语句:
START TRANSACTION;
-- 获取共享锁
SELECT * FROM items WHERE id = 1 LOCK IN SHARE MODE;
-- 保持事务打开,等待事务2的操作
- 事务2:尝试获取共享锁
打开另一个MySQL客户端会话,并执行以下SQL语句
START TRANSACTION;
-- 尝试获取共享锁
SELECT * FROM items WHERE id = 1 LOCK IN SHARE MODE;
-- 读取数据成功,因为共享锁允许并发读取
SELECT * FROM items WHERE id = 1;
-- 提交事务
COMMIT;
- 事务3:尝试获取排他锁(写锁)
在另一个MySQL客户端会话中,执行以下SQL语句:
START TRANSACTION;
-- 尝试获取排他锁(写锁),会被阻塞,因为事务1和事务2持有共享锁
UPDATE items SET quantity = 50 WHERE id = 1;
-- 提交事务,解除锁定
COMMIT;
explain
事务1:获取共享锁,读取数据并保持事务打开。此时,该行数据被共享锁定,但其他事务仍然可以获取共享锁。
事务2:成功获取共享锁,读取数据并提交事务,因为共享锁允许并发读取。
事务3:尝试获取排他锁(写锁)时会被阻塞,因为事务1持有共享锁。只有当事务1提交或回滚后,事务3才能获取排他锁并执行更新操作。
写锁(排他锁)
当一个事务获取某行数据的排它锁时,其他事务不能对该行数据进行读取或写入操作,知道持有锁的事务释放锁,这意味着只有一个事务可以对数据进行修改,防止了并发写操作引起的数据不一致。可以保持数据的一致性、防止写入冲突,但是会降低并发性能、且可能造成死锁。
demo
- 创建示例表并插入数据
CREATE TABLE items (
id INT PRIMARY KEY,
name VARCHAR(100),
quantity INT
);
INSERT INTO items (id, name, quantity) VALUES (1, 'item1', 100);
- 事务1:获取排他锁并修改数据
打开一个MySQL客户端会话,并执行以下SQL语句:
START TRANSACTION;
-- 获取排他锁
SELECT * FROM items WHERE id = 1 FOR UPDATE;
-- 修改数据
UPDATE items SET quantity = 50 WHERE id = 1;
-- 保持事务打开,等待事务2的操作
- 事务2:尝试获取排他锁
打开另一个MySQL客户端会话,并执行以下SQL语句:
START TRANSACTION;
-- 尝试获取排他锁,会被阻塞,直到事务1提交或回滚
SELECT * FROM items WHERE id = 1 FOR UPDATE;
-- 如果事务1提交或回滚后,才能继续执行
UPDATE items SET quantity = 30 WHERE id = 1;
-- 提交事务
COMMIT;
explain
事务1:获取排他锁,读取数据并进行修改。此时,事务1持有该行数据的排他锁,其他事务无法读取或修改该数据。
事务2:尝试获取排他锁,会被阻塞,因为事务1已经持有该行数据的排他锁。只有当事务1提交或回滚后,事务2才能获取排他锁并继续操作。
意向锁
主要用于多粒度锁定中协调行锁和表锁之间的关系,意向锁本身并不阻塞任何事务,它的主要目的是在表级别上指示某个事务即将或已经在更细颗粒度上加了锁。
意向锁分为意向共享锁、意向排它锁
它通过在表级别指示锁定意图,减少了锁定检查的开销,提高了系统的并发性能。
减少了并发的发生,也是更高效的锁管理方法。
同时,也增加了锁机制的复杂性和潜在的性能开销。
demo
- 创建示例表并插入数据
CREATE TABLE items (
id INT PRIMARY KEY,
name VARCHAR(100),
quantity INT
);
INSERT INTO items (id, name, quantity) VALUES (1, 'item1', 100);
- 事务1:获取意向排他锁并更新数据
打开一个MySQL客户端会话,并执行以下SQL语句:
START TRANSACTION;
-- 获取意向排他锁,打算对表中的某些行加排他锁
UPDATE items SET quantity = 50 WHERE id = 1;
-- 此时事务1持有行级别的排他锁(X锁)和表级别的意向排他锁(IX锁)
-- 保持事务打开,等待事务2的操作
- 事务2:尝试获取意向共享锁并读取数据
打开另一个MySQL客户端会话,并执行以下SQL语句:
START TRANSACTION;
-- 获取意向共享锁,打算对表中的某些行加共享锁
SELECT * FROM items WHERE id = 1 LOCK IN SHARE MODE;
-- 读取数据成功,因为意向锁不冲突,读取操作不会被阻塞
SELECT * FROM items WHERE id = 1;
-- 提交事务
COMMIT;
- 事务3:尝试获取表级别的排他锁
在另一个MySQL客户端会话中,执行以下SQL语句:
START TRANSACTION;
-- 尝试获取表级别的排他锁(X锁),会被阻塞,因为事务1持有意向排他锁(IX锁)
LOCK TABLES items WRITE;
-- 事务3会被阻塞,直到事务1提交或回滚
-- 提交事务,解除锁定
COMMIT;
自增锁
用于控制自增列的锁机制,自增锁确保在高并发环境下,自增列值的生成是安全的,不会出现重复或跳跃。
优点:确保唯一性、保证顺序性、简单易用
缺点:性能瓶颈(每一次插入都要获取锁)、阻塞问题(如果一个事务长时间持有锁,会阻塞)、碎片问题。
自增锁的工作机制:传统锁模式、连续锁模式、交错锁模式。

被折叠的 条评论
为什么被折叠?



