技术 - DevOps

🧐 为什么 HttpServletRequest 的 Body 只能被读取一次？

它触及了 Java Web容器（Servlet规范） 处理 HTTP请求体（Request Body） 的核心机制，以及 输入/输出流（IO Stream） 的基本特性。

🧐 为什么 HttpServletRequest 的 Body 只能被读取一次？

核心原因在于 HTTP 协议和 Java I/O 流的本质，尤其是对于 流式数据 (Streamed Data) 的处理。

1. HTTP 请求体的本质是“输入流” (Input Stream)

在 Java Web 应用中，当服务器接收到一个 HTTP 请求时，请求的 Header（如方法、路径、Content-Type）会被解析成字符串/集合等对象，但请求的 Body（如 POST/PUT 请求中的 JSON、XML、文件内容）通常是一个 字节序列。

Web 容器（如 Tomcat）不会一次性将整个 Body 加载到内存中，而是将其暴露为一个 ServletInputStream（通过 request.getInputStream() 获取）。

  • 流（Stream） 的概念就像水管里的水流：数据是按顺序从源头（客户端）流向目的地（服务器）的。

  • 读取（Read） 意味着水被抽走了。一旦一个字节的数据被读取并处理，它就从流中消耗掉了，无法回溯。

  • 这种设计是出于对 性能和内存 的优化，特别是处理 大文件上传 或 超大请求体 时。如果每次请求都必须把整个 Body 缓存起来，服务器很快就会耗尽内存（OOM）。

2. 对比 List 或 Map 等集合

您提到 List 和 Map 可以多次读取，这是因为它们是 内存中的数据结构 (In-Memory Data Structures)。

继续阅读
技术 - DevOps

redis 中的lua脚本是如何执行的?

Redis 中 Lua 脚本的执行机制

1. Lua 脚本是如何执行的？

Redis 使用 EVAL 和 EVALSHA 命令执行 Lua 脚本：

1
2
3
4
5
6

-- EVAL 命令格式
EVAL "return {KEYS[1],KEYS[2],ARGV[1],ARGV[2]}" 2 key1 key2 arg1 arg2

-- EVALSHA 使用脚本的 SHA1 校验和执行
SCRIPT LOAD "return 'hello'"
EVALSHA <sha1_hash> 0

执行特点：

  • 原子性：脚本作为一个整体执行，期间不会被其他命令打断
  • 单线程：Redis 单线程执行，避免并发问题
  • 事务性：优于 Redis 事务（MULTI/EXEC），没有事务失败问题

2. Lua 脚本以什么形式存在于 Redis 中？

脚本在 Redis 中以两种形式存在：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

-- 1. 临时形式：EVAL 直接执行（不持久化）
EVAL "return redis.call('GET', 'foo')" 0

-- 2. 缓存形式：SCRIPT LOAD 后缓存在内存中
SCRIPT LOAD "return redis.call('GET', 'foo')"
-- 返回 SHA1: 6b1bf486c81ceb7edf3c093f4c48582e38c0e791
-- 脚本会缓存在服务器的脚本缓存字典中

-- 查看缓存中的所有脚本
SCRIPT EXISTS <sha1> <sha2>...

-- 清空脚本缓存
SCRIPT FLUSH

存储特点：

继续阅读
技术 - DevOps

HTTP 响应html时body体的分块行为

你观察到的这个现象非常有意思！这通常是由以下几种情况造成的：

1. 分块传输编码（Chunked Transfer Encoding）

这是最常见的原因。当服务器使用 Transfer-Encoding: chunked 时，响应体会被分成多个块传输。

示例结构：

1
2
3
4
5
6
7

HTTP/1.1 200 OK
Content-Type: text/html;charset=utf-8
Transfer-Encoding: chunked

2000          ← 第一个块的大小（16进制，8192字节）
{...json数据...}  ← 实际的数据内容
0             ← 结束块（大小为0）

Wireshark 显示示例：

1
2
3
4
5
6
7
8

HTTP/1.1 200 OK\r\n
Content-Type: text/html;charset=utf-8\r\n
Transfer-Encoding: chunked\r\n
\r\n
2000\r\n
{"status": "success", "data": [...]}\r\n
0\r\n
\r\n

2. 自定义的响应格式

有些框架或中间件会添加自定义的头部信息：

1
2
3
4

// 类似这样的服务器端代码可能产生这种格式
response.getWriter().println("2000");  // 自定义长度标识
response.getWriter().println(jsonData);
response.getWriter().println("0");     // 结束标识

3. 调试或监控信息

开发环境中的中间件可能添加调试信息：

继续阅读
技术 - DevOps

mysql 分析执行计划

完全不用担心！记不住 EXPLAIN 的输出字段是非常正常的，因为它包含的信息确实很多。这其实不是一个需要死记硬背的东西，而是一个需要理解其核心思想并通过查看来熟练使用的工具。

下面我给您一个超实用的 “三步速查指南” 和 核心字段详解，您以后遇到就翻出来看，看多了自然就熟了。

三步速查指南：如何快速判断SQL性能？

拿到一条 EXPLAIN 结果，不要一个个字段看晕了，按照这三个步骤来分析：

✅ 第一步：先看 type 列（访问类型）—— 这是最重要的指标！

这列告诉你 MySQL 如何查找数据。从好到坏排列，理想状态是尽量靠前：

类型 (值)含义性能解读
system系统表，只有一行数据最佳忽略，极少见。
const通过主键或唯一索引一次就找到极佳WHERE id = 1，效率最高。
eq_ref联表查询时，使用主键或唯一索引关联极佳常见于 A JOIN B ON A.id = B.id。
ref使用普通非唯一索引查找优秀WHERE name = 'Alice'（name是普通索引）。
range索引范围扫描良好WHERE id > 100，BETWEEN，IN。
index全索引扫描较差比全表扫描好点，但需要扫描整个索引树。
ALL全表扫描最差警报！ 性能杀手，需要优化。

您的例子解读： type: ALL -> 这是最坏的情况，说明MySQL正在对 com_order 表进行全表扫描，性能极差。

继续阅读
技术 - DevOps

慢查询排行榜

事先申明 这项目不是我写ヾ(o◕∀◕)ﾉヾ

Profile
Rank Query ID                            Response time   Calls  R/Call  
==== =================================== =============== ====== ======= 
   1 0x43213F365998840ACD9C3079B9E87DAE  857789.5898 ... 230501  3.7214  0.47 SELECT com_order
   2 0xDF3E01C0AD745FDFF16601E364C36572  107786.6011 ...   7621 14.1434  8.21 SELECT com_order_step
   3 0x8F9F477B37A66516C7CD43B477D3A270  68362.6915  ...   3105 22.0170  4.60 UPDATE com_order_detail
   4 0x4A0BE95958C84E7A96EDFB2C21FB67C1  61784.0898  ...  18351  3.3668  0.05 SELECT com_order
   5 0x118C6D89A59CD6963430E2D2D19BB258  47610.6692  ...  11604  4.1030  0.19 SELECT com_order
   6 0xE53F09B2262794BEC6E2688CAA143431  45380.2740  ...  12985  3.4948  0.06 SELECT com_order com_goods_co
   7 0x2C3A955FE023BE233878F80DEBE1C7F5  45306.2355  ...  10324  4.3884  2.03 SELECT com_order
   8 0x881AF4FC304C67F886CE7F4B92F5F836  32297.1495  ...   2164 14.9247  2.56 SELECT com_order com_goods co
   9 0xE2B66B13B936E38828F345F8840CB173  17972.5383  ...    943 19.0589  3.67 SELECT com_order com_goods co
  10 0xBA63E58F684365ED5EF9EBECF6211154  12255.0037  ...    633 19.3602  1.64 SELECT com_order com_goods co
  11 0x9AF174602EBD35D03339D52BD6BA454A  6755.3975  0.5%    976  6.9215  0.58 SELECT com_goods com_order
  12 0xAE8DB0A6FE47D628D931A483CCAE8A75  6587.3134  0.5%    737  8.9380  3.80 SELECT com_order com_goods co
  13 0x41CD552DAEB5C20B6442CE78748915D4  6388.0521  0.5%   1074  5.9479  0.38 SELECT com_goods com_order
  14 0x5821670C589337A3F5230781CA62B830  5463.3930  0.4%   1452  3.7627  0.88 UPDATE com_order
  17 0x29284E1C020294A86F3B5089534E1F25  3770.1613  0.3%    130 29.0012  0.02 SELECT com_order com_goods co
  18 0x4FD4F24768F143A7E142658B51C74256  3136.3929  0.2%    285 11.0049  5.74 SELECT com_order com_goods co
  19 0x7D5D8A24C7C014336145D6174DD83F54  3082.0708  0.2%    183 16.8419  1.81 SELECT com_order com_goods co
  20 0x827B61B85C77531BFAD687333071E9C2  2498.9570  0.2%    640  3.9046  1.01 SELECT com_goods com_order
  21 0x92DB913CB9BC963C7C2815C23F00603E  2251.8580  0.2%     75 30.0248  0.00 INSERT com_order_step
  22 0x1E42A48C29626389B6911D90A3C7BE41  2137.8542  0.2%     69 30.9834  1.65 INSERT com_order_detail
  23 0x55FA21C415B57A8C8BEE934489C5C092  2030.6716  0.1%    486  4.1783  0.17 SELECT com_order com_goods co
  24 0xB7098BC79C0AF47C49F17C710D3D3357  1920.8152  0.1%     64 30.0127  0.00 INSERT com_order
  25 0x3718B70A1AD6C2B67B67703C6EBE839C  1704.2796  0.1%    456  3.7375  0.01 SELECT com_order
  26 0x1FA49422BC44151C0D4FA0D8AA44BB27  1659.9687  0.1%    120 13.8331  0.01 SELECT com_order com_goods co
  27 0x5A7C30146FFACC7F55CC11096B93B354  1607.1963  0.1%    442  3.6362  0.28 SELECT com_order
  30 0x43D8E9778CDD92BE946D19B37645F74C  1196.9710  0.1%    218  5.4907  2.59 SELECT com_order_detail com_o
  31 0xFB9EE232DEF62B88A9E803150ABE2D9D  1163.1644  0.1%     52 22.3685  3.58 SELECT ers_cash_list com_orde
  32 0x342763F4807710266FE036FD2AC058B9  1137.1729  0.1%     59 19.2741  4.43 SELECT ers_cash_list com_orde
  33 0x37AE68F96E70CDFF548417176CAEB2AF  1002.2846  0.1%    209  4.7956  0.64 SELECT com_goods com_order
  34 0xCFD2BFF2205FD63DD0FF201E7734D7FD   865.9522  0.1%    178  4.8649  0.17 SELECT com_goods com_order
  35 0x6AF371BEED556B36FD41230774042645   810.7413  0.1%     27 30.0275  0.00 UPDATE com_order
  36 0xFB49BD352A70DA19A7B45E49CA0FB56A   755.3083  0.1%     82  9.2111  0.01 SELECT com_order com_goods co
  37 0x591DFEABF77D53A9DB97E97F66DB2BCC   686.2606  0.0%    173  3.9668  0.22 SELECT com_order com_goods co
  38 0xAD6FBF179A5CC50419715DCE46FC7EB1   682.1636  0.0%    182  3.7482  0.11 SELECT ers_cash_list com_orde
  39 0xE360E29586DD3B1FA65F5AE61988A6CB   676.1795  0.0%    141  4.7956  0.24 SELECT com_order com_goods co
  40 0xCB8BD72D494052A7A56DD28BDDFDCBDC   657.7839  0.0%     87  7.5607  0.47 SELECT com_order com_goods co
  41 0xB1E04439EF51C794A915EB4866531585   537.9265  0.0%    153  3.5159  0.01 SELECT com_order com_goods co
  42 0x594D5C2699347573F74DE0CDC2CEFC32   529.2930  0.0%     20 26.4647  0.55 SELECT ers_cash_list com_orde
  43 0x27D2F92EBA60A1D41619A371781312A2   503.5509  0.0%     96  5.2453  0.00 SELECT com_order com_goods co
  44 0xD3F5CCA83C841835CC79BAE5E68A8CFF   496.4855  0.0%    132  3.7613  0.10 SELECT ers_cash_list com_orde
  45 0x7D3AA779A8224BC6F6C452E880162A64   475.0059  0.0%     55  8.6365  1.97 SELECT com_order_detail com_o
  46 0xB5A0A353B20D286F197F13E71BBAFC81   444.7246  0.0%    117  3.8011  0.37 SELECT com_order
  47 0xC695CA39DA1088B7ED82E1BEB33B4B7B   419.5935  0.0%     15 27.9729  0.46 SELECT ers_cash_list com_orde
  48 0xB10F790621F5CA1C97B99EAA126E00B2   346.4819  0.0%     17 20.3813  4.26 SELECT ers_cash_list com_orde
  50 0x0C170F407F3F8F9BA2A097013DF2317A   333.6224  0.0%     24 13.9009  2.32 SELECT ers_cash_list com_orde

就贴出前五十个,留作纪念;

继续阅读
技术 - DevOps

mysql慢日志分析--头部数据解读

起因:

领导突发奇想使用阿里云的dns解析做负载均衡,我感觉他之前可能只做过单机项目,所以想体验负载均衡,其实目前生产系统的业务量远远打不满的单机节点的,领导做事情不需要向大头兵解释,咱也不晓得他啥时候改的解析,事后来记录一下盘查慢日志的过程.

关于阿里云的域名dns

解析能配置多个ip,正常来说不会使用这种方式去做负载均衡,因为dns解析生效时间不可控,修改解析生效时间需要等待很长时间,阿里云要同步全球dns服务器,不同的客户端ip访问的dns服务器可能得到不同的结果.

特别是当你某台机器故障时,你是没办法即时清理掉这个故障节点的;

分析慢查询日志使用的工具是 pt-query-digest,下面是分析后的文件头部,汇总统计:

40.3s user time, 210ms system time, 68.71M rss, 263.14M vsz
Current date: Fri Aug 29 17:19:51 2025
Hostname: VM-0-13-centos
Files: mysql-slow.log
Overall: 308.93k total, 300 unique, 0.03 QPS, 0.15x concurrency ________
Time range: 2025-05-15T17:37:29 to 2025-08-29T09:19:39
Attribute          total     min     max     avg     95%  stddev  median
============     ======= ======= ======= ======= ======= ======= =======
Exec time        1384350s      3s   4979s      4s      6s     13s      4s
Lock time           230s       0     14s   743us   144us    61ms   103us
Rows sent         33.29M       0   2.37M  113.00  487.09   8.40k    0.99
Rows examine     629.53G       0 259.56M   2.09M   2.26M   1.90M   1.95M
Query size        46.40M       8 108.83k  157.50  271.23  308.67  124.25

这是一个MySQL慢查询日志分析报告的开头部分，逐行解释：

第2行 - 系统资源使用情况

1

# 40.3s user time, 210ms system time, 68.71M rss, 263.14M vsz
  • 40.3s user time: 用户态CPU时间，表示分析工具本身运行了40.3秒
  • 210ms system time: 内核态CPU时间，系统调用耗时210毫秒
  • 68.71M rss: 常驻内存集大小，程序实际使用的物理内存约68.71MB
  • 263.14M vsz: 虚拟内存大小，程序分配的虚拟内存约263.14MB

第3-6行 - 基本信息

1
2
3
4

# Current date: Fri Aug 29 17:19:51 2025
# Hostname: VM-0-13-centos
# Files: mysql-slow.log
# Overall: 308.93k total, 300 unique, 0.03 QPS, 0.15x concurrency ________
  • 分析时间：2025年8月29日17:19:51
  • 主机名：VM-0-13-centos
  • 分析文件：mysql-slow.log
  • 总体统计：
    • 308.93k total: 总共308,930条慢查询记录
    • 300 unique: 300种不同的查询模式
    • 0.03 QPS: 平均每秒0.03个查询（非常低）
    • 0.15x concurrency: 平均并发度0.15

第7行 - 时间范围

1

# Time range: 2025-05-15T17:37:29 to 2025-08-29T09:19:39

慢查询日志覆盖的时间范围：从2025年5月15日到8月29日，跨度约3个多月

继续阅读
技术 - DevOps

pt-query-digest 完全指南：从入门到高级实战

一、什么是 pt-query-digest？

pt-query-digest 是 Percona Toolkit 中的明星工具，用于分析 MySQL 慢查询日志。它能够将庞大的慢日志文件转化为易懂的性能分析报告，帮助DBA快速定位数据库性能瓶颈。

二、安装与配置

安装方法

1
2
3
4
5
6
7
8

# CentOS/RHEL
sudo yum install percona-toolkit

# Ubuntu/Debian
sudo apt-get install percona-toolkit

# 使用docker
docker run -it --rm -v $(pwd):/data percona/percona-toolkit pt-query-digest --version

启用MySQL慢查询日志

1
2
3
4
5

-- 在MySQL中执行
SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 2;      -- 超过2秒的查询记录
SET GLOBAL slow_query_log_file = '/var/log/mysql/slow.log';
SET GLOBAL log_queries_not_using_indexes = 'ON';

三、基础使用

1. 基本分析

1
2
3
4
5
6
7
8

# 最简单的分析
pt-query-digest /var/log/mysql/slow.log

# 输出到文件
pt-query-digest slow.log > slow_report.txt

# 分析最近的文件
pt-query-digest /var/log/mysql/slow.log --since="24h"

2. 排序和限制

1
2
3
4
5
6
7
8

# 按执行时间排序，显示前10条
pt-query-digest slow.log --order-by=Query_time:sum --limit=10

# 按锁定时间排序
pt-query-digest slow.log --order-by=Lock_time:sum --limit=5

# 按执行次数排序
pt-query-digest slow.log --order-by=Count:sum --limit=10

3. 过滤特定查询

1
2
3
4
5
6
7
8

# 只分析SELECT语句
pt-query-digest slow.log --filter '$event->{arg} =~ m/^SELECT/i'

# 分析特定表的查询
pt-query-digest slow.log --filter '$event->{arg} =~ m/users/i'

# 排除特定用户
pt-query-digest slow.log --filter '$event->{user} !~ m/root/i'

四、中级应用

1. 生成不同类型的报告

1
2
3
4
5
6
7
8

# 生成HTML报告
pt-query-digest slow.log --report-format=html > report.html

# 生成JSON格式
pt-query-digest slow.log --report-format=json > report.json

# 详细查询报告
pt-query-digest slow.log --report-format=query_report

2. 时间范围分析

1
2
3
4
5
6
7
8

# 分析特定时间范围
pt-query-digest slow.log --since="2025-08-28 00:00:00" --until="2025-08-29 23:59:59"

# 分析最近12小时
pt-query-digest slow.log --since="12h"

# 分析特定时间段（每天9点到18点）
pt-query-digest slow.log --time-range="09:00-18:00"

3. 对比分析

1
2
3
4
5
6

# 两个时间段的对比
pt-query-digest slow.log --since="2025-08-20" --until="2025-08-25" > week1.txt
pt-query-digest slow.log --since="2025-08-26" --until="2025-08-29" > week2.txt

# 使用review模式存储历史数据
pt-query-digest slow.log --review h=localhost,D=monitor,t=query_review

五、高级实战技巧

1. 实时监控分析

1
2
3
4
5

# 实时分析当前进程
pt-query-digest --processlist h=localhost --interval 0.01 --print --no-stream

# 监控并只显示慢查询
pt-query-digest --processlist h=localhost --filter '$event->{Time} > 2' --interval 1

2. 高级过滤技巧

1
2
3
4
5
6
7
8

# 复合过滤：查询时间大于5秒且扫描行数大于10000
pt-query-digest slow.log --filter '$event->{Query_time} > 5 && $event->{Rows_examined} > 10000'

# 特定数据库和用户
pt-query-digest slow.log --filter '$event->{db} eq "mydb" && $event->{user} eq "app_user"'

# 错误查询分析
pt-query-digest slow.log --filter '$event->{Error} ne ""'

3. 生成可执行的优化建议

1
2

# 生成创建索引的建议
pt-query-digest slow.log --report-format=query_report --filter '$event->{Rows_examined} > 100000' | grep -A5 -B5 "SELECT\|UPDATE\|DELETE"

4. 与Explain结合分析

1
2
3
4
5

# 提取需要分析的SQL语句
pt-query-digest slow.log --order-by=Query_time:sum --limit=5 --output=slow_queries.sql

# 然后手动执行EXPLAIN分析
mysql -e "EXPLAIN SELECT * FROM users WHERE created_at > '2025-01-01';"

六、解读分析报告

报告关键指标解读

1
2
3
4
5
6
7
8

# Overall: 308.93k total, 300 unique, 0.03 QPS, 0.15x concurrency
# Time range: 2025-05-15T17:37:29 to 2025-08-29T09:19:39
# Attribute          total     min     max     avg     95%  stddev  median
# ============     ======= ======= ======= ======= ======= ======= =======
# Exec time        1384350s      3s   4979s      4s      6s     13s      4s
# Lock time           230s       0     14s   743us   144us    61ms   103us
# Rows sent         33.29M       0   2.37M  113.00  487.09   8.40k    0.99
# Rows examine     629.53G       0 259.56M   2.09M   2.26M   1.90M   1.95M
  • Exec time: 查询执行时间，关注max和95%值
  • Rows examine: 扫描行数，值过大说明索引问题
  • Rows sent: 返回行数，与扫描行数比值越小越好
  • Lock time: 锁等待时间，过高可能有锁竞争

七、实战案例

案例1：分析并优化慢查询

1
2
3
4
5
6
7

# 1. 找出最耗时的查询
pt-query-digest slow.log --order-by=Query_time:sum --limit=3

# 2. 查看具体查询的执行计划
pt-query-digest slow.log --filter '$event->{fingerprint} =~ m/SELECT.*users/' --output=explain_queries.sql

# 3. 生成优化建议

案例2：监控生产环境实时性能

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

#!/bin/bash
# realtime_monitor.sh

while true; do
    echo "=== $(date) ==="
    pt-query-digest --processlist h=localhost \
                    --filter '$event->{Time} > 2' \
                    --order-by=Time:max \
                    --limit=5
    sleep 30
done

案例3：每日性能报告

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

#!/bin/bash
# daily_report.sh

DATE=$(date +%Y%m%d)
REPORT_FILE="/tmp/mysql_report_$DATE.html"

pt-query-digest /var/log/mysql/slow.log \
                --since="24h" \
                --report-format=html \
                > $REPORT_FILE

# 发送邮件报告
mail -s "MySQL Daily Report $DATE" dba@company.com < $REPORT_FILE

八、常见问题排查

1. 内存不足处理

1
2

# 分析大文件时使用分段处理
pt-query-digest slow.log --memory-limit=1G --chunk-size=100000

2. 网络分析

1
2

# 分析远程数据库
pt-query-digest --processlist h=db-prod.example.com,u=monitor,p=password --interval=5

3. 批量处理多个文件

1
2

# 分析多个慢日志文件
pt-query-digest /var/log/mysql/slow.log*

九、最佳实践

  1. 定期分析：设置每天自动分析慢日志
  2. 建立基线：保存历史报告用于对比
  3. 重点关注：95%百分位的值比平均值更重要
  4. 结合监控：与Prometheus、Grafana等监控系统结合
  5. 团队协作：将报告分享给开发团队共同优化

十、总结

pt-query-digest 是MySQL性能优化不可或缺的工具。从简单的日志分析到复杂的性能监控，它都能提供有价值的见解。掌握这个工具，你就能：

继续阅读
技术 - DevOps

mysql慢查询相关的属性

– 查看慢查询日志是否开启以及日志文件位置 SHOW VARIABLES LIKE ‘slow_query_log%’;

– 查看慢查询的时间阈值（单位：秒） SHOW VARIABLES LIKE ’long_query_time';

– 查看是否记录未使用索引的查询（即使它们执行得很快） SHOW VARIABLES LIKE ’log_queries_not_using_indexes';

– 查看慢查询日志的输出方式（FILE 或 TABLE） SHOW VARIABLES LIKE ’log_output';

继续阅读
技术 - DevOps

慢查询sql分析工具:percona-toolkit安装

方法一：添加Percona官方Yum源（推荐）

1. 安装Percona的yum仓库

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# 下载并安装Percona的yum源
sudo yum install https://repo.percona.com/yum/percona-release-latest.noarch.rpm

# 启用Percona Toolkit仓库
sudo percona-release enable tools release

# 更新yum缓存
sudo yum makecache

# 安装percona-toolkit
sudo yum install percona-toolkit

方法二：使用EPEL仓库

1. 首先安装EPEL仓库

1
2
3
4
5

# 安装EPEL仓库
sudo yum install epel-release

# 再次尝试安装
sudo yum install percona-toolkit

方法三：直接下载RPM包安装

1. 手动下载并安装

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# 查看系统架构
arch

# 如果是x86_64架构，下载对应的RPM包
wget https://repo.percona.com/yum/release/7/RPMS/x86_64/percona-toolkit-3.5.5-1.el7.x86_64.rpm

# 安装下载的RPM包
sudo yum install percona-toolkit-3.5.5-1.el7.x86_64.rpm

# 或者使用rpm命令直接安装
sudo rpm -ivh percona-toolkit-3.5.5-1.el7.x86_64.rpm

方法四：使用tar包安装（无需root权限）

1. 下载二进制tar包

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

# 下载最新版本的tar包
wget https://www.percona.com/downloads/percona-toolkit/3.5.5/binary/tarball/percona-toolkit-3.5.5_x86_64.tar.gz

# 解压
tar -zxvf percona-toolkit-3.5.5_x86_64.tar.gz

# 进入目录
cd percona-toolkit-3.5.5

# 直接使用pt-query-digest
./bin/pt-query-digest --help

# 或者添加到PATH
echo 'export PATH=$PATH:/path/to/percona-toolkit-3.5.5/bin' >> ~/.bashrc
source ~/.bashrc

验证安装

安装完成后验证：

继续阅读
技术 - DevOps

redis配置文件--gemini解读

好的，这是您提供的 Redis 配置文件（redis.conf）中注释部分的中文翻译。我将按照原文的结构和段落，为您逐一翻译。

配置注释翻译

文件头部（General）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

# 请注意，为了读取配置文件，Redis 必须以文件路径作为第一个参数启动：
#
# ./redis-server /path/to/redis.conf

# 单位说明：当需要指定内存大小时，可以使用常见的形式，如 1k, 5GB, 4M 等：
#
# 1k => 1000 字节
# 1kb => 1024 字节
# 1m => 1000000 字节
# 1mb => 1024*1024 字节
# 1g => 1000000000 字节
# 1gb => 1024*1024*1024 字节
#
# 单位不区分大小写，因此 1GB、1Gb 和 1gB 都表示相同的值。

模块 (MODULES)

继续阅读