0kr's Blog

1.Redis存储过程Redis数据存储的核心是基于redisDb结构，它是Redis中最顶层的数据库对象。 redisDb代表Redis数据库结构，上一章，我们讲到的各种操作对象，就是存储在dict数据结构里，本节后面的讲述中，我们都会以上一章节的操作对象为例来进行讲解。 redisDb结构redisDb结构体(来自Redis 5.0.5)包含以下主要字段： 12345678910typedef struct redisDb { dict *dict; /* 数据库的主键空间，存储所有键值对 */ dict *expires; /* 存储设置了过期时间的键 */ dict *blocking_keys; /* 存储有客户端在等待数据的键(BLPOP) */ dict *ready_keys; /* 接收了PUSH命令的被阻塞的键 */ dict *watched_keys; /* 被WATCH命令监视的键(用于MULTI/EXEC事务)...

Redis学习流程：对象、执行流程、持久化、场景、集群。本篇讲述第一部分：Redis的各种数据结构。 0.Why Redis？相比与MySQL这种磁盘型的数据库，Redis是一款内存数据存储系统，所有数据采用键值对结构，以其卓越的性能和灵活性在现代应用架构中占据重要地位。它将数据直接存储在RAM中，提供毫秒级响应速度，同时支持多样化的数据结构（如后面要讲到的String、List、Hash、Set、ZSet等）。 在以前，Redis作为传统缓存层的首选技术充当请求与主数据库的缓冲。而现在，Redis不仅能够提供数据持久化保障，还支持JSON格式、高效搜索和对象映射功能，也能支持作为主数据库使用了。无论是自托管还是通过Redis...

主从复制与读写分离过程总共有三步： 写入binlog: 当主库上发生数据变更时，这些变更会被记录到二进制日志(binlog)中。这是一个事务日志，记录了所有修改数据库的操作。 同步binlog: 从库上的IO线程会连接到主库，并请求获取主库上的binlog。主库会通过dump线程发送binlog内容给从库，从库将接收到的binlog信息写入到自己的中继日志(relay log)中。 回放binlog: 从库上的SQL线程会读取relay log中的内容，并在从库上执行这些SQL操作，使从库的数据与主库保持一致。 那么这就不得不提出一个问题：为什么要通过relay日志文件做缓冲呢，从库为什么不能直接请求获取主库的binlog日志并读取呢？ 首先要考虑到数据完整性风险。从库的 IO线程从主库读取二进制日志(binlog)时，如果没有 relaylog，一旦从库发生故障，已读取但未执行的 binlog 内容可能丢失，导致数据不一致。 还有就是复制效率问题：IO 线程和SQL线程的工作节奏不同步。没有 relay log 作为缓冲，SQL线程可能需要等待 IO...

Mysql单机性能 https://support.huaweicloud.com/pwp-rds/rds_swp_mysql_09.html 对于4c8g 服务器，mysql 可承载： 500 TPS(数据库每秒执行的事务数，以COMMIT 成功次数为准) 10000 QPS(数据库每秒执行的 SQL 数) explain执行计划 注：本节最重要的目的是根据type、key、extra三个字段判断查询是否走了索引 在执行计划中，参数有： possible_keys 字段表示可能用到的索引； key 字段表示实际用的索引，如果这一项为 NULL，说明没有使用索引； key_len 表示索引的长度； rows 表示扫描的数据行数。 type 表示数据扫描类型，我们需要重点看这个。 type 字段就是描述了找到所需数据时使用的扫描方式是什么，常见扫描类型的执行效率从低到高的顺序为： All（全表扫描）：在这些情况里，all 是最坏的情况，因为采用了全表扫描的方式。 index（全索引扫描）：index 和 all 差不多，只不过 index...

慢查询解决慢SQL的路径： MySQL 有一个慢查询日志，会帮我们记录执行耗时超过n秒的 SQL 语句，可以通过这个慢查询日志，发现慢SQL. 慢查询日志默认是关闭状态，可以通过以下命令查看慢查询日志的开关状态和慢查询日志路径： 可以将参数设置为on，或者修改配置文件my.cnf来开启慢查询日志，如： 1234[mysqld]slow_query_log= ON #开启慢查询日志的开关slow_query_log_file=/var/lib/mysql/my-slow.log #慢查询日志的目录和文件名信息long_query_time=2 #设置慢査询的阈值为2秒，超出此设定值的SQL即被记录到慢查询日志 在我们想排查接口响应慢的原因的时候，可以考虑把慢査询日志打开，看下接口响应慢的原因是不是慢SQL导致的，如果是的话，就可以针对日志中SQL进行分析和调优了。 接下来，为了分析查询执行慢的原因，需要使用explain来查看执行计划。 逐列解释： table table 显示的是这一行的数据是关于哪张表的，上述内容中显示的表名就是...

处理缺失值标准化与归一化分割日期字符编码日期不一致

锁 实在写不动了，多拿了点别人的截图过来，自己写写额外的理解。锁还是为了解决并发场景下数据一致性的问题，我们将从锁的分类、加锁过程、死锁问题三个大方面去介绍何为锁。开始！ 锁类型自上而下分为：全局锁、表级锁、行级锁，其中重点是行级锁。 全局锁顾名思义，锁的对象是整个数据库，一般用于数据库快照和备份存储（显然备份的时候是需要上锁的，毫无疑问）。 然而加上全局锁，意味着整个数据库都是只读状态。那么如果数据库里有很多数据，备份就会花费很多的时间，关键是备份期间，业务只能读数据，而不能更新数据，这样会造成业务停滞。 解决办法就是：如果数据库的引擎支持的事务支持可重复读的隔离级别，那么在备份数据库之前先开启事务，会先创建 Read View，然后整个事务执行期间都在用这个 Read View，而且由于 MVCC 的支持，备份期间业务依然可以对数据进行更新操作。 备份数据库的工具是 mysqldump，在使用 mysqldump 时加上 -single-transaction...