数据库优化

MySQL优化一览图 笔者将优化分为了两大类： 软优化和硬优化 。软优化一般是操作数据库即可；而硬优化则是操作服务器硬件及参数设置。 1、软优化 1）查询语句优化 首先我们可以用EXPLAIN或DESCRIBE(简写:DESC)命令分析一条查询语句的执行信息。 例: DESC SELECT * FROM `user` 其中会显示索引和查询数据读取数据条数等信息。 2）优化子查询 在MySQL中，尽量使用JOIN来代替子查询。因为子查询需要嵌套查询，嵌套查询时会建立一张临时表，临时表的建立和删除都会有较大的系统开销，而连接查询不会创建临时表，因此效率比嵌套子查询高。 3）使用索引 索引是提高数据库查询速度最重要的方法之一，使用索引的三大注意事项包括： LIKE关键字匹配'%'开头的字符串，不会使用索引； OR关键字的两个字段必须都是用了索引，该查询才会使用索引； 使用多列索引必须满足最左匹配。 4）分解表 对于字段较多的表，如果某些字段使用频率较低，此时应当将其分离出来从而形成新的表。 5）中间表 对于将大量连接查询的表可以创建中间表，从而减少在查询时造成的连接耗时。 6）增加冗余字段 类似于创建中间表，增加冗余也是为了减少连接查询。 7）分析表、检查表、优化表 分析表主要是分析表中关键字的分布；检查表主要是检查表中是否存在错误；优化表主要是消除删除或更新造成的表空间浪费。 分析表：

网站性能优化对于大型网站来说非常重要，一个网站的访问打开速度影响着用户体验度，网站访问速度慢会造成高跳出率，小网站很好解决，那对于大型网站由于栏目多，图片和图像都比较庞大，那该怎么进行整体性能优化呢？本文为你提供一份大型php网站性能和并发访问优化方案. 一、大型网站性能提高策略： 大型网站，比如门户网站，在面对大量用户访问、高并发请求方面，基本的解决方案集中在这样几个环节：使用高性能的服务器、高性能的数据库、高效率的编程语言、还有高性能的Web容器。这几个解决思路在一定程度上意味着更大的投入。 web容器是一种服务程序，在服务器一个端口就有一个提供相应服务的程序，而这个程序就是处理从客户端发出的请求，如JAVA中的Tomcat容器，ASP的IIS或PWS都是这样的容器。一个服务器可以多个容器。 1、HTML静态化 其实大家都知道，效率最高、消耗最小的就是纯静态化的html页面，所以我们尽可能使我们的网站上的页面采用静态页面来实现，这个最简单的方法其实也是最有效的方法。 2、图片服务器分离 大家知道，对于Web服务器来说，不管是Apache、IIS还是其他容器，图片是最消耗资源的，于是我们有必要将图片与页面进行分离，这是基本上大型网站都会采用的策略，他们都有独立的、甚至很多台的图片服务器。这样的架构可以降低提供页面访问请求的服务器系统压力，并且可以保证系统不会因为图片问题而崩溃。

一、引言 　　随着互联网应用的广泛普及，海量数据的存储和访问成为了系统设计的瓶颈问题。对于一个大型的互联网应用，每天几十亿的PV无疑对数据库造成了相当高的负载。对于系统的稳定性和扩展性造成了极大的问题。通过数据切分来提高网站性能，横向扩展数据层已经成为架构研发人员首选的方式。水平切分数据库，可以降低单台机器的负载，同时最大限度的降低了了宕机造成的损失。通过负载均衡策略，有效的降低了单台机器的访问负载，降低了宕机的可能性；通过集群方案，解决了数据库宕机带来的单点数据库不能访问的问题；通过读写分离策略更是最大限度了提高了应用中读取（Read）数据的速度和并发量。目前国内的大型互联网应用中，大量的采用了这样的数据切分方案，Taobao,Alibaba,Tencent，它们大都实现了自己的分布式数据访问层（DDAL）。以实现方式和实现的层次来划分，大概分为两个层次（ Java 应用为例）：JDBC层的封装，ORM框架层的实现。就JDBC层的直接封装而言，现在国内发展较好的一个项目是被称作“变形虫”(Amoeba)的项目，由阿里集团的研究院开发，现在仍然处于测试阶段（beta版），其运行效率和生产时效性有待考究。就ORM框架层的实现而言，比如Taobao的基于ibatis和Spring的的分布式数据访问层，已有多年的应用，运行效率和生产实效性得到了开发人员和用户的肯定

作者: 听风，原文地址: https://www.cnblogs.com/huchong/p/10219318.html 。 数据库命令规范 数据库基本设计规范 所有表必须使用 Innodb 存储引擎 数据库和表的字符集统一使用 UTF8 所有表和字段都需要添加注释 尽量控制单表数据量的大小,建议控制在 500 万以内。 谨慎使用 MySQL 分区表 6.尽量做到冷热数据分离,减小表的宽度 禁止在表中建立预留字段 禁止在数据库中存储图片,文件等大的二进制数据 禁止在线上做数据库压力测试 禁止从开发环境,测试环境直接连接生成环境数据库 数据库字段设计规范 优先选择符合存储需要的最小的数据类型 避免使用 TEXT,BLOB 数据类型，最常见的 TEXT 类型可以存储 64k 的数据 避免使用 ENUM 类型 尽可能把所有列定义为 NOT NULL 使用 TIMESTAMP(4 个字节) 或 DATETIME 类型 (8 个字节) 存储时间 同财务相关的金额类数据必须使用 decimal 类型 索引设计规范 限制每张表上的索引数量,建议单张表索引不超过 5 个 禁止给表中的每一列都建立单独的索引 每个 Innodb 表必须有个主键 常见索引列建议 5.如何选择索引列的顺序 避免建立冗余索引和重复索引（增加了查询优化器生成执行计划的时间） 对于频繁的查询优先考虑使用覆盖索引 8.索引

1、增加了数据库等连接池后，架构发生了变化，进行了一定的性能提升 主从读写分离： 大部分系统时读多，写少，读写的数据量可能会有几个数量级 刷朋友圈的肯定比发朋友圈的多太多了。 所以这时候的优化要考虑到主从读写分离 主从就要涉及到主从的数据复制过程： 1、主从复制， mysql的主从复制全部依赖于binlog ， mysql的所有变化以二进制的形式存在磁盘上的二进制日志文件中， binlog从主库传输到了从库上，一般这个过程时异步的，主库操作不等待binlog同步完成 从库连接到主节点，会创建一个io线程， 请求binlog的信息，并写入relay_log中，然后在从库进行回放，最终从库一致性 可以进行一主多从多配置，最多挂3-5个从库，因为从库多了，主库需要log dump线程来处理复制的请求，对主库资源消耗大 ，主库的网络带宽也是限制 问题点：主从延迟问题，解决办法： 1、尽量不去从库查询数据，可以进行数据的冗余。 2、使用缓存，写入库的同时在缓存中进行记录 缓存的方案比较适用于新增数据 3、查询走主库（明确查询的量不是很大） 4、运维增强保证对主从延迟的一些监控和报警 缓存，如果是更新数据的操作，可能会导致库里和数据库不一致的问题 如何访问数据库： 数据库中间件，来解决数据库的访问问题 业务继续扩张，单表的数据量太大了 数据量大了：占用磁盘空间，恢复和备份时间长

a) 选择合适的字段，比如邮箱字段可以设为char（6），尽量把字段设置为notnull，这样查询的时候数据库就不需要比较null值 b) 使用关联查询（ left join on）查询代替子查询 c) 使用union联合查询手动创建临时表 d) 开启事物，当数据库执行多条语句出现错误时，事物会回滚，可以维护数据库的完整性 e) 使用外键，事物可以维护数据的完整性但是它却不能保证数据的关联性，使用外键可以保证数据的关联性 f) 使用索引，索引是提高数据库性能的常用方法，它可以令数据库服务器以比没有索引快的多的速度检索特定的行，特别是对于max，min，order by查询时，效果更明显 g) 优化的查询语句，绝大多数情况下，使用索引可以提高查询的速度，但如果sql语句使用不恰当的话，索引无法发挥它的特性。 来源： https://www.cnblogs.com/Yanss/p/11678105.html

1、选取最适用的字段属性 ​ MySQL可以很好的支持大数据量的存取，但是一般说来，数据库中的表越小，在它上面执行的查询也就会越快。因此，在创建表的时候，为了获得更好的性能，我们可以将表中字段的宽度设得尽可能小。 例如，在定义邮政编码这个字段时，如果将其设置为CHAR(255),显然给数据库增加了不必要的空间，甚至使用VARCHAR这种类型也是多余的，因为CHAR(6)就可以很好的完成任务了。同样的，如果可以的话，我们应该使用MEDIUMINT而不是BIGIN来定义整型字段。 ​ 另外一个提高效率的方法是在可能的情况下，应该尽量把字段设置为NOT NULL，这样在将来执行查询的时候，数据库不用去比较NULL值。 ​ 对于某些文本字段，例如“省份”或者“性别”，我们可以将它们定义为ENUM类型。因为在MySQL中，ENUM类型被当作数值型数据来处理，而数值型数据被处理起来的速度要比文本类型快得多。这样，我们又可以提高数据库的性能。 2、使用连接（JOIN）来代替子查询(Sub-Queries) ​ MySQL从4.1开始支持SQL的子查询。这个技术可以使用SELECT语句来创建一个单列的查询结果，然后把这个结果作为过滤条件用在另一个查询中。例如，我们要将客户基本信息表中没有任何订单的客户删除掉，就可以利用子查询先从销售信息表中将所有发出订单的客户ID取出来，然后将结果传递给主查询

MySQL官方优化文档：https://dev.mysql.com/doc/refman/5.7/en/optimization.html 数据库优化概述： 数据库性能取决于数据库级别的多个因素，例如表，查询和配置设置。这些软件构造导致硬件级别的CPU和I / O操作，您必须尽可能地最小化并尽可能高效。在处理数据库性能时，首先要学习软件方面的高级规则和指南，并使用挂钟时间来衡量性能。当您成为专家时，您将了解内部发生的更多信息，并开始测量诸如CPU周期和I / O操作之类的事情。 典型用户的目标是从现有的软件和硬件配置中获得最佳的数据库性能。高级用户寻找改进MySQL软件本身的机会，或者开发自己的存储引擎和硬件设备来扩展MySQL生态系统。 在数据库级别进行优化 在硬件级别进行优化 平衡可移植性和性能 在数据库级别进行优化 使数据库应用程序快速运行的最重要因素是其基本设计： 表格结构合理吗？特别是，列是否具有正确的数据类型，并且每个表是否具有适合工作类型的列？例如，执行频繁更新的应用程序通常具有许多具有少量列的表，而分析大量数据的应用程序通常具有很少列的表。 是否有适当的 索引 来提高查询效率？ 您是否为每个表使用适当的存储引擎，并利用您使用的每个存储引擎的优势和功能？特别是，事务性存储引擎（例如 InnoDB 非 事务性存储引擎）的选择 MyISAM 对于性能和可伸缩性来说非常重要

MySQL 数据库性能优化之缓存参数优化 数据库属于 IO 密集型的应用程序，其主要职责就是数据的管理及存储工作。而我们知道，从内存中读取一个数据库的时间是微秒级别，而从一块普通硬盘上读取一个IO是在毫秒级别，二者相差3个数量级。所以，要优化数据库，首先第一步需要优化的就是 IO，尽可能将磁盘IO转化为内存IO。本文先从 MySQL 数据库IO相关参数(缓存参数)的角度来看看可以通过哪些参数进行IO优化。 query_cache_size/query_cache_type (global) Query cache 作用于整个 MySQL Instance，主要用来缓存 MySQL 中的 ResultSet，也就是一条SQL语句执行的结果集，所以仅仅只能针对select语句。当我们打开了 Query Cache 功能，MySQL在接受到一条select语句的请求后，如果该语句满足Query Cache的要求(未显式说明不允许使用Query Cache，或者已经显式申明需要使用Query Cache)，MySQL 会直接根据预先设定好的HASH算法将接受到的select语句以字符串方式进行hash，然后到Query Cache 中直接查找是否已经缓存。也就是说，如果已经在缓存中，该select请求就会直接将数据返回，从而省略了后面所有的步骤(如 SQL语句的解析

在进行 MySQL 的优化之前必须要了解的就是 MySQL 的查询过程，很多的查询优化工作实际上就是遵循一些原则让 MySQL 的优化器能够按照预想的合理方式运行而已。 图 - MySQL查询过程 优化的哲学 优化有风险，涉足需谨慎。 优化可能带来的问题 优化不总是对一个单纯的环境进行，还很可能是一个复杂的已投产的系统。 优化手段本来就有很大的风险，只不过你没能力意识到和预见到！ 任何的技术可以解决一个问题，但必然存在带来一个问题的风险！ 对于优化来说解决问题而带来的问题,控制在可接受的范围内才是有成果。 保持现状或出现更差的情况都是失败！ 优化的需求 稳定性和业务可持续性,通常比性能更重要！ 优化不可避免涉及到变更，变更就有风险！ 优化使性能变好，维持和变差是等概率事件！ 切记优化,应该是各部门协同，共同参与的工作，任何单一部门都不能对数据库进行优化！ 所以优化工作,是由业务需要驱使的！！！ 优化由谁参与 　　在进行数据库优化时，应由数据库管理员、业务部门代表、应用程序架构师、应用程序设计人员、应用程序开发人员、硬件及系统管理员、存储管理员等，业务相关人员共同参与。 优化思路 优化什么 在数据库优化上有两个主要方面：即安全与性能。 安全 ---> 数据可持续性 性能 ---> 数据的高性能访问 优化的范围有哪些 存储、主机和操作系统方面 主机架构稳定性 I/O 规划及配置