数据库优化

MySQL数据库优化 概览 软优化 1.优化查询语句 2.优化子查询 3.命中索引 4.分解表 5.增加中间表 6.增加冗余字段 7.分析表、检查表、优化表 硬优化 1.cpu、内存、磁盘 2.配置参数 3.分库分表 4.缓存集群 概览 软优化 ：1.优化查询语句；2.优化子查询；3.命中索引；4.分解表；5.增加中间表；6.增加冗余字段；7.分析表、检查表、优化表 硬优化 ：1.cpu、内存、磁盘；2.配置参数；3.分库分表+读写分离；4.缓存集群 软优化 1.优化查询语句 使用EXPLAIN或者DESCRIBE（可简写为DESC）命令分析一条查询语句的执行信息 输入： DESC SELECT * FROM user 显示： select_type：代表查询类型，分为简单查询、子查询等等 type：代表查询策略，分为全表扫描（ALL）、索引合并（index_merge）等等 possible_keys：可能用到的索引 key：实际用到的索引 Extra：额外信息，包含Using intersect（index1，index2）、Using where、Using index等等 2.优化子查询 应该尽量使用join查询代替子查询。子查询是一个嵌套的查询，外层查询嵌套内层查询，查询时会建立内层查询的临时表，查询完毕会删除该临时表，建立和删除会有较大的系统开销

数据库优化，是一种综合性的技术，不是通过某一种方式让数据库效率提高很多，而是通过各个方面的优化，来是数据库效率明显的稳步的提高。 主要包括以下： 1、库表的设计优化（三种范式） 2、 库表添加合适的索引(普通索引+主键索引+唯一索引+全文索引) 3、 分表技术-水平分割与垂直分割 4、 读写分离（add/delete/update与select分开） 5、 多用存储过程和触发器（模块化编程） 6、 优化MqSql配置（配置最大并发数，调整缓存大小，my.ini） 7、SQL优化与慢查询 8、 定时清楚垃圾数据，定时进行碎片整理（ MyISAM ） 除此之外，还有 MqSql服务器硬件升级 以下进行详细描述 题外话： 存储引擎： MyISAM ： 查询速度快，插入速度快，但不支持 事务 ，碎片多； InnoDB ：5.5版本后Mysql的默认数据库，支持事务，支持ACID事务，支持行级锁定； Memory ：所有数据置于内存中，拥有极高的插入，适合频繁的数据更新，更新和查询效率。但是会占用和数据量成正比的内存空间。并且其内容会在Mysql重新启动时丢失，不需要保存滴； 数据库三种模式结构/三级模式 外模式（用户）：用户所能看到的数据视图，可通过数据库操纵语言对数据进行操作； 模式（概念）：用户视图的最小并集，所有数据的逻辑结构和概念的描述； 内模式（物理）：实际存储组合，内部视图

特别说明： 1、 本文只是面对数据库应用开发的程序员，不适合专业 DBA ， DBA 在数据库性能优化方面需要了解更多的知识； 2、 本文许多示例及概念是基于 Oracle 数据库描述，对于其它关系型数据库也可以参考，但许多观点不适合于 KV 数据库或内存数据库或者是基于 SSD 技术的数据库； 3、 本文未深入数据库优化中最核心的执行计划分析技术。 读者对像： 开发人员： 如果你是做数据库开发，那本文的内容非常适合，因为本文是从程序员的角度来谈数据库性能优化。 架构师： 如果你已经是数据库应用的架构师，那本文的知识你应该清楚 90% ，否则你可能是一个喜欢折腾的架构师。 DBA （数据库管理员）： 大型数据库优化的知识非常复杂，本文只是从程序员的角度来谈性能优化， DBA 除了需要了解这些知识外，还需要深入数据库的内部体系架构来解决问题。 引言 在网上有很多文章介绍数据库优化知识，但是大部份文章只是对某个一个方面进行说明，而对于我们程序员来说这种介绍并不能很好的掌握优化知识，因为很多介绍只是对一些特定的场景优化的，所以反而有时会产生误导或让程序员感觉不明白其中的奥妙而对数据库优化感觉很神秘。 很多程序员总是问如何学习数据库优化，有没有好的教材之类的问题。在书店也看到了许多数据库优化的专业书籍，但是感觉更多是面向 DBA 或者是 PL/SQL 开发方面的知识

` ` ` bash show variables like '%max_connections%' ; show variables like '%max_user_connections%' ; ` show variables like '%max_connections%' ; show variables like '%max_user_connections%' ; ` ` MySQL性能 最大数据量 最大并发数 查询耗时0.5秒 实施原则 数据表设计 数据类型 避免空值 text类型 索引优化 索引分类 优化原则 SQL优化 分批处理 不做列运算 避免Select * 操作符<>优化 OR优化 IN优化 LIKE优化 JOIN优化 LIMIT优化 其他数据库   博主负责的项目主要采用阿里云数据库MySQL，最近频繁出现慢SQL告警，执行时间最长的竟然高达5分钟。导出日志后分析，主要原因竟然是 没有命中索引和没有分页处理 。其实这是非常低级的错误，我不禁后背一凉，团队成员的技术水平亟待提高啊。改造这些SQL的过程中，总结了一些经验分享给大家，如果有错误欢迎批评指正。 MySQL性能 最大数据量    抛开数据量和并发数，谈性能都是耍流氓 。MySQL没有限制单表最大记录数，它取决于操作系统对文件大小的限制。 文件系统 单文件大小限制 FAT32 最大4G NTFS

有一次在mybatis查6000条数据，发现就用了2秒多，实在是忍不了，在数据库中执行只要400毫秒就可以了。后来设置了一下fetchSize=1000，用postman就从2秒变成了800毫秒，其中还是下载耗时。下面简单介绍一下jabc fethSize的原理和作用。 jdbc在查询的时候，每次会从游标中取10条数据，连续重复，每一次重复都会进行一次数据库交互，交互都是非常耗时间的，而fetchSize就是设置每次查询出来的数据条数，保存进缓存中，以后每次游标取10条数据，就会从内存中读取10条数据， 这样不需要进行数据库交互，耗时也就变少了。 所以说，fechSize设置的越大，也就查询越快。 来源： https://www.cnblogs.com/javalisong/p/12203046.html

对于一个以数据为中心的应用，数据库的好坏直接影响到程序的性能，因此数据库性能至关重要。一般来说，要保证数据库的效率，要做好以下四个方面的工作：数据库设计、sql语句优化、数据库参数配置、恰当的硬件资源和操作系统，这个顺序也表现了这四个工作对性能影响的大小。下面我们逐个阐明： 一、数据库设计 　　适度的反范式,注意是适度的 　　我们都知道三范式，基于三范式建立的模型是最有效保存数 据的方式，也是最容易扩展的模式。我们在开发应用程序时，设计的数据库要最大程度的遵守三范式，特别是对于OLTP型的系统，三范式是必须遵守的规则。当 然，三范式最大的问题在于查询时通常需要join很多表，导致查询效率很低。所以有时候基于性能考虑，我们需要有意的违反三范式，适度的做冗余，以达到提 高查询效率的目的。注意这里的反范式是适度的，必须为这种做法提供充分的理由。下面就是一个糟糕的实例：　　 　 　在这里，为了提高学生活动记录的检索效率，把单位名称冗余到学生活动记录表里。单位信息有500条记录，而学生活动记录在一年内大概有200万数据量。 如果学生活动记录表不冗余这个单位名称字段，只包含三个int字段和一个timestamp字段，只占用了16字节，是一个很小的表。而冗余了一个 varchar(32)的字段后则是原来的3倍，检索起来相应也多了这么多的I/O。而且记录数相差悬殊，500 VS 2000000

对于一个以数据为中心的应用，数据库的好坏直接影响到程序的性能，因此数据库性能至关重要。一般来说，要保证数据库的效率，要做好以下四个方面的工作：数 据库设计、sql语句优化、数据库参数配置、恰当的硬件资源和操作系统，这个顺序也表现了这四个工作对性能影响的大小。下面我们逐个阐明： 一、数据库设计 　　适度的反范式,注意是适度的 　　我们都知道三范式，基于三范式建立的模型是最有效保存数 据的方式，也是最容易扩展的模式。我们在开发应用程序时，设计的数据库要最大程度的遵守三范式，特别是对于OLTP型的系统，三范式是必须遵守的规则。当 然，三范式最大的问题在于查询时通常需要join很多表，导致查询效率很低。所以有时候基于性能考虑，我们需要有意的违反三范式，适度的做冗余，以达到提 高查询效率的目的。注意这里的反范式是适度的，必须为这种做法提供充分的理由。下面就是一个糟糕的实例：　　 　 　在这里，为了提高学生活动记录的检索效率，把单位名称冗余到学生活动记录表里。单位信息有500条记录，而学生活动记录在一年内大概有200万数据量。 如果学生活动记录表不冗余这个单位名称字段，只包含三个int字段和一个timestamp字段，只占用了16字节，是一个很小的表。而冗余了一个 varchar(32)的字段后则是原来的3倍，检索起来相应也多了这么多的I/O。而且记录数相差悬殊，500 VS 2000000

数据库设计优化 使用varchar(变长)而非char 使用tinyint、smallint、mediumint而非int，非负加unsigned 尽量使用数字型字段，不要把数字型设计为字符型 合理使用索引：单列索引（普通索引index–>唯一索引unique index–>主键索引primary key）、组合索引(最左匹配)、全文索引(MyISAM引擎 char、varcahr、text)、空间索引（空间数据类型）。索引提高了select效率，降低了insert和update效率（<=6） 分表：（垂直）字段较多的表，有些字段使用频率较低，分离出新表；（水平）数据量大的按时间、区间分表 大量连接查询的表创建临时表，减少查询时的连接耗时 适当增加冗余字段，减少连接查询（单表>>多表） sql语句优化（括号中为替代方案或注释） 避免跳过索引而进行全表扫描 ：避免where中null值判断（使用默认值0）、!=、<>、or（两边字段都为索引或使用union）、in（exists）、not in（between）、对字段进行表达式操作、对字段进行函数操作、like ‘%xxx’（like ‘xxx%‘）。 禁止使用 ‘*’ 使用join替代子查询，避免频繁创建和删除临时表 用where替代having order by只有在order

数据库优化的目的 1.避免出现页面访问错误 由于数据库连接 timeout 产生页面5xx错误 由于慢查询造成页面无法加载 由于阻塞造成数据无法提交 2.增加数据库的稳定性 很多数据库问题都是由低效的查询引起的 3.优化用户体验 流畅的页面访问速度 良好的网站功能体验 MySQL数据库优化 上图是数据库优化的金字塔结构。可以看出，SQL及索引优化位于金字塔的最低层，是数据库优化的基础，成本最低，效果却最好。 一 SQL语句优化 找出有问题的SQL 1.1 使用MySQL慢查询日志对低效率的SQL进行监控 1）查询是否开启了慢查询日志 show variables like 'slow_query_log'; 2）设置记录未使用索引的查询 set global log_queries_not_using_indexes=on; 3）设置慢查询时间 set global long_query_time=0.1; 注：直接修改 global 的 long_query_time 在当前窗口是不生效的，在新打开的窗口才有效果。如果想让当前窗口生效，在设置时不用加 global 关键字。 4）设置慢查询日志地址 set global slow_query_log_file='/home/log/mysql/mysql-query.log'; 5）开启慢查询日志 set global slow

对于一个以数据为中心的应用，数据库的好坏直接影响到程序的性能，因此数据库性能至关重要。一般来说，要保证数据库的效率，要做好以下四个方面的工作：数据库设计、sql语句优化、数据库参数配置、恰当的硬件资源和操作系统，这个顺序也表现了这四个工作对性能影响的大小。下面我们逐个阐明： 一、数据库设计 　　适度的反范式,注意是适度的 　　我们都知道三范式，基于三范式建立的模型是最有效保存数 据的方式，也是最容易扩展的模式。我们在开发应用程序时，设计的数据库要最大程度的遵守三范式，特别是对于OLTP型的系统，三范式是必须遵守的规则。当 然，三范式最大的问题在于查询时通常需要join很多表，导致查询效率很低。所以有时候基于性能考虑，我们需要有意的违反三范式，适度的做冗余，以达到提 高查询效率的目的。注意这里的反范式是适度的，必须为这种做法提供充分的理由。下面就是一个糟糕的实例：　　 　 　在这里，为了提高学生活动记录的检索效率，把单位名称冗余到学生活动记录表里。单位信息有500条记录，而学生活动记录在一年内大概有200万数据量。 如果学生活动记录表不冗余这个单位名称字段，只包含三个int字段和一个timestamp字段，只占用了16字节，是一个很小的表。而冗余了一个 varchar(32)的字段后则是原来的3倍，检索起来相应也多了这么多的I/O。而且记录数相差悬殊，500 VS 2000000