zoukankan      html  css  js  c++  java
  • 8.1 Optimization Overview

    8.1 Optimization Overview  
    
    8.1 Optimization Overview
    8.2 Optimizing SQL Statements     
    8.3 Optimization and Indexes     
    8.4 Optimizing Database Structure     
    8.5 Optimizing for InnoDB Tables     
    8.6 Optimizing for MyISAM Tables     
    8.7 Optimizing for MEMORY Tables
    8.8 Understanding the Query Execution Plan     
    8.9 Controlling the Query Optimizer     
    8.10 Buffering and Caching     
    8.11 Optimizing Locking Operations     
    8.12 Optimizing the MySQL Server     
    8.13 Measuring Performance (Benchmarking)     
    8.14 Examining Thread Information     
    
    本章节介绍如何优化MySQL 性能和提供例子,优化涉及配置,调优和性能测量,
    
    在几个层次。这取决于你的工作角色(开发,DBA或者两者的结合),
    
    你可以优化在单个SQL层面, 整个应用,或者一个单独的数据库服务器,或者多个网络数据库服务器。
    
    有时候你可以主动和规划性能,当其他时间你可能处理一个配置或者代码执行在一个问题发生后,
    
    优化CPU 和内存使用可以改善可扩展性,允许数据库处理更多负载没有缓慢的情况下
    
    
    8.1 Optimization Overview  优化概述:
    
    数据库性能 取决于数据库层面的几个因素,比如表,查询和配置设置。
    
    那些软件构造引起CPU和I/O 操作在硬件层面,你必须最小化和尽可能的有效。
    
    
    当你从事数据库性能,你通过学习高层面规则和准则用于软件一侧,
    
    
    
    和维护性能使用墙上时间。当你变为一个专家,你了解很多关于内部发生的,
    
    开始测量东西比如CPU 周期和I/O 操作。
    
    
    典型的用户目标是得到更好的数据库性能 在现有的软件和硬件配置.
    
    
    高级用户寻找机会提高MySQL 软件本身,或者开发它们自己的存储引擎和硬件应用来扩展MySQL 生态系统
    
    
    数据库层面优化:
    
    最重要的因素在让一个数据库应用快是它的基本设计:
    
    1. 表结构正确吗?特别是,确定columns有正确的数据类型,
    
    确保每个表有合适的列对于工作的类型?比如, 应用执行频繁更新经常是很多表的少量列,
    
    当应用 分析大量的数据经常是几个表的很多列
    
    是否有正确的索引让查询更有效
    
    是否使用合适的存储引擎对于每个表,并利用每个存储引擎的优势和功能
    
    特别的,你选择一个事务存储引擎比如InnoDB 或者一个非事务存储引擎 比如MyISAM 是非常重要的
    
    对于性能和扩展。
    
    
    注意;
    
    在MySQL 5.5和更高的版本,InnoDB 是默认的存储引擎对于新的表。
    
    实际上, InnoDB 性能优势意味着InnoDB 表可以比MyISAM表性能好,尤其对于繁忙的数据库
    
    
    每个表 使用一个合适的行格式?这个选择也取决于表使用的存储引擎。特别的,
    
    压缩表使用更少的磁盘和需要更少的io 来读和写。压缩是可用的对于所有类型的负载使用InnoDB, 和对于只读的MyISAM表。
    
    
    应用程序使用一个合适的锁策略? 比如,通过允许共享访问,数据库操作可以并发运行,
    
    
    请求独占访问当适当的 这样特定的操作可以得到优先级。
    
    再次, 存储引擎的选择是重要的。
    
    
    InnoDB 存储引擎处理很多锁问题不需要你参与,允许更好的并发在数据库和降低实验和优化你的代码
    
    
    所有的内存区域用于正确的cache ?也就是说, 足够大来容纳你经常访问的数据,
    
    但是不能太大 会是内存负载太大出现paging.
    
    主要的内存区域是配置用于InnoDB buffer pool,MyISAM key cache,和其他Mysql 查询cache.
    
    硬件层面优化:
    
    任何数据库应用最后达到硬件限制 当数据库变的越来越繁忙。
    
    一个DBA必须评估是否它是可能调整应用或者重新评估server来避免那些瓶颈,
    
    或者 是否需要更多的硬件资源,系统瓶颈通常来自这些来源:
    
    磁盘寻道,它消耗时间对于disk来找到一个数据的部分。 随着现代磁盘的发展,
    
    
    平均时间用于这个是通常小于10毫秒,因此我们可以理论上 1秒钟做100次寻址。
    
    这时间改善使用新的磁盘是很难优化的对于单个表。
    
    优化寻址时间是分布数据到一个或者多个磁盘。
    
    
    磁盘读取和写入, 当磁盘是在正确的位置,我们需要读或者写数据。在现代磁盘,一个磁盘至少10-20M/s吞吐量。
    
    
    这是容易优化相比寻到 因为你可以读从多个磁盘并行读取
    
    
    内存带宽,当处理器需要更多的数据来填满cpu cache, 主要的内存带宽成为一个瓶颈。
    
    这是一个不常见的瓶颈
    
    
    可移植性和性能:

  • 相关阅读:
    [摘抄]数据湖,大数据的下一个变革
    linux localhost 借助nginx 支持https
    mac os 下 android studio 选择模拟器设备的时候一直显示Loading
    SpringBoot 项目遇到错误: Invalid character found in the request target. The valid characters are defined in RFC 7230 and RFC 3986
    nexus-2.12.0-01 shiro漏洞升级
    IDEA 历史版本下载地址
    Postfix 554 5.7.1 Relay Access Denied
    Java SPI 机制实现项目框架高扩展性
    IDEA控制台 springboot输出中文乱码
    Setup Apache2 in Debian 9 and enable two ports for two sites
  • 原文地址:https://www.cnblogs.com/zhaoyangjian724/p/6199170.html
Copyright © 2011-2022 走看看