跟事务相关的日志生成量的对比

博客对比了Oracle中插入相同数量记录时单条提交和成批提交产生的日志量,发现成批提交通常远小于单条提交。还对比了设置transaction_auditing为false/true前后的日志生成量差异,指出该参数设置会影响大量短小事务的日志生成情况。

 

1: 插入相同数量记录的单条提交和成皮提交之间的对比
我们可以看出分别是 25112152 - 8024588 = 17087564
8024588 - 13384 = 8011204
对比相差达到9M


SQL> show parameters transaction_auditing

NAME TYPE VALUE
------------------------------------ ------- --------------------
transaction_auditing boolean TRUE
SQL>


SQL> select name,value from v$sysstat where name like 'redo size';

NAME VALUE
---------------------------------------------------------------- ----------
redo size 13384

SQL> begin
2 for i in 1..25835 loop
3 insert into rainy.t select * from dba_objects where rownum = 1;
4 end loop;
5 end;
6 /

PL/SQL procedure successfully completed.

SQL> commit;

Commit complete.

SQL> select name,value from v$sysstat where name like 'redo size';

NAME VALUE
---------------------------------------------------------------- ----------
redo size 8024588

SQL> begin
2 for i in 1..25835 loop
3 insert into rainy.t select * from dba_objects where rownum = 1;
4 commit;
5 end loop;
6 end;
7 /

PL/SQL procedure successfully completed.

SQL> select name,value from v$sysstat where name like 'redo size';

NAME VALUE
---------------------------------------------------------------- ----------
redo size 25112152


2 : 关于设置 transaction_auditing = false/true 前后的对比
13892572 - 12332 = 13880240

对比 1 中相同状况下的结果 17087564 ,可以看出体制生成两相差了大约3M

SQL> show parameters transaction_auditing

NAME TYPE VALUE
------------------------------------ ------- --------------------
transaction_auditing boolean FALSE
SQL>

SQL> select name,value from v$sysstat where name like 'redo size';

NAME VALUE
---------------------------------------------------------------- ----------
redo size 12332

SQL> begin
2 for i in 1..25835 loop
3 insert into rainy.t select * from dba_objects where rownum = 1;
4 commit;
5 end loop;
6 end;
7 /

PL/SQL procedure successfully completed.

SQL> select name,value from v$sysstat where name like 'redo size';

NAME VALUE
---------------------------------------------------------------- ----------
redo size 13892572



结论:
成批提交和但条提交所产生的日志量差异巨大,成批提交通常远小于单条提交

关于transaction_auditing ,我们先看oracle的解释
If TRANSACTION_AUDITING is true, Oracle generates a special redo record that contains the user logon name, username, the session ID, some operating system information, and client information. For each successive transaction, Oracle generates a record that contains only the session ID. These subsequent records link back to the first record, which also contains the session ID.

These records might be useful if you are using a redo log analysis tool. You can access the records by dumping the redo log.

If TRANSACTION_AUDITING is false, no redo record will be generated

      这个意思是,如果设置为true,则oracle将对事务进行审计,也就是日志里面为事务产生一几乎固定大小的信息,包括用户名、session is、一些操作信息、client信等(通过dump logfile可以看到),这些信息在使用logmnr等工具分析的时候可以有用的。如果设置该参数为false,则在大量的短小事务的情况下将产生不可忽略的日志生成量的差异

<think>嗯,用户之前让我详细讲解了Redis,现在要求将Redis与MySQL进行对比。我需要先回顾之前的内容,确保对比时覆盖存储机制、优缺点和应用场景。用户可能想知道在不同情况下该选择哪种数据库,或者是想理解两者的根本区别。 首先,得明确Redis是内存型键值存储,而MySQL是关系型数据库,基于磁盘。存储结构上,Redis支持多种数据结构,而MySQL是表格结构,支持SQL查询。性能方面,Redis肯定更快,但持久化和数据规模可能不如MySQL。 然后,用户可能关心两者的优缺点对比,尤其是在存储方面。比如Redis内存限制,而MySQL可以处理更大规模的数据,但速度较慢。事务支持方面,MySQL有ACID,而Redis的事务相对简单。 应用场景方面,用户可能想知道何时用Redis作为缓存,何时用MySQL做主数据库。需要提到结合使用的情况,比如用Redis加速MySQL的查询。 还要注意用户可能的深层需求,比如系统架构设计中的选择考量,或者如何解决数据一致性问题。需要给出实际例子,比如电商中的库存缓存用Redis,订单处理用MySQL。 最后,确保对比清晰,结构分明,用表格或分点列出,让用户一目了然。避免技术术语过多,用简单的中文解释,必要时举例说明。</think>--- ### **Redis vs MySQL 核心对比** | **特性** | **Redis** | **MySQL** | |------------------------|-----------------------------------------------|-----------------------------------------------| | **数据模型** | 键值对 + 多种数据结构(字符串、哈希、列表等) | 关系型表结构,支持复杂 JOIN 和 SQL 查询 | | **存储介质** | **内存为主**(持久化可选) | **磁盘为主**(通过 Buffer Pool 缓存部分数据) | | **读写性能** | **极高**(微秒级延迟,10万+ QPS) | **中等**(毫秒级延迟,数千 QPS) | | **数据规模** | 受内存限制(通常百 GB 级以内) | 支持 TB 级数据(依赖磁盘容量) | | **事务支持** | 简单事务(无 ACID,通过 Lua 脚本实现原子性) | 完整 ACID 特性(原子性、一致性、隔离性、持久性)| | **适用场景** | 缓存、实时计算、消息队列 | 复杂查询、事务处理、持久化业务数据存储 | | **扩展性** | 集群模式支持水平扩展 | 主从复制、分库分表(复杂度较高) | --- ### **详细对比分析** #### 1. **数据模型与查询能力** - **Redis** - **优势**:直接操作数据结构(例如:集合求交集、有序集合排序),无需解析 SQL。 - **局限**:无法实现关联查询(如 `JOIN`),过滤条件简单(仅支持键匹配或范围查询)。 - **示例**:获取用户 `user:1000` 的姓名 → `HGET user:1000 name`。 - **MySQL** - **优势**:通过 SQL 实现复杂查询(如多表关联、聚合函数、子查询)。 - **示例**:统计订单表中每个用户的消费总额 → ```sql SELECT user_id, SUM(amount) FROM orders GROUP BY user_id; ``` --- #### 2. **存储与性能** - **Redis** - **内存存储**:数据常驻内存,读写速度极快(例如:读取字符串值仅需 $O(1)$ 时间复杂度)。 - **持久化代价**:RDB 快照可能阻塞线程,AOF 日志写入影响吞吐量(需权衡性能与数据安全)。 - **典型场景**:缓存热门商品信息,QPS 从 MySQL 的 1万 提升到 Redis 的 10万+。 - **MySQL** - **磁盘存储**:数据持久化到磁盘,通过 Buffer Pool 缓存热点数据(内存不足时性能下降明显)。 - **索引优化**:通过 B+ 树索引加速查询(例如:主键查询 $O(\log N)$,全表扫描 $O(N)$)。 --- #### 3. **事务与一致性** - **Redis** - **弱事务**:`MULTI/EXEC` 命令仅保证命令顺序执行,不满足 ACID(无回滚机制)。 - **解决方案**:通过 Lua 脚本实现原子操作(例如:库存扣减的原子性校验)。 - **MySQL** - **强事务**:支持事务隔离级别(如 Read Committed、Repeatable Read),通过 Undo/Redo 日志保障一致性。 - **示例**:转账操作(原子性保障): ```sql BEGIN; UPDATE accounts SET balance = balance - 100 WHERE user_id = 'A'; UPDATE accounts SET balance = balance + 100 WHERE user_id = 'B'; COMMIT; ``` --- #### 4. **扩展性与成本** - **Redis** - **垂直扩展**:受单机内存限制,成本高(例如:64GB 内存服务器价格约 5000 元)。 - **水平扩展**:集群模式分散数据(需解决分片和数据迁移问题)。 - **MySQL** - **垂直扩展**:通过提升 CPU/内存/磁盘性能(成本可控,例如:1TB SSD 约 800 元)。 - **水平扩展**:分库分表复杂度高(需处理跨分片查询和事务)。 --- ### **协作使用建议** 1. **缓存加速** - 用 Redis 缓存 MySQL 热点数据(如商品详情),降低数据库压力。 - **注意**:需维护缓存一致性(可通过延迟双删或订阅 Binlog 同步)。 2. **实时统计** - 用 Redis 计数器(`INCR`)统计页面 PV,定时同步到 MySQL 持久化。 3. **削峰填谷** - 用 Redis 队列缓冲高并发请求(如秒杀订单),MySQL 异步处理。 --- ### **总结:如何选择?** - **选 Redis**:需要**低延迟、高并发、弱一致性**的场景(如缓存、排行榜)。 - **选 MySQL**:需要**复杂查询、强事务、海量数据持久化**的场景(如订单管理、财务系统)。 - **混合使用**:多数互联网系统同时使用两者(Redis 作缓存层,MySQL 作持久层)。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值