u013905744的专栏

场景：业务逻辑：第三方登录情况下，获取到用户的实名信息。之后判断该用户在用户表中是否存在，如果不存在或非实名，那么将其实名；如果已经实名，那么不做处理，直接登录。ORM使用的是spring data jpa，用户表在mobile字段上有唯一索引idx_mobile发现不定期的发生业务报错：Deadlock found when trying to get lock; try restart...

数据库中存储日期的字段类型到底应该用varchar还是datetime

Mysql 为表添加外键约束Error Code: 1215. Cannot add foreign key constraint (foreign keys)

mysql批量删除多条记录的sql语句

mysqld --initialize mysqld --initialize-insecure

问题：虚拟机192.168.211.101连接在192.168.211.2（宿主机）上的mysql报错：java.sql.SQLException: null, message from server: "Host '192.168.211.101' is not allowed to connect to this MySQL server"解决方案：GRANT ALL ...

数据库监控需要监控哪些指标呢？文章目录1. 对数据库服务可用性进行监控2. 对数据库性能进行监控1. 周期性获取QPS和TPS2. 如何监控innodb的阻塞3. 监控buffer pool4. 监控binlog是否使用了磁盘5. 监控写的能力grafana mysql dashboard1. Uptime2. Current QPS3. InnoDB Buffer Pool Size4. ConnectionsConnectionsMax Used ConnectionsMax Connections5

模块划分能力relational database management system底层需要一个存储模块（文件系统）我们还需要组织并使用这些数据，因此需要有程序实例。用逻辑结构来映射出物理结构来，并且在程序中提供获取以及管理数据的方式，以及必要的问题追踪机制。文章目录1. 存储管理模块2. 缓存机制3. sql解析模块4. 日志管理5. 权限划分6. 容灾机制7. 索引管理8. 锁管理接下来来细分一下程序的模块。首先，需要对数据的格式以及文件的风格进行统一的管理，即把物理数据通过逻辑的形式给

表象：快照读（非阻塞读）–伪MVCC内在：next-key锁（行锁+gap锁）文章目录快照读和当前读next-key lock案例分析情况1：where条件全部命中，则不会用Gap锁，只会加记录锁情况2：where条件部分命中或者全不命中，则会加gap锁情况3：当前读走的是非唯一索引的情况情况4：不走索引的情况，会对所有的gap都上锁，这也就类似于锁表了快照读和当前读当前读：select…lock in share mode, select… for update当前读：update, delet

文章目录Read UnCommitted（未提交读）Read COMMITTED（提交读）REPEATABLE READ （可重复读）SERIALIIZABLE （可串行化）总结Read UnCommitted（未提交读）在Read UnCommitted级别，事务中的修改，即使没有提交，对其他事务也都是可见的。事务可以读取未提交的数据，这也被称为脏读（Dirty Read）。这个级别会导致很多问题，从性能上来说， Read UnCommitted 不会比其他的级别好太多，但却缺乏其他级别的很多好处，除

注意这里讨论的是抽象意义上的数据库，mysql数据库有自己特有的实现。事务隔离级别更新丢失脏读不可重复读幻读未提交读RU(Read Uncommited)避免发生发生发生已提交读RC(Read Commited)避免避免发生发生可重复读RR(Repeatable Read)避免避免避免发生串行化(Serializable)避免避免避免避免事务并发访问引起的问题以及如何避免文章目录1. 更新丢失问题2. 脏读问题3. 不可重

比如说数据库设计的时候，可以设计有以下4个级别的锁：数据库级别的锁表级别的锁页级别的锁记录级别的锁实际上innodb没有数据库级别的锁，也没有页级别的锁，其只有表级别的锁和记录级别的锁。加锁是从上往下（表到记录），一层一层的加锁释放锁就是从下向上（记录到表）逐层释放的innodb中的锁S 行级共享锁 record-lock（包含record lock + gap lock）X 行级排他锁 record-lock（包含record lock + gap lock）IS

在物理存储层面，每个mysql的表（非系统表）就是.frm文件及一个.ibd文件（前提是开启了独立表空间）。在物理层面就是一个二进制文件。在这个二进制文件的基础上，分析其内部逻辑组织结构。文章目录表空间 tablespace段 segment区 extent页页记录格式1. file Header2. Page Header3. lnfimum 和Supremum Record4. User Record5. Free Space6. Page Directory7. File Trailer行/记

查询性能优化，有3个方法。如何设计最优的库表结构如何建立最好的索引合理的设计查询库表结构优化、索引优化、查询优化需要齐头并进，一个不落。在尝试编写快速的查询之前，需要清楚一点，真正重要是响应时间。提升性能的两个方法：空间换时间，随机转顺序方法1：设计最优的库表结构，参考：数据库查询性能优化方法1：设计最优的库表结构方法2：建立最好的索引，参考：数据库查询性能优化方法2：建立最好的索引本篇为方法3：合理设计查询语句文章目录合理设计查询语句1. 确认是否返回了大量的无用数

查询性能优化，有3个方法。如何设计最优的库表结构如何建立最好的索引合理的设计查询库表结构优化、索引优化、查询优化需要齐头并进，一个不落。在尝试编写快速的查询之前，需要清楚一点，真正重要是响应时间。提升性能的两个方法：空间换时间，随机转顺序本篇为方法2：建立最好的索引方法1：设计最优的库表结构，参考：数据库查询性能优化方法1：设计最优的库表结构建立最好的索引MySQL可以使用同一个索引既满足排序，又用于查找行。因此，如果可能，设计索引时应该尽可能地同时满足这两种任务，这

查询性能优化，有3个方法。如何设计最优的库表结构如何建立最好的索引合理的设计查询库表结构优化、索引优化、查询优化需要齐头并进，一个不落。在尝试编写快速的查询之前，需要清楚一点，真正重要是响应时间。提升性能的两个方法：空间换时间，随机转顺序本篇为方法1：设计最优的库表结构文章目录设计最优的库表结构1. 数字类型2. 日期类型DATETIME类型TIMESTAMP类型3. char类型4. VARCHAR类型注意事项设计最优的库表结构主要就是选择合适的数据类型MySQL

文章目录B+ Tree数据结构主键B+ Tree复合索引(Compound Index) B+ Tree二级索引B+ Tree查询生命周期回表不回表的情况回表的情况回表优化案例B+ Tree数据结构mysql索引就是通过B+ Tree实现的B+树的primary value（主要作用）是在block-oriented storage context 块存储环境下，in particular, filesystems，比如说文件系统中，来存储数据。与B树对比，all records都被存储在树的le

binlog要与redo log对比来看，这篇文章就通过两者的对比来说明binlog的功能。文章目录binlog功能binlog工作过程对比binlog和redo logbinlog功能二进制日志（binlog），其用来进行point in time（PIT 基于时间点的恢复）的恢复及主从复制（Replication）环境的建立。binlog也是一种恢复机制，其实现的是基于时间点的恢复，比如通过binlog将数据库恢复到某个时间点。从表面上看其和重做日志非常相似，都是记录了对于数据库操作的日志。然而

这篇文章来回答这个问题：当应用层提交了一个事务，mysql底层是如何将增删改写入到最底层的.ibd文件中，并保证这个已提交的事务的原子性和持久性的文章目录背景知识LSN（log sequence number）buffer pool部分写失效及Double Write写过程基于redo log实现事务的原子性及持久性为了解决这个问题，要分析mysql的写过程。整体上来看，可以分为这两大部分：左侧为数据部分。左侧上部分是innodb内存缓冲池buffer pool，左侧下部分是磁盘上的record

undo log基础大家都知道，数据库的四个隔离级别。有一个情况大家也熟悉：即RC和RR两种隔离级别下的不同可见性，即不可重复读问题。不可重复读的含义是事务A多次读取同一数据，事务B在事务A多次读取的过程中，对数据做了更新并提交，导致事务A多次读取时数据不一致在RC隔离级别下，伪代码session1start transaction;session2start transact...

redo log基础重做日志用来实现事务的持久性，即事务ACID中的D。其由两部分组成：一是内存中的重做日志缓冲（redo log buffer），其是易失的：二是重做日志文件（redo log file），其是持久的。redo log buffer–innodb_log_buffer：通常8M已经足够使用了由log block组成，每个log block 512字节（不需要doub...

atomicity原子性一个事务是不可分割的最小单元，事务中的所有操作要么全部成功，要么全部失败如何保证：通过redo，重放机制来保证Consistency一致性数据如果有约束性，那么事务执行前后，数据的约束性还是存在的，并没有破坏掉。比如说转账事务的前后，资金的总数这个约束条件是不会被破坏的如何保证：通过undo，回滚机制来保证Isolation隔离性这个是很...