Mysql（数据库）知识详解【6】~{锁，架构}

数据库锁和架构是两个不同的概念，但它们都与数据库管理系统（DBMS）的性能和并发控制有关。

1. 数据库锁： 数据库锁是一种同步机制，用于控制多个事务对共享资源的访问。锁可以确保数据的一致性和完整性，防止多个事务同时修改相同的数据。根据锁的粒度和类型，可以分为以下几种：

   • 行锁：锁住单个数据行，允许其他事务访问未锁定的数据行。行锁具有高并发性，但可能导致死锁。
   • 表锁：锁住整个数据表，阻止其他事务访问表中的任何数据。表锁适用于大量数据操作，但并发性较低。
   • 页锁：锁住数据页，允许其他事务访问未锁定的数据页。页锁是行锁和表锁之间的折衷方案，具有一定的并发性和较低的死锁风险。
   • 读锁（共享锁）：允许事务读取锁定的数据，但阻止其他事务修改数据。读锁适用于多个事务需要读取相同数据的场景。
   • 写锁（排他锁）：阻止其他事务读取或修改锁定的数据。写锁适用于事务需要修改数据的场景。

2. 数据库架构： 数据库架构是指数据库的整体结构和设计，包括表、视图、索引、存储过程等数据库对象的组织方式。一个好的数据库架构可以提高查询性能、降低存储成本、方便维护和管理。以下是一些常见的数据库架构：

   • 第三范式（3NF）：通过消除数据冗余和依赖关系，确保数据的一致性和完整性。3NF架构适用于大多数业务场景，特别是需要保证数据质量的系统。
   • 星型模式（Star Schema）：将事实表和维度表分开存储，便于进行大数据分析。星型模式适用于数据仓库和报表系统。
   • 雪花模式（Snowflake Schema）：通过规范化维度表，减少数据冗余。雪花模式适用于需要进行复杂分析和多维报表的场景。
   • 无模式（NoSQL）：不使用固定的表结构，允许灵活地存储和查询数据。无模式架构适用于大数据和实时分析场景。

总之，数据库锁和架构都是影响数据库性能和并发控制的重要因素。在实际应用中，需要根据业务需求和场景选择合适的锁策略和架构设计。

没有数据的命令后面不要加“；”分号（命令行中）

也就是说只有加锁的窗口可以解锁

全局锁：其他客户端写入数据也会阻塞

加了表锁，只能读表，不能更新表中数据

第一个方框为读锁，第二个为写锁，而右边的DQL DDL/DML为另一个客户端

exclusive：排他锁

commit后，元数据锁就会解除

简单来说就是有读写数据操作的事务未提交的情况下不能修改表结构

元数据锁这个锁主要就是增删改查的时候不给你修改表数据

会不会阻塞就看所加的锁会不会互斥，不互斥，是兼容的话就不会阻塞，而如果这些锁所在客户端的事务提交以后，与其互斥的锁所在客户端阻塞状态就会解除

如锁第34行的数据记录

间隙锁只锁间隙里的记录

临键锁锁间隙和第34行的记录

1、自动锁（ Automatic Locks） 当进行一项数据库操作时，缺省情况下，系统自动为此数据库操作获得所有有必要的锁。

自动锁分为三种： DML 锁：

锁用于控制并发事务中的数据操纵，保证数据的一致性和完整性。 保护并发情况下的数据完整性。 语句能够自动地获得所需的表级锁（TM）与行级（事务）锁（TX）。 DDL 锁

锁用于保护数据库对象的结构，如表、索引等的结构定义。

排它 DDL 锁 创建、修改、删除一个数据库对象的 DDL 语句获得操作对象的 排它锁。

共享 DDL 锁 需在数据库对象之间建立相互依赖关系的 DDL 语句通常需共享获得 DDL锁。

如创建一个包，该包中的过程与函数引用了不同的数据库表，当编译此包时该事务就获得了引用表的共享 DDL 锁。如使用 alter table 语句时，为了维护数据的完成性、一致性、合法性，该事务获得一排它 DDL 锁

S代表共享锁

意向共享锁（IS锁）：事务在请求S锁前，要先获得IS锁 2）意向排他锁（IX锁）：事务在请求X锁前，要先获得IX锁

上面绿色方框是相应语法

前面的那个不可重复读的兄弟是可重复读，不可重复读是读已提交产生的后果