Mysql 优化从基础到落地 一 节

本文深入探讨Mysql慢查询的定义与作用,详细介绍慢查询日志的配置与分析,包括启动、配置参数、记录规则及分析工具mysqldumpslow的使用。同时,文章覆盖了数据库设计的三大范式及其在减少冗余中的应用,并提供了多种慢查询优化策略,如服务器硬件升级、Mysql服务器优化、SQL语句优化、反范式设计和索引优化等。

                                               Mysql 优化从基础到落地 一 节

 

● 慢查询, 找到值得优化的 SQL

慢查询的定义以及作用:

慢查询日志, 顾名思义   就是查询慢的日志, 是指 Mysql 记录所有执行 超过 long_query_time 参数设定的时间的 阀值 的 SQL 语句的 日志。  该日志能为 SQL 语句的优化 带来 很好的帮助。 默认情况下  慢查询日志是关闭的,  要使用慢查询日志功能  首先要开启慢 查询的日志功能 

 

启动慢查询:

常用配置

  • show_query_log                             启动 停止慢查询
  • show_query_log_file                      指定慢查询日志的 存储路径及 文件(默认和数据文件放在一起)
  • long_query_time                            指定记录慢查询日志 SQL 执行 时间的 阀值 (单位 秒, 默认  10秒)
  • log_queries_not_using_indexes    是否记录未使用的 索引的 SQL
  • log_output                                      日志存放的地方 [table]   [file]    [file, table]

● 记录符合条件的 SQL

  • 查询语句
  • 数据修改语句
  • 已经回滚的 SQL

 

 

下面是 其中的几条慢查询日志

  (单位毫秒)

  • query_time           :查询时间
  • lock_time              :执行获取 锁 的时间
  • row_sent              :获得结果时间
  • row_examined     :扫描的行数
  • set_ timestamp    :sql 执行的具体时间

 

慢查询 分析工具  mysqldumpslow

● 常用的 慢查询 日志分析工具   mysqldumpslow

汇总除查询 条件以外 完全相同的 SQL, 并将 分析结果 按照参数中指定的顺序输出

●  语法

mysqldumpslow -s r -t 10 slow-mysql.log

●  -s   排序参数 : c,t,l,r,at,ai,ar
   c            :总次数
   t            :总时间
   l            :总次数
   r            :总数行数
   at, al, ar / t,l,r   :平均数     at = 总时间 / 总次数

●  -t   指定取前面几天 作为结果输入:
 

 这个需要 安装 perl  来运行 mysqldumpslow.pl

perl 下载地址

#以总时间排序,取出前5条

C:\Program Files\MySQL\MySQL Server 8.0\bin>perl mysqldumpslow.pl -s t -t 5 C:\WIN-7781FQVPL6U-slow.log

 

慢的 SQL 语句 已经找到出来了,接下来我们来优化慢的 SQL

 

 

数据库设计的三大范式

        三大范式的主要作用: 减少冗余

● 第一大范式

  • 数据库表中的 所有字段 都 只具有 单一属性

  • 单一属性 的列是由 基本数据类型 所构成的

  • 设计出来的表 都是简单的 二维表

● 第二大范式

  • 要求表中只有一个业务主键, 也就是说符合第二范式的表  不能存在 非主键 列 只对部分主键的 依赖关系;   (每一行数据 需要有一个 主键 来区分)

● 第三大范式

指 每一个 非 主键属性 即不能 部分依赖 也不传递依赖  与 主键。(属性之间不要有关联)

 

 

 

 

 

常用的慢查询 优化方式:

服务器硬件      

  • SSD  比  HDD  高 10倍 左右                                               

Mysql 服务器优化    

  • linux  随着时间推移 会比  window 稳定 而且系统效能 更高                                      

SQL 本身优化                    

  • 子查询   优化为   关联查询                 

反范式设计优化

  • 反范式 是针对 范式而言的

  • 所谓的 反范式 优化    就是 为了 性能和 读取效率 考量 而 违反 数据库设计范式 进行的优化

  • 允许存在 少量的 冗余 来换取 缩短查询时间。 换句话说  使用空间来换取时间

索引优化

索引的定义:

索引(index)是帮助 Mysql 高效获取数据的 数据结构。可以得到 索引的本质: 索引是数据结构

索引的分类:

  • 普通索引: 一个索引只包含单个列,  一个表 可以包含多个单列索引                                idnex
  • 唯一索引: 索引列的值 必须唯一,     但是 允许为 null                                                      unique
  • 主键索引: 主键索引 是在创建 主键的时候, 自动添加的 索引唯一  且不能为 null            pramery key
  • 复合索引: 一个索引包含多个列

 

 

执行计划:

执行计划是什么:

使用 EXPLAIN 关键字 可以 模拟 优化器 执行 SQL 查询语句; 从而知道 是如何 处理你的 MYSQL 语句的。 分析你的查询语句 或者 表的结构性 瓶颈

语法:

Explain + SQL语句

  ● Explain 看是否 用到了 索引;     key 为 Null 则没有使用 到索引,   ley_len 索引  算法

    key_len       算法

    类型                           varchar                      char

    字符编码                      utf8                           3

    字符本身长度         

   ● 索引是否 充分使用,                     ley_len  的大小,数值越大   说明 索引利用的月充分

   ● Type 字段:                                   type  system > const > eq_ref > ref > range > index > ALL

 ●  ALL        全表扫描                     性能最低 
 ●  Index      全表扫描(索引表)

 

 

 

<think>嗯,用户想了解海量数据存储与优化的实现方案,包括数据库架构、分布式存储以及最佳实践。用户提到的"海量数据"通常指TB/PB级别数据,这确实需要系统化的解决方案。用户可能正在设计或维护个面临数据量激增的系统,需要可扩展的存储方案。从引用材料看,用户关注点集中在分布式技术和数据库架构优化上,特别是引用了分布式数据库相关内容(引用1、2、3)和存储层设计(引用4)。用户应该需要既理论又落地的方案。海量数据存储的核心矛盾在于:数据量指数增长vs硬件性能线性增长。解决方案必须多管齐下。参考工业界实践,准备从垂直拆分、水平扩展、缓存加速、存储引擎四个维度构建回答框架。垂直拆分是基础手段。引用4提到的文件系统层优化很关键,比如MySQL的独立表空间管理就属于此列。但单机总有极限,所以必须引入水平扩展。引用1提到的分表分库(5.4)和引用2的分布式数据库是重点,这里要区分两种模式:TiDB这类NewSQL和自定义分片方案,前者适合事务型场景,后者适合定制化需求。缓存层不可或缺。引用1开头就强调"在数据库之前使用缓存",这是七倍定律的体现——内存访问比磁盘快10^6倍。但要注意缓存穿透问题,需要设计空值缓存策略。存储引擎选择影响深远。引用4提到日志文件和数据文件的分离管理,这在LevelDB的LSM-tree设计中尤为明显。现代数据库如ClickHouse的列式存储对分析型海量数据很有效。用户可能还关心具体技术选型。比如分库分表中间件(ShardingSpherevsVitess),分布式数据库(TiDBvsCockroachDB),缓存组件(RedisvsMemcached)等。不过回复里不需要列举全部,重点说明架构原理即可。最后的最佳实践部分要强调监控。任何海量系统没有监控就像盲人骑马,必须包含分片均衡率、缓存命中率、慢查询比例等核心指标。相关问题设计围绕用户可能的后续需求:深度技术细(LSM-tree)、特定场景方案(时序数据)、扩展阅读方向(CAP理论应用)。这样既解答当前问题,又打开后续对话空间。</think>以下是海量数据存储优化的系统性方案,结合分布式架构与最佳实践: ### 、核心架构设计 1. **分层缓存体系** - 前端缓存(CDN/浏览器)→ 应用层缓存(Redis/Memcached)→ 数据库缓存(Buffer Pool) - **优化效果**:减少90%以上的数据库读请求[^1],如热点数据查询$Q_{hit}$命中率需 > 95%$ 2. **分布式数据库选型** | 类型 | 代表产品 | 适用场景 | |---|---|----| | **NewSQL** | TiDB/CockroachDB | 强致性事务 | | **分库分表** | ShardingSphere/MyCAT | 定制化分片 | | **列式存储** | ClickHouse | 实时分析 | 3. **数据分片策略** $$shard\_key = hash(user\_id) \mod N$$ - 动态扩容:通过致性哈希环减少数据迁移量 - 冷热分离:近3月热数据存SSD,历史数据归档至对象存储 ### 二、存储引擎优化 1. **LSM-Tree结构优化** - 写放大系数控制:$WAF = \frac{实际写入}{逻辑写入} \leq 5$ - Compaction策略:Leveled(读优) vs Tiered(写优) 2. **列式存储优势** ```plaintext 原始行存储: [UserID,Name,Age][1,"Alice",30][2,"Bob",25] 列式存储: UserID: [1,2] Name: ["Alice","Bob"] Age: [30,25] ``` - 压缩率提升50%+,OLAP查询速度提升10倍 ### 三、最佳实践案例 1. **微信支付分库方案** - 单元化部署:按地域划分数据库集群 - 异步复制:跨单元数据同步延迟 < 200ms - 流量调度:自动隔离故障分片[^3] 2. **阿里云PB级分析** - 三级存储: ```mermaid graph LR A[热数据] -->|OSS缓存| B[温数据] B -->|生命周期策略| C[冷归档] ``` - 成本降低70%:OSS归档存储单价$0.0015/GB/月 ### 四、关键技术指标 1. 吞吐量:$TPS = \frac{并发线程数}{平均响应时间(s)}$ 2. 持久化保证:RPO(恢复点目标) < 5s,RTO(恢复时间) < 30s 3. 扩展性:线性增长比 ≥ 0.8(资源增加1倍,性能提升80%+) > **架构警示**:分布式系统需在CAP中取舍——支付系统选CP(致性+分区容忍),推荐系统选AP(可用性+分区容忍)[^2]。重要业务慎用新兴分布式数据库,优先验证金融级稳定性[^1]。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

nicepainkiller

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值