本文目录一览：
- 1、8，mysql数据库，怎么优化
- 2、MySQL数据库性能优化之分区分表分库
- 3、MySQL 数据表优化设计（三）：CHAR 和 VARCHAR 怎么选？
- 4、北大青鸟设计培训：mysql数据库的优化方法？
- 5、北大青鸟设计培训：Mysql数据库的设计和优化？
- 6、昆明java培训学校告诉你Mysql数据库的设计和优化？
8，mysql数据库，怎么优化
优化Mysql数据库的8个方法
1、创建索引
对于查询占主要的应用来说，索引显得尤为重要。很多时候性能问题很简单的就是因为我们忘了添加索引而造成的，或者说没有添加更为有效的索引导致。如果不加索引的话，那么查找任何哪怕只是一条特定的数据都会进行一次全表扫描，如果一张表的数据量很大而符合条件的结果又很少，那么不加索引会引起致命的性能下降。但是也不是什么情况都非得建索引不可，比如性别可能就只有两个值，建索引不仅没什么优势，还会影响到更新速度，这被称为过度索引。
2、复合索引
比如有一条语句是这样的：select
* from users where area='beijing' and
age=22;
如果我们是在area和age上分别创建单个索引的话，由于mysql查询每次只能使用一个索引，所以虽然这样已经相对不做索引时全表扫描提高了很多效率，但是如果在area、age两列上创建复合索引的话将带来更高的效率。如果我们创建了(area,
age,
salary)的复合索引，那么其实相当于创建了(area,age,salary)、(area,age)、(area)三个索引，这被称为最佳左前缀特性。因此我们在创建复合索引时应该将最常用作限制条件的列放在最左边，依次递减。
3、索引不会包含有NULL值的列
只要列中包含有NULL值都将不会被包含在索引中，复合索引中只要有一列含有NULL值，那么这一列对于此复合索引就是无效的。所以我们在数据库设计时不要让字段的默认值为NULL。
4、使用短索引
对串列进行索引，如果可能应该指定一个前缀长度。例如，如果有一个CHAR(255)的
列，如果在前10 个或20
个字符内，多数值是惟一的，那么就不要对整个列进行索引。短索引不仅可以提高查询速度而且可以节省磁盘空间和I/O操作。
5、排序的索引问题
mysql查询只使用一个索引，因此如果where子句中已经使用了索引的话，那么order
by中的列是不会使用索引的。因此数据库默认排序可以符合要求的情况下不要使用排序操作；尽量不要包含多个列的排序，如果需要最好给这些列创建复合索引。
6、like语句操作
一般情况下不鼓励使用like操作，如果非使用不可，如何使用也是一个问题。like
“%aaa%” 不会使用索引而like “aaa%”可以使用索引。
7、不要在列上进行运算
select *
from users where
YEAR(adddate)2007;
将在每个行上进行运算，这将导致索引失效而进行全表扫描，因此我们可以改成
select * from
users where adddate‘2007-01-01';
8、不使用NOT
IN和操作
NOT IN和操作都不会使用索引将进行全表扫描。NOT IN可以NOT
EXISTS代替，id3则可使用id3 or id3来代替。
MySQL数据库性能优化之分区分表分库
分表是分散数据库压力的好方法。
分表，最直白的意思，就是将一个表结构分为多个表，然后，可以再同一个库里，也可以放到不同的库。
当然，首先要知道什么情况下，才需要分表。个人觉得单表记录条数达到百万到千万级别时就要使用分表了。
分表的分类
**1、纵向分表**
将本来可以在同一个表的内容，人为划分为多个表。（所谓的本来，是指按照关系型数据库的第三范式要求，是应该在同一个表的。）
分表理由：根据数据的活跃度进行分离，（因为不同活跃的数据，处理方式是不同的）
案例：
对于一个博客系统，文章标题，作者，分类，创建时间等，是变化频率慢，查询次数多，而且最好有很好的实时性的数据，我们把它叫做冷数据。而博客的浏览量，回复数等，类似的统计信息，或者别的变化频率比较高的数据，我们把它叫做活跃数据。所以，在进行数据库结构设计的时候，就应该考虑分表，首先是纵向分表的处理。
这样纵向分表后：
首先存储引擎的使用不同，冷数据使用MyIsam 可以有更好的查询数据。活跃数据，可以使用Innodb ,可以有更好的更新速度。
其次，对冷数据进行更多的从库配置，因为更多的操作时查询，这样来加快查询速度。对热数据，可以相对有更多的主库的横向分表处理。
其实，对于一些特殊的活跃数据，也可以考虑使用memcache ,redis之类的缓存，等累计到一定量再去更新数据库。或者mongodb 一类的nosql 数据库，这里只是举例，就先不说这个。
**2、横向分表**
字面意思，就可以看出来，是把大的表结构，横向切割为同样结构的不同表，如，用户信息表，user_1,user_2等。表结构是完全一样，但是，根据某些特定的规则来划分的表，如根据用户ID来取模划分。
分表理由：根据数据量的规模来划分，保证单表的容量不会太大，从而来保证单表的查询等处理能力。
案例：同上面的例子，博客系统。当博客的量达到很大时候，就应该采取横向分割来降低每个单表的压力，来提升性能。例如博客的冷数据表，假如分为100个表，当同时有100万个用户在浏览时，如果是单表的话，会进行100万次请求，而现在分表后，就可能是每个表进行1万个数据的请求（因为，不可能绝对的平均，只是假设），这样压力就降低了很多很多。
延伸：为什么要分表和分区？
日常开发中我们经常会遇到大表的情况，所谓的大表是指存储了百万级乃至千万级条记录的表。这样的表过于庞大，导致数据库在查询和插入的时候耗时太长，性能低下，如果涉及联合查询的情况，性能会更加糟糕。分表和表分区的目的就是减少数据库的负担，提高数据库的效率，通常点来讲就是提高表的增删改查效率。
什么是分表？
分表是将一个大表按照一定的规则分解成多张具有独立存储空间的实体表，我们可以称为子表，每个表都对应三个文件，MYD数据文件，.MYI索引文件，.frm表结构文件。这些子表可以分布在同一块磁盘上，也可以在不同的机器上。app读写的时候根据事先定义好的规则得到对应的子表名，然后去操作它。
什么是分区？
分区和分表相似，都是按照规则分解表。不同在于分表将大表分解为若干个独立的实体表，而分区是将数据分段划分在多个位置存放，可以是同一块磁盘也可以在不同的机器。分区后，表面上还是一张表，但数据散列到多个位置了。app读写的时候操作的还是大表名字，db自动去组织分区的数据。
**MySQL分表和分区有什么联系呢？**
1、都能提高mysql的性高，在高并发状态下都有一个良好的表现。
2、分表和分区不矛盾，可以相互配合的，对于那些大访问量，并且表数据比较多的表，我们可以采取分表和分区结合的方式（如果merge这种分表方式，不能和分区配合的话，可以用其他的分表试），访问量不大，但是表数据很多的表，我们可以采取分区的方式等。
3、分表技术是比较麻烦的，需要手动去创建子表，app服务端读写时候需要计算子表名。采用merge好一些，但也要创建子表和配置子表间的union关系。
4、表分区相对于分表，操作方便，不需要创建子表。
我们知道对于大型的互联网应用，数据库单表的数据量可能达到千万甚至上亿级别，同时面临这高并发的压力。Master-Slave结构只能对数据库的读能力进行扩展，写操作还是集中在Master中，Master并不能无限制的挂接Slave库，如果需要对数据库的吞吐能力进行进一步的扩展，可以考虑采用分库分表的策略。
**1、分表**
在分表之前，首先要选中合适的分表策略（以哪个字典为分表字段，需要将数据分为多少张表），使数据能够均衡的分布在多张表中，并且不影响正常的查询。在企业级应用中，往往使用org_id(组织主键)做为分表字段，在互联网应用中往往是userid。在确定分表策略后，当数据进行存储及查询时，需要确定到哪张表里去查找数据，
数据存放的数据表 = 分表字段的内容 % 分表数量
**2、分库**
分表能够解决单表数据量过大带来的查询效率下降的问题，但是不能给数据库的并发访问带来质的提升，面对高并发的写访问，当Master无法承担高并发的写入请求时，不管如何扩展Slave服务器，都没有意义了。我们通过对数据库进行拆分，来提高数据库的写入能力，即所谓的分库。分库采用对关键字取模的方式，对数据库进行路由。
数据存放的数据库=分库字段的内容%数据库的数量
**3、即分表又分库**
数据库分表可以解决单表海量数据的查询性能问题，分库可以解决单台数据库的并发访问压力问题。
当数据库同时面临海量数据存储和高并发访问的时候，需要同时采取分表和分库策略。一般分表分库策略如下：
中间变量 = 关键字%（数据库数量*单库数据表数量）
库 = 取整（中间变量/单库数据表数量）
表 = （中间变量%单库数据表数量）
实例：
1、分库分表
很明显，一个主表（也就是很重要的表，例如用户表）无限制的增长势必严重影响性能，分库与分表是一个很不错的解决途径，也就是性能优化途径，现在的案例是我们有一个1000多万条记录的用户表members,查询起来非常之慢，同事的做法是将其散列到100个表中，分别从members0到members99，然后根据mid分发记录到这些表中，牛逼的代码大概是这样子：
复制代码 代码如下:
?php
for($i=0;$i 100; $i++ ){
//echo "CREATE TABLE db2.members{$i} LIKE db1.members
";
echo "INSERT INTO members{$i} SELECT * FROM members WHERE mid%100={$i}
";
}
?
2、不停机修改mysql表结构
同样还是members表，前期设计的表结构不尽合理，随着数据库不断运行，其冗余数据也是增长巨大，同事使用了下面的方法来处理：
先创建一个临时表：
/*创建临时表*/
CREATE TABLE members_tmp LIKE members
然后修改members_tmp的表结构为新结构，接着使用上面那个for循环来导出数据，因为1000万的数据一次性导出是不对的，mid是主键，一个区间一个区间的导，基本是一次导出5万条吧，这里略去了
接着重命名将新表替换上去：
/*这是个颇为经典的语句哈*/
RENAME TABLE members TO members_bak,members_tmp TO members;
就是这样，基本可以做到无损失，无需停机更新表结构，但实际上RENAME期间表是被锁死的，所以选择在线少的时候操作是一个技巧。经过这个操作，使得原先8G多的表，一下子变成了2G多。
MySQL 数据表优化设计（三）：CHAR 和 VARCHAR 怎么选？
VARCHAR 和 CHAR 是两种主要的字符串类型，用于存储字符。不幸的是，由于实现的方式依赖于存储引擎，因此很难解释这些字符串在磁盘和内存中如何存储，除了除了常用的 InnoDB 和 MyISAM 外，假设你使用了其他存储引擎，应当仔细阅读存储引擎的文档。
VARCHAR 存储可变长度的字符串，也是最常用的字符数据类型。相比固定长度的类型，VARCHAR 所需的存储空间更小，它会尽可能少地使用存储空间（例如，短的字符串占据的空间）。对于 MyISAM 来说，如果创建表的时候指定了 ROW_FORMAT=FIXED 的话，那么会使用固定的空间存储字段而导致空间浪费。VARCHAR 使用1-2个额外的字节存储字符串的长度：当最大长度低于255字节的时候使用1个字节，如果更多的话就使用2个字节。因此，拉丁字符集的 VARCHAR(10)会使用11个字节的存储空间，而 VARCHAR(1000)则会使用1002个字节的存储空间。
VARCHAR 由于能够节省空间，因此可以改善性能。但是，由于长度可变，当更新数据表的时候数据行的存储空间会变化，这一定程度上会带来额外的开销。如果数据行的长度导致原有的存储位置无法存放，那么不同的存储引擎会做不同的处理。例如 MyISAM 可能产生数据行的碎片，而 InnoDB 需要进行磁盘分页来存放更新后的数据行。
通常，如果最大的列长度远远高于平均长度的话（例如可选的备注字段），使用 VARCHAR 是划算的，同时如果更新的频次很低，那么碎片化也不会是一个问题。需要注意的是，如果使用的是 UTF-8字符集，则实际存储的字节长度是根据字符定的。对于中文，推荐的存储字符集是 utf8mb4。
CHAR 类型的长度是固定的，MySQL 会对每个字段分配足够的存储空间。 存储CHAR 类型值的时候，MySQL 会移除后面多出来的空字符 。值是使用空字符进行对齐以便进行比较。对于短的字符串来说，使用 CHAR 更有优势，而如果所有的值的长度几乎一致的话，就可以使用 CHAR。例如存储用户密码的MD5值时使用 CHAR 就更合适，这是因为 MD5的长度总是固定的。同时，对于字段值经常改变的数据类型来说，CHAR 相比 VARCHAR 也更有优势，因为 CHAR 不会产生碎片。对于很短的数据列，使用 CHAR 比 VARCHAR更高效，例如使用CHAR(1)存储逻辑值的 Y 和 N，这种情况下只需要1个字节，而 VARCHAR 需要2个字节。
对于移除空字符这个特性会感觉奇怪，我们举个例子：
按上面的结果插入数据表后，string2中的前置空格不会移除，但使用 CHAR 类型存储时，string3尾随空格会被移除，使用 SQL 查询结果来检验一下：
得出来的结果如下，可以看到 CHAR 类型的 string3后面的空格被移除了，而 VARCHAR类型的没有。这种情况大多数时候不会有什么问题，实际在应用中也经常会使用 trim 函数移除两端的空字符，但是如果确实需要存储空格的时候，那就需要注意不要选择使用 CHAR 类型：
数据如何存储是由存储引擎决定的，而且存储引擎处理固定长度和可变长度的数据的方式并不相同。Memory 引擎使用固定大小的行，因此它需要分配最大可能的存储空间——即便数据长度是可变的。但是，对于字符串的对齐和空字符截断是由 MySQL 服务端完成的，因此所有存储引擎都是一样的。
与 CHAR 和 VARCHAR 相似的是 BINARY和 VARBINARY，用于存储二进制字节字符，BINARY 的对齐使用字符0的字节值来对齐，并且再获取值的时候不会截断。如果需要使用字符的字节值而不是字符的话，使用 BINARY 会更高效，这是因为比较时，一方面不需要考虑大小写，另一方面是MySQL一次只比较一个字节。
北大青鸟设计培训：mysql数据库的优化方法？
我们都知道，服务器数据库的开发一般都是通过java或者是PHP语言来编程实现的，而为了提高我们数据库的运行速度和效率，数据库优化也成为了我们每日的工作重点，今天，昌平IT培训就一起来了解一下mysql服务器数据库的优化方法。
为什么要了解索引真实案例案例一：大学有段时间学习爬虫，爬取了知乎300w用户答题数据，存储到mysql数据中。
那时不了解索引，一条简单的“根据用户名搜索全部回答的sql“需要执行半分钟左右，完全满足不了正常的使用。
案例二：近线上应用的数据库频频出现多条慢sql风险提示，而工作以来，对数据库优化方面所知甚少。
例如一个用户数据页面需要执行很多次数据库查询，性能很慢，通过增加超时时间勉强可以访问，但是性能上需要优化。
索引的优点合适的索引，可以大大减小mysql服务器扫描的数据量，避免内存排序和临时表，提高应用程序的查询性能。
索引的类型mysql数据中有多种索引类型，primarykey，unique，normal，但底层存储的数据结构都是BTREE;有些存储引擎还提供hash索引，全文索引。
BTREE是常见的优化要面对的索引结构，都是基于BTREE的讨论。
B-TREE查询数据简单暴力的方式是遍历所有记录;如果数据不重复，就可以通过组织成一颗排序二叉树，通过二分查找算法来查询，大大提高查询性能。
而BTREE是一种更强大的排序树，支持多个分支，高度更低，数据的插入、删除、更新更快。
现代数据库的索引文件和文件系统的文件块都被组织成BTREE。
btree的每个节点都包含有key，data和只想子节点指针。
btree有度的概念d=1。
假设btree的度为d，则每个内部节点可以有n=[d+1，2d+1)个key，n+1个子节点指针。
树的大高度为h=Logb[(N+1)/2]。
索引和文件系统中，B-TREE的节点常设计成接近一个内存页大小(也是磁盘扇区大小)，且树的度非常大。
这样磁盘I/O的次数，就等于树的高度h。
假设b=100，一百万个节点的树，h将只有3层。
即，只有3次磁盘I/O就可以查找完毕，性能非常高。
索引查询建立索引后，合适的查询语句才能大发挥索引的优势。
另外，由于查询优化器可以解析客户端的sql语句，会调整sql的查询语句的条件顺序去匹配合适的索引。
北大青鸟设计培训：Mysql数据库的设计和优化？
在JAVA开发中数据库的学习也是我们需要了解的，截下来几篇文章都是关于数据库的设计和应用，那么java课程培训机构废话不多说开始学习吧！ 数据库的设计 数据库设计是基础，数据库优化是建立在设计基础之上的。
好的数据库一定拥有好的设计。
数据库设计的目标是为用户和各种应用系统提供一个信息基础设施和高效的运行环境。
数据库的三大范式 第一范式1NF:所有的域都应该是原子性的，即数据库表的每一列都是不可分割的原子数据项，而不能是集合，数组，记录等非原子数据项。
第二范式2Nf:第二范式在第一范式的基础之上更进一层。
第二范式需要确保数据库表中的每一列都和主键相关，而不能只与主键的某一部分相关(主要针对联合主键而言)。
也就是说在一个数据库表中，一个表中只能保存一种数据，不可以把多种数据保存在同一张数据库表中。
第三范式3Nf:所有字段必须与主键直接相关，而不是间接相关。
也可以理解为字段不要和其他非主键字段相关. 注意:这三个范式尽可能去遵守,不是一定要墨守成规.这只是让我们设计的表的时候,越靠近这些范式,可以使字段尽量的减小冗余.但是有时候也可以根据实际需要小小的违背一下.但是第三范式违反一下还可以接受,但是第一范式别违反. 数据库设计的步骤 需求分析阶段 准确了解与分析用户需求(包括数据与处理)。
是整个设计过程的基础，是最困难、最耗费时间的一步。
概念结构设计阶段 是整个数据库设计的关键--设计数据库的E-R模型图，确认需求信息的正确和完整 Entity_Relationship---实体之间的关系 一对一 一对多 多对一
昆明java培训学校告诉你Mysql数据库的设计和优化？
在JAVA开发中数据库的学习也是我们需要了解的，截下来几篇文章都是关于数据库的设计和应用，那么java课程培训机构废话不多说开始学习吧！
数据库的设计
数据库设计是基础，数据库优化是建立在设计基础之上的。好的数据库一定拥有好的设计。
数据库设计的目标是为用户和各种应用系统提供一个信息基础设施和高效的运行环境。
数据库的三大范式
第一范式1NF:所有的域都应该是原子性的，即数据库表的每一列都是不可分割的原子数据项，而不能是集合，数组，记录等非原子数据项。
第二范式2Nf:第二范式在第一范式的基础之上更进一层。第二范式需要确保数据库表中的每一列都和主键相关，而不能只与主键的某一部分相关(主要针对联合主键而言)。也就是说在一个数据库表中，一个表中只能保存一种数据，不可以把多种数据保存在同一张数据库表中。
第三范式3Nf:所有字段必须与主键直接相关，而不是间接相关。也可以理解为字段不要和其他非主键字段相关.
注意:这三个范式尽可能去遵守,不是一定要墨守成规.这只是让我们设计的表的时候,越靠近这些范式,可以使字段尽量的减小冗余.但是有时候也可以根据实际需要小小的违背一下.但是第三范式违反一下还可以接受,但是第一范式别违反.
数据库设计的步骤
需求分析阶段
准确了解与分析用户需求(包括数据与处理)。是整个设计过程的基础，是最困难、最耗费时间的一步。
概念结构设计阶段
是整个数据库设计的关键--设计数据库的E-R模型图，确认需求信息的正确和完整
Entity_Relationship---实体之间的关系
一对一
一对多
多对一
