数据库优化

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

mysql查询的过程图 为什么要优化 系统的吞吐量瓶颈往往出现在数据库的访问速度上 随着应用程序的运行，数据库的中的数据会越来越多，处理时间会相应变慢 数据是存放在磁盘上的，读写速度无法和内存相比 如何优化 设计数据库时：数据库表、字段的设计，存储引擎 利用好MySQL自身提供的功能，如索引等 横向扩展：MySQL集群、负载均衡、读写分离 SQL语句的优化（收效甚微） 一、字段设计阶段 选取最适用的字段属性 1. 字段的宽度设得尽可能小 MySQL可以很好的支持大数据量的存取，但是一般说来，数据库中的表越小，在它上面执行的查询也就会越快。因此，在创建表的时候，为了获得更好的性能，我们可以将表中字段的宽度设得尽可能小。 2. 尽量把字段设置为NOTNULL 在可能的情况下，应该尽量把字段设置为NOTNULL，这样在将来执行查询的时候，数据库不用去比较NULL值。 3. 确定数据定义为ENUM类型 对于某些文本字段，例如“省份”或者“性别”，我们可以将它们定义为ENUM类型。因为在MySQL中，ENUM类型被当作数值型数据来处理，而数值型数据被处理起来的速度要比文本类型快得多。这样，我们又可以提高数据库的性能。 4. 单表字段不宜过多，可以预留字段 满足业务需求的前提下二三是个字段就是极限了，可以预留字段便于扩展。 遵循数据表的设计规范 1. 第一范式(1NF) 字段值具有原子性

关于数据库优化的问题我总结为已下七个方面去优化；不足之处请大家多指教。 1、根据服务层面：配置mysql性能优化参数 根据服务器目前状况，修改mysql的系统参数，可达到合理利用服务器现有资源，最大合理的提高mysql性能。但一般我们从两个方向进行修改参数；一是mysql非缓存参数修改，二是mysql缓存变量修改。如何详细的修改请看我下一篇文章。 2、从系统层面增强mysql的性能：优化数据表结构、字段类型、字段索引、分表，分库、读写分离等。 优化数据表结构： 数据表设计遵循三范式 第一范式：数据库的每一列都是不可分割的原子数据项，而不能是集合、数组，记录非原子数据项。 第二范式：要求每一行的所有非主属性都必须完全依赖于主键；完全依赖：主键可能由多个属性构成，完全依赖要求不允许存在非主属性依赖于主键中的某一部分属性。 第三范式：实体中的属性不能是其他实体中的非主属性，即属性不依赖于其他非主属性。 字段类型 尽可能占用更少的存储空间 尽可能用整数代替字符串 尽可能定长的数据类型（占用固定的存储空间） 字段索引 表的主键、外健必须有索引 数据量大的表应该有索引 经常与其他表进行连接的表，在连接字段上应该上应该建立索引 经常出现在where子句中的字段，特别是大表的字段，应该建立索引 索引应该建立在选择性高的字段上 索引应该建立在小字段上，对于大的文本字段甚至超长字段，不要建索引

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

一、前提 这里的原则只是针对MySQL数据库，其他的数据库某些是殊途同归，某些还是存在差异。我总结的也是MySQL普遍的规则，对于某些特殊情况得特殊对待。在构造SQL语句的时候要养成良好的习惯。 二、原则总结 原则1、仅列出需要查询的字段，这对速度不会明显的影响，主要是考虑节省应用程序服务器的内存。 原来语句： select * from admin 优化为： select admin_id,admin_name,admin_password from admin 原则2、尽量避免在列上做运算，这样导致索引失效。 原语句： select * from admin where year(admin_time)>2014 优化为： select * from admin where admin_time> ’2014-01-01′ 原则3、使用JOIN 时候，应该用小的结果驱动大的结果（left join 左边表结果尽量小 如果有条件应该放到左边先处理，right join 同理反向），同事尽量把牵涉到多表联合的查询拆分多个query（多个连表查询效率低，容易到之后锁表和阻塞）。 原来语句 select * from admin left join log on admin.admin_id = log.admin_id where log.admin_id>10 优化为：

数据库优化 库和表结构优化 分库分表 当单个库或者表中的数据量大时 数据库的性能会变慢 垂直拆分 垂直拆分表 当一个表中的数据量比较大字段比较多时，创建一个附属表，将表中不常用的字段存入附属表，通过创建外检进行关联 垂直拆分库 根绝不同的业务需求，将不同的表放入不同的库中，一般会放到多个服务器上 水平拆分 水平分库分表 单表数据量太大 将数据水平拆分成多个表，多个表组合在一起才能组成一个完成的数据 将拆分的表放到不同的库中 水平拆分面临的问题： 主键如何保证唯一性 1.制定每张表的id取值范围 2.通过时间或者地理位置 3.通过趋势递增 雪花算法 水平分库 会面临 多表查询会受到影响 事物也会受到影响 目前没有人能解决这些问题，我们可以使用开源的框架产品来解决 但是不同的开源产品，所解决的问题也不相同，所以根据自己的需求来去选择 架构优化： 主从复制(读写分离) 添加缓存 一般使用非关系数据库做为缓存数据库 将数据存到内存中 sql语句的优化： 允许部分字段冗余，使用逻辑外检避免使用物理外键 添加索引：给查询频繁的条件添加索引，使用索引最左原则 查询时 select 后面不使用* 减少数据库的查询的次数 sql关键字尽量大写 使用关联查询替代嵌套子查询 使用where条件过滤 避免全表查询 Update修改时，避免修改索引字段所在的列 避免修改where后面字段 来源： https

一、数据库性能瓶颈主要原因 1、数据库连接 MySQL数据库默认连接为100，我们可以通过配置initialSize、minIdle、maxActive等进行调优，但由于硬件资源的限制，数据库连接不可能无限制的增加，对大型单体应用单实例数据库可能会出现最大连接数不能满足实际需求的情况，这时就会系统业务阻塞。 2、表数据量大（空间存储问题） 普遍观点认为单表数据量超过1000万条时就是出现数据库读取性能瓶颈。从索引角度分析，如果索引未被命中，数据库系统就会全表扫描，数据量越大，扫描全表的时间就会越长；即使索引被命中了，由于B+TREE索引是存放在硬盘上的，数据量越大B+TREE层次越深，IO次数也就越多。 3、硬件资源限制 硬件资源直接影响QPS每秒查询数/TPS每秒事务数。 二、数据性能优化方案 常见的数据性能优化方案：SQL优化、缓存、创建索引、读写分离、分库分表等。 解决大数据量性能优化，真正有效方案是采用分布式数据存储，即上面所述读写分离和分库分表。 1、读写分离 读写分离基于主从复制，采用区别读、写多数据源方式进行数据的存储和加载。数据的存储（增删改）指定写数据源，数据的读取查询指定读数据源。 通过读写分离复制与master相同的数据源（一主多从），多数据源可以部署到不同主机上，从而可以解决数据里连接瓶颈和硬件资源限制问题。 2、分库分表 对数据的库表进行拆分

摘要 本文以MySQL数据库为研究对象，讨论与数据库索引相关的一些话题。特别需要说明的是，MySQL支持诸多存储引擎，而各种存储引擎对索引的支持也各不相同，因此MySQL数据库支持多种索引类型，如BTree索引，哈希索引，全文索引等等。为了避免混乱，本文将只关注于BTree索引，因为这是平常使用MySQL时主要打交道的索引，至于哈希索引和全文索引本文暂不讨论。 常见的查询算法及数据结构 为什么这里要讲查询算法和数据结构呢？因为之所以要建立索引，其实就是为了构建一种数据结构，可以在上面应用一种高效的查询算法，最终提高数据的查询速度。 索引的本质 MySQL官方对索引的定义为：索引（Index）是帮助MySQL高效获取数据的数据结构。提取句子主干，就可以得到索引的本质：索引是数据结构。 常见的查询算法 我们知道，数据库查询是数据库的最主要功能之一。我们都希望查询数据的速度能尽可能的快，因此数据库系统的设计者会从查询算法的角度进行优化。那么有哪些查询算法可以使查询速度变得更快呢？ 顺序查找（linear search ） 最基本的查询算法当然是顺序查找（linear search），也就是对比每个元素的方法，不过这种算法在数据量很大时效率是极低的。 数据结构：有序或无序队列 复杂度：O(n) //顺序查找 int SequenceSearch(int a[], int value,

前言 数据库优化一方面是找出系统的瓶颈,提高MySQL数据库的整体性能,而另一方面需要合理的结构设计和参数调整,以提高用户的相应速度,同时还要尽可能的节约系统资源,以便让系统提供更大的负荷. 1、优化一览图 2、优化 笔者将优化分为了两大类,软优化和硬优化,软优化一般是操作数据库即可,而硬优化则是操作服务器硬件及参数设置. 2.1 软优化 2.1.1 查询语句优化 1、首先我们可以用EXPLAIN或DESCRIBE(简写:DESC)命令分析一条查询语句的执行信息. 2.例: DESC SELECT * FROM `user` 显示: 其中会显示索引和查询数据读取数据条数等信息. 2.1.2 优化子查询 在MySQL中,尽量使用JOIN来代替子查询.因为子查询需要嵌套查询,嵌套查询时会建立一张临时表,临时表的建立和删除都会有较大的系统开销,而连接查询不会创建临时表,因此效率比嵌套子查询高. 2.1.3 使用索引 索引是提高数据库查询速度最重要的方法之一,关于索引可以参高笔者<MySQL数据库索引>一文,介绍比较详细,此处记录使用索引的三大注意事项: 1、LIKE关键字匹配'%'开头的字符串,不会使用索引. 2、OR关键字的两个字段必须都是用了索引,该查询才会使用索引. 3、使用多列索引必须满足最左匹配. 2.1.4 分解表 对于字段较多的表,如果某些字段使用频率较低,此时应当

1.1、创建并使用正确的索引 索引会大大增加表记录的DML(INSERT,UPDATE,DELETE)开销，正确的索引可以让性能提升100，1000倍以上，不合理的索引也可能会让性能下降100倍，因此在一个表中创建什么样的索引需要平衡各种业务需求。 1、表的主键、外键必须有索引； 2、数据量超过300的表应该有索引； 3、经常与其他表进行连接的表，在连接字段上应该建立索引； 4、经常出现在Where子句中的字段，特别是大表的字段，应该建立索引； 5、索引应该建在选择性高的字段上； 6、索引应该建在小字段上，对于大的文本字段甚至超长字段，不要建索引； 插入数据对索引的影响 给people表创建了索引后，表中的所有数据将按照字母表顺序进行分块处理，假如分成两个块， 当往数据中插入一条name为Bill的数据时 ，数据表要做更多的操作，例如先要在Charles前插入Bill，然后数据块1中的数据往数据块2中移，数据块2又满了，得新增数据块3。因此，由于插入数据的不可知性，对于插入操作来说，索引造成的操作开销是普通表的l两倍以上。 修改数据对索引的影响 将原来name为James的数据修改为Winne时 ，修改的数据会反应到数据表中，但是索引项不会被删除，原索引项只会被标记为不可用，新的索引重新添加到相应的数据块中。这虽然减小了数据库操作的开销，但是带来了空间上的浪费。