SQL 慢查询日志、模拟分析海量数据、查询全局日志

本文详细介绍了MySQL慢查询日志的配置与使用,包括如何开启和设置阀值,利用mysqldumpslow工具进行慢SQL分析,以及通过存储过程和函数模拟海量数据插入,帮助读者掌握SQL调优技巧。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

SQL排查

--- 慢查询日志: MySQL提供的一种日志记录用于记录MySQK中响应时间超过 阀值 的 sql语句  (long_query)

慢查询日志默认是关闭

建议:开发调优是打开  而最终部署时关闭 

检查是否开启了慢查询日志

 show variables like '%slow_query_log';

临时开启:

set global slow_query_log=1

在内存开启

 

永久开启:

 

阀值: show variables like '%long_queury_time%';

临时设置阀值: set global long_queury_time = 5;

重新登录生效 不需要重启服务
 

永久设置阀值:

 

慢查询阀值和mysqldumpslow工具

查询超过阀值得sql : show global status like '%slow_queries';

cat /var/lib/mysql/localhost-slow.log

(2)通过mysqldumpslow工具查看慢sql 可以通过一些过滤条件  快速查找需要定位的慢sql

mysqldumpslow --help

s:order排序方式
r:逆序
l:锁定时间
g:正则匹配模式

-- 获取返回记录组多的3个sql : mysqldumpslow -s r -t 3  /var/lib/mysql/localhost-slow.log

-- 获取访问次数最多的3个SQL   mysqldumpslow -s c -t 3 /var/lib/mysql/localhost-slow.log

--- 按照时间排序,前10条包含left join 查询语句的sql  mysqldumpslow -s t -t  10 -g "left join"

 


分析海量数据

用存储过程 、存储函数  模拟海量数据 

通过存储函数 插入海量数据

创建存储函数: 存储过程 无return 存储函数 有return

delimiter $
create function randString(n int) returns varchar(255)
begin
      declare all_str varchar(100)default 'abcdefg.....' 
      declare return_str varchar(255) default '';
      declare i int default 0;
      while i<n
      do
       set return_str - concat(return_str.substring(all_srt,FLOOR(rand()*52)+1,1) );
       set i=i+1;       
      end while;
      return return_str; 
end $ 
--产生随机整数
delimiter $
create function ran_run() returns int(5)
begin
      declare i int default  0
     set i - floor(rand()*100);
     return i;   
end $ 

create produre insert_emp(in eid_start int(10), in data_times int(10))

begin 
    declare i int default 0;
    set autocommit = 0; --关闭自动提交
  
    repeat 
  
         insert into emp values(eid_start + i ,randstring(5), 'other' ,ran_nu())
        set i=i+1;
       until i = data_times
     end repeat;
    commit;
end $
- - 通过存储过程插入海量数据,dept表中
create produre insert_dept(in dno_start int(10), in data_times int(10))

begin 
    declare i int default 0;
    set autocommit = 0; --关闭自动提交
  
    repeat 
        insert into dept values(dno_start + i ,randstring(6), randstring(8))
        set i=i+1;
       until i = data_times
     end repeat;
    commit;
end $

- - 插入数据

delimiter ;
call insert_emp (1000,800000);
call insert_dept(10,30);

 

show profiles

show variables like '%profiling’

set profiling = on;  
 

查询全局日志

这些全局的记录操作 仅仅在开发和调优过程中打开即可,部署时一定要关闭

show variables like '%general_log%';

- - 执行的所有sql记录在表中
set global general_log = 1

set global log_output ='table'

- -执行的所有sql记录在文件中
set global log_output ='file'

set global general_log_file ='/tmp/general.log'

set global general_log= 1

开启全局日志  会记录所有sql : 会被记录 到 mysql.general_log表中。

select * from mysql.general_log

 

 

<think>我们正在讨论消息队列中的数据去重问题。根据引用内容,重复消费的解决方案包括:设计幂等性处理逻辑、使用分布式锁、在消费者端实现消息去重机制(如布隆过滤器或记录已处理的消息ID)。用户的问题是如何在消息队列中确保数据不被重复消费,因此我们需要围绕这些方法展开。 设计思路: 1. 首先解释重复消费的原因(引用中提到了生产时和消费时的重复)。 2. 然后详细说明解决重复消费的几种方法,重点包括幂等性设计、分布式锁、消息去重机制(如布隆过滤器、哈希表记录消息ID)。 3. 结合引用内容,强调幂等性的重要性(引用[1]和[3]都提到幂等性处理)。 4. 可以给出一个简单的示例(伪代码或描述性代码)来说明如何实现幂等性。 注意:引用[4]提到“确保消费端只执行一次”和“保证消费方幂等性”,这也与我们的主题一致。 由于用户要求结构清晰,我们将分步骤回答。 回答结构: 1. 重复消费的原因 2. 解决方法概述 3. 详细阐述每种方法 4. 示例说明(可选) 5. 总结 同时,生成相关问题。</think>### 消息队列数据去重机制设计方法 在消息队列中确保数据不被重复消费的核心是**设计幂等性消费机制**,结合多种技术手段实现。以下是系统化的解决方案: --- #### 一、重复消费的根本原因 1. **生产端重复** 网络超时导致生产者重发(如MQ未及时ACK) 2. **消费端重复** 消费者处理成功但ACK失败,消息被重新投递 3. **系统故障** 消费者崩溃后重启,未完成消息被重新分配 --- #### 二、核心去重机制设计 1. **幂等性设计(根本解决方案)** - **定义**:相同输入多次执行结果一致 - **实现方式**: - **数据库唯一约束**:业务ID+状态字段建立唯一索引 ```sql ALTER TABLE orders ADD UNIQUE (order_id, status); ``` - **乐观锁控制**:基于版本号更新 ```sql UPDATE account SET balance=balance-100, version=version+1 WHERE user_id=123 AND version=current_version; ``` 2. **消息唯一标识追踪** - **全局消息ID**:生产者生成唯一ID(如UUID/Snowflake) - **去重表存储**:消费者记录已处理ID(需考虑存储成本) ```java // 伪代码示例 if (!redis.setnx(msgId, "processed")) { return; // 已存在则跳过 } ``` 3. **分布式锁控制** - **流程**:消费前获取业务键锁 → 处理 → 释放锁 ```python lock = distributed_lock.acquire(key=order_id, ttl=30s) if lock: process_message() lock.release() ``` 4. **布隆过滤器(海量数据场景)** - 空间效率极高,允许少量误判(需配合其他机制) $$ P_{false} \approx \left(1 - e^{-kn/m}\right)^k $$ 其中$k$=哈希函数数,$m$=比特数组大小,$n$=元素数量 --- #### 三、分层防护策略 | 层级 | 技术手段 | 适用场景 | |-------------|------------------------------|-----------------------| | **传输层** | MQ自带消息ID去重(如RocketMQ)| 基础防护 | | **存储层** | Redis SETNX/数据库唯一索引 | 高频小数据量 | | **业务层** | 状态机+版本控制 | 金融/交易等高敏感场景 | --- #### 四、实践建议 1. **组合使用**:布隆过滤器前置过滤 + 数据库最终校验 2. **时效控制**:Redis键设置TTL避免永久存储膨胀 3. **熔断机制**:异常重复量阈值触发告警(如10s内相同消息>3次) 4. **压测验证**:模拟网络分区与节点故障测试幂等性 > 关键原则:**去重成本应与业务价值匹配**——普通日志可允许少量重复,支付交易需严格防护[^1][^3][^4]。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值