优化概述

数据库性能表现依赖于数据库级别的几个因素,比如表,查询和配置设置。这些软件在硬件级别通过CPU和IO操作构筑结果,你需要尽可能的使用最少的资源达到最大的效果。当你专注于数据库的性能表现时,你应该学习数据库的高级规则和指南,然后以实际执行时间来度量数据库性能。你想成为专家的话,你应该进一步学习在MySQL内部都发生了什么,并且开始以CPU周期和IO操作来度量数据库的性能了。

大多数用户都想方设法的通过现有的软件和硬件配置来或者数据库的最好性能,再高级点的用户则尝试找机会去改进MySQL软件本身,或者开发它们自己的存储引擎和硬件设施以此来扩展MySQL系统。

*)在数据库级别优化

*)在硬件级别优化

*)平衡移植和性能

一、在数据库级别优化

让数据库运行更快的最重要的因素就在它的基本设计之中:

1)表结构是否设计合理?特别是表子段被设计成正确的数据类型,还有每个表是否都有合适的类型的子段?比如,应用程序经常处理频繁的更新,但是却要更新多张子段很少的表。再如应用程序要解析大量的数据,但是这些数据通常只分布在很少的表中,但表的字段却很多。

2)索引设置是否得当,它有没有起到应有的效果?

3)你是否为每个表都设置了合适的存储引擎,并且充分利用了这个存储引擎的优势和特点?特别是,选择事务型存储引擎例如InnoDB或者非事务型存储引擎MyISAM可能对性能和可扩展性非常重要。

注意:

InnoDB是你创建新表时的默认引擎。实际上,改进型的InnoDB的表现特性意味着InnoDB表通常要比与之类似的MyISAM表性能要好,尤其是那种业务量大的数据库。

4)你是否为每个表都使用了合适的行格式?这个选择同样依赖于你为数据表选择的存储引擎。特别是,压缩表以使数据用的磁盘空间更少这样就可以用更少的I/O去读写数据。压缩功能对于任何类型的InnoDB表和MyISAM表都是可用的。

5)应用是否使用了合适的锁机制?例如,通过允许共享访问来实现数据库的并发访问,同时在需要执行排它操作时请求一个独立访问。再次印证,对于存储引擎的选择意义重大。InnoDB存储引擎处理大多数加锁问题而不需要你的参与,实现了更好的并发并且减少了你的代码为了提高性能而进行的大量的试验和尝试。

6)是否所有的内存区域都应用了正确的缓存大小。通俗的讲,是否足够大以应对频繁的数据访问,但又不大到超过物理内存并引起排序。最主要的内存区域配置是InnoDB缓存池,MyISAM的健缓存,还有MySQL的查询缓存。

二、在硬件层面优化

当数据库负载越来越大的时候,任何数据库应用最终都会被硬件所限制。作为一个DBA应该评估一下是否可能通过优化应用或者重新配置服务器去规避这些瓶颈,或者扩展更多的硬件。系统瓶颈通常来源于以下几个原因:

1)硬盘寻址。想找到硬盘上的数据是要花时间的。现代硬盘,这种寻址一般少于10毫秒,因此我们可以以每秒100次寻址来统计。这种耗时在新硬盘上提高缓慢并且对于单表来说比较难优化。优化寻址时间可以通过把数据放到不同硬盘上来进行。

2)硬盘读写。当硬盘在正确的位置时,我们需要读写数据。现代硬盘,一快硬盘读取速率至少在10-20兆每秒。这块很好优化,因为你可以同时从不同的硬盘去读取数据。

3)CPU周期。当数据在主存种,我们必须处理它以得到我们想要的结果。读取大表相比较于大量的内存而言是通常限制的因素。但是小表速度通常不是问题。

4)内存带宽。当CPU超过它能配置在CPU缓存里的数据时,主存带宽就成为了一个瓶颈。这并不是大多数系统所面临的常见瓶颈,但它应该引起我们的注意。

三、平衡移植和性能

在一个可移植的MySQL项目中使用性能目的类型的SQL扩展,你可以用Mysql特有的关键词 /*! */来作为注释标识。其他的SQL服务器忽略这个关键词。

-------------------------------------英文原文---------------------------------------
Optimization Overview

Database performance depends on several factors at the database level, such as tables, queries, and configuration settings. These software constructs result in CPU and I/O operations at the hardware level, which you must minimize and make as efficient as possible. As you work on database performance, you start by learning the high-level rules and guidelines for the software side, and measuring performance using wall-clock time. As you become an expert, you learn more about what happens internally, and start measuring things such as CPU cycles and I/O operations.

Typical users aim to get the best database performance out of their existing software and hardware configurations. Advanced users look for opportunities to improve the MySQL software itself, or develop their own storage engines and hardware appliances to expand the MySQL ecosystem.

Optimizing at the Database Level

Optimizing at the Hardware Level

Balancing Portability and Performance

Optimizing at the Database Level

The most important factor in making a database application fast is its basic design:

Are the tables structured properly? In particular, do the columns have the right data types, and does each table have the appropriate columns for the type of work? For example, applications that perform frequent updates often have many tables with few columns, while applications that analyze large amounts of data often have few tables with many columns.

Are the right indexes in place to make queries efficient?

Are you using the appropriate storage engine for each table, and taking advantage of the strengths and features of each storage engine you use? In particular, the choice of a transactional storage engine such as InnoDB or a nontransactional one such as MyISAM can be very important for performance and scalability.

Note
InnoDB is the default storage engine for new tables. In practice, the advanced InnoDB performance features mean that InnoDB tables often outperform the simpler MyISAM tables, especially for a busy database.

Does each table use an appropriate row format? This choice also depends on the storage engine used for the table. In particular, compressed tables use less disk space and so require less disk I/O to read and write the data. Compression is available for all kinds of workloads with InnoDB tables, and for read-only MyISAM tables.

Does the application use an appropriate locking strategy? For example, by allowing shared access when possible so that database operations can run concurrently, and requesting exclusive access when appropriate so that critical operations get top priority. Again, the choice of storage engine is significant. The InnoDB storage engine handles most locking issues without involvement from you, allowing for better concurrency in the database and reducing the amount of experimentation and tuning for your code.

Are all memory areas used for caching sized correctly? That is, large enough to hold frequently accessed data, but not so large that they overload physical memory and cause paging. The main memory areas to configure are the InnoDB buffer pool, the MyISAM key cache, and the MySQL query cache.

Optimizing at the Hardware Level

Any database application eventually hits hardware limits as the database becomes more and more busy. A DBA must evaluate whether it is possible to tune the application or reconfigure the server to avoid these bottlenecks, or whether more hardware resources are required. System bottlenecks typically arise from these sources:

Disk seeks. It takes time for the disk to find a piece of data. With modern disks, the mean time for this is usually lower than 10ms, so we can in theory do about 100 seeks a second. This time improves slowly with new disks and is very hard to optimize for a single table. The way to optimize seek time is to distribute the data onto more than one disk.

Disk reading and writing. When the disk is at the correct position, we need to read or write the data. With modern disks, one disk delivers at least 10–20MB/s throughput. This is easier to optimize than seeks because you can read in parallel from multiple disks.

CPU cycles. When the data is in main memory, we must process it to get our result. Having large tables compared to the amount of memory is the most common limiting factor. But with small tables, speed is usually not the problem.

Memory bandwidth. When the CPU needs more data than can fit in the CPU cache, main memory bandwidth becomes a bottleneck. This is an uncommon bottleneck for most systems, but one to be aware of.

Balancing Portability and Performance

To use performance-oriented SQL extensions in a portable MySQL program, you can wrap MySQL-specific keywords in a statement within /*! */ comment delimiters. Other SQL servers ignore the commented keywords. For information about writing comments, see Section 9.6, “Comment Syntax”.

MySQL文档翻译(八)附英文原文---性能优化概览的更多相关文章

  1. MySQL查询语句执行过程及性能优化(JOIN/ORDER BY)-图

    http://blog.csdn.net/iefreer/article/details/12622097 MySQL查询语句执行过程及性能优化-查询过程及优化方法(JOIN/ORDER BY) 标签 ...

  2. MySQL查询语句执行过程及性能优化-查询过程及优化方法(JOIN/ORDER BY)

    在上一篇文章MySQL查询语句执行过程及性能优化-基本概念和EXPLAIN语句简介中介绍了EXPLAIN语句,并举了一个慢查询例子:

  3. Haproxy官方文档翻译(第三章)全局参数(1) 附英文原文

    3.全局参数 在global这个节点里的参数是“进程范围的”并且经常是“操作系统指定”的.它们通常是一次性设置而且一旦正确设置不需要动来动去的.它们中的一些和命令行对应. global节点支持以下关键 ...

  4. Haproxy官方文档翻译(第二章)配置Haproxy 附英文原文

    2.配置 HAProxy 2.1 配置文件格式 Haproxy的配置过程包含了3部分的参数资源:- 命令行中的参数,此种参数总是享有优先权被使用- 配置文件中global节点中的参数,此种参数是进程范 ...

  5. MySQL学习笔记(二)性能优化的笔记(转)

    今天,数据库的操作越来越成为整个应用的性能瓶颈了,这点对于Web应用尤其明显.关于数据库的性能,这并不只是DBA才需要担心的事,而这更是我们程序员需要去关注的事情.当我们去设计数据库表结构,对操作数据 ...

  6. 高性能MySQL笔记 第6章 查询性能优化

    6.1 为什么查询速度会慢   查询的生命周期大致可按照顺序来看:从客户端,到服务器,然后在服务器上进行解析,生成执行计划,执行,并返回结果给客户端.其中“执行”可以认为是整个生命周期中最重要的阶段. ...

  7. MySQL查询语句执行过程及性能优化-基本概念和EXPLAIN语句简介

    网站或服务的性能关键点很大程度在于数据库的设计(假设你选择了合适的语言开发框架)以及如何查询数据上. 我们知道MySQL的性能优化方法,一般有建立索引.规避复杂联合查询.设置冗余字段.建立中间表.查询 ...

  8. MySQL学习笔记:select语句性能优化建议

    关于SQL中select性能优化有以下建议,仅当笔记记录. 1.检查索引:where.join部分字段都该加上索引 2.限制工作数据集的大小:利用where字句过滤 3.只选择需要的字段:减少IO开销 ...

  9. MYSQL ini 配置文件详解及性能优化方案

    my.ini分为两块:Client Section和Server Section.   Client Section用来配置MySQL客户端参数.   要查看配置参数可以用下面的命令: show va ...

随机推荐

  1. 简单数据库开发之dao层开发

    数据库 dao层是用来与底层数据库连接的一系列代码,它因上层service层调用而调用底层数据库,因为一般的数据库不会只存在一到几张表格,所以必须定义出dao层的接口协议,方便各种表格的操作. dao ...

  2. 几个bat文件(关于robot freamwork安装)

    如果安装后 没有这几文件,或者在运行后 提示 文件缺少这个文件 , 就需要手动创建.   一般文件在 :C:\Python27\Scripts 这个目录下 1.pybot.bat文件: @echo o ...

  3. Multi-Projector Based Display Code ------- Home

    Overview This project provides you with the tools and techniques you need to create your own large-a ...

  4. linux信息收集

    1.系统区分debian系列:debian.ubunturedhat系列:redhat.centos 是否为docker.或者为虚拟机 分为通用模块.单独模块的信息获取 2.系统信息收集 内核(是否为 ...

  5. flask基础二

    内容有:1.配置文件处理,2.路由系统,3.视图,4.请求,5.响应,6.模板渲染,7.session,8.flash,9.中间件,10特殊装饰器 一:一个简单知识点 通过路径构成的字符串1.动态导入 ...

  6. CentOS7 使用systemctl来管理服务

    1.建立service文件 以tomcat为例 , 建立tomcat.service文件 #服务说明 [Unit] #服务描述 Description=Tomcat Service #前置需要启动的服 ...

  7. Python request SSL证书问题

    错误信息如下: 1 requests.exceptions.SSLError: ("bad handshake: Error([('SSL routines', 'tls_process_s ...

  8. Centos 安装Java jdk

    1/ yum search java|grep jdk 2/ yum install java-......... 3/ vi /etc/profile 在最后添上: 4/ source /etc/p ...

  9. 赶集网三年 DBA 总结(转)

    2012年初入职赶集,当时处在流量讯猛增长的阶段,3年DBA生涯收获坡多,其实坑更多(泪... 后来在做开发时,慢慢体会到 ”运维“ 和 “开发” 确实存在沟通问题:知识不对称.如何解决呢?先总结下这 ...

  10. mac环境使用ATS验证

    https://blog.csdn.net/skylin19840101/article/details/53760146 参考的这篇文章,用 /usr/bin/nscurl --ats-diagno ...