“ MySQL是一个开源的关系型数据库，由瑞典MySQL AB 公司开发，目前属于Oracle 旗下产品。”
说到关系型数据库，我们脑海里浮现的大概就是Oracle、SQL Server 、MySQL了，但其实关系型数据库还有DB2、Microsoft Access等，只不过最常见的还是Oracle、SQL Server 、MySQL。本篇文章关于MySQL的安装和配置就不多说了，还没有安装过数据库的小伙伴，可以移步到小程序的知识模块，那里有你想要的哦点击前往小程序
01
—
关系型数据库
在正式说MySQL之前，我们先来说一下什么叫关系型数据库。
关系型数据库是采用了关系模型来组织数据的数据库，而关系模型指的是二维表格模型,因而一个关系型数据库就是由二维表及其之间的联系组成的一个数据组织。
关系型数据库的最大特性就是事物的一致性(ACID是关系型数据库需要遵循的规则：A (Atomicity) 原子性；C (Consistency) 一致性；I (Isolation) 独立性；D (Durability) 持久性。这四个规则我们这里先不讨论)。
关系型数据库有这几个优点：
1、容易理解：二维表结构是非常贴近逻辑世界一个概念，关系模型相对网状、层次等其他模型来说更容易理解。
2、使用方便：通用的SQL语言使得操作关系型数据库非常方便。
3、易于维护：丰富的完整性(实体完整性、参照完整性和用户定义的完整性)大大减低了数据冗余和数据不一致的概率。
4、支持SQL，可用于复杂的查询。
关系型数据库有这几个缺点：
1、为了维护一致性所付出的巨大代价就是其读写性能比较差；
2、固定的表结构；
3、高并发读写需求：针对网站类用户的并发性访问非常高,而一台数据库的最大连接数有限,且硬盘I/O有限,其不能满足很多人同时连接
4、海量数据的高效率读写：当表中数据量太大,每次的读写速率都将非常缓慢；
说到这里，我们知道了什么是关系型数据库，知道关系型数据库的优点和缺点，我想大家对于关系型数据中读写性能差会比较关心，因为我们很多时候都在尽量优化SQL语句，以此来达到相对的高效。此外，在前面我们聊Redis的过程中，我们说了Redis属于非关系型数据库，通常它能有效的解决关系型数据库查询慢的缺点，所以我们通常将非关系型数据库作为数据缓存和关系型数据库联合使用。
下面我们来详细的了解一下MySQL的实际使用。
02
—
MySQL的实际使用
对于mysql简单的增删该查我们同样也不再赘述，大家可以前往小程序，在知识模块转载的有菜鸟教程的简单SQL语句，当然如果你使用电脑也可以直接前往菜鸟教程去查看。现在我们要聊的是一些SQL查询的优化。
为什么需要SQL优化呢？因为一些不合理SQL语句会大大的增加我们服务器的开销，一毫秒可以查询出来的数据，你用了一秒这还不能说明问题吗。
如何知道SQL是否需要优化呢？
首先你要想知道SQL是否需要优化，大多数的时候凭感觉就能知道，网页数据迟迟不展示，你就可以看一下SQL语句了。
然后是如何快速的定位到SQL语句呢？
可以通过开启慢查询日志，查看执行比较慢的SQL。
知道SQL语句后，如何解决SQL执行慢的问题呢？
那我想你需要知道explain这个关键字有什么用途，explain 命令可以获取 select 语句的执行计划。 我们可以知道以下信息：表的读取顺序，数据读取操作的类型，哪些索引可以使用，哪些索引实际使用了，表之间的引用，每张表有多少行被优化器查询等信息。格式如下（大家可以执行看看）
代码语言：javascript复制explain select * from table;
在我们拿到Explain给我们一些数据之后我们要怎么做呢？这里做了如下的总结：
一.对于存在text，longtext这长度很长的字段的的表最好不要在全表扫描的时候用select * ，最好将此类字段排除出去，尤其在获取数据比较多的时候，因为无用字段的读取也会增加查询时间，当无用字段长度过大时，查询的时间更是夸张。
这里来看下效果对比,其中content是longtext类型，50条数据用了3.27S。
一般来说，存在此类型字段的数据会通过ID一条一条的去查，而不是在不用的时候去取，所以这一点其实大家都很好去避开。
二.添加合适的索引
其实这个基本上不用说，大家都知道去增加索引，但是加索引也是有一定的技巧的。首先对于查询频率高的字段创建索引，某些查询频率很低的字段我们没有添加索引的必要，因为维护索引对于数据库来说也是一种开销；然后索引的数目不宜太多，原因也很简单：
每创建一个索引都会占用相应的物理控件，而且过多的索引会导致insert、update、delete语句的执行效率降低；再然后就是使用数据量少的索引，因为如果索引的值很长，那么查询的速度会受到影响。例如，对一个CHAR(100)类型的字段进行全文检索需要的时间肯定要比对CHAR(10)类型的字段需要的时间要多。最后就是对于Text，longText类型的字段尽量使用前缀来索引，因为如果索引字段的值很长，最好使用值的前缀来索引。例如，TEXT和BLOG类型的字段，进行全文检索会很浪费时间。如果只检索字段的前面的若干个字符，这样可以提高检索速度。
三.字段设计尽可能的使用 NOT NULL
为什么呢？因为null其需要额外的空间，并且，在你进行比较的时候，你的程序会更复杂。 当然，这里并不是说你就不能使用NULL了，现实情况是很复杂的，依然会有些情况下，你需要使用NULL值。在MySQL的官方文档中说到：空列需要行中额外的空间来记录它们的值是否为空。
四：选择正确的存储引擎
在 MySQL 中有两个存储引擎 MyISAM 和 InnoDB，每个引擎都有利有弊。
MyISAM 适合于一些需要大量查询的应用，但其对于有大量写操作并不是很好。甚至你只是需要update一个字段，整个表都会被锁起来，而别的进程，就算是读进程都无法操作直到读操作完成。另外，MyISAM 对于 SELECT COUNT(*) 这类的计算是超快无比的。
InnoDB 的趋势会是一个非常复杂的存储引擎，对于一些小的应用，它会比 MyISAM 还慢。他是它支持“行锁” ，于是在写操作比较多的时候，会更优秀。并且，他还支持更多的高级应用
五：SQL优化
这里就不具体的说如何进行SQL优化了，因为深层次的太过于复杂，浅层次的大家都知道。只能说如果服务器内存比较充足，如果你选择合适的存储引擎，数据库字段设计合理，适当的增加索引之后，数据查询仍然很慢的情况下，你就应该往实际的SQL语句中下功夫了，这个时候你就用上了explain提供给你的数据，比如是否用了太多的子连接，是否用了排序，语句中是否用了union，等等。但是我不得不说一句，并不是SQL越长执行效率越慢，我见过公司的DBA帮我写一个邮件查询的语句，写了有五六行左右，但是查询速度都是在毫秒级别。
六：结合业务去分析SQL
如果数据量过大，我们其实很难解决这类问题，因为这可能已经不再是SQL语句的问题了，尤其是我们并不是专业的DBA。这种情况下，如过实际的业务场景中，数据量达到上千万，上亿（当然这个数据量的公司，肯定不会让我们Java开发去写语句了）MySQL数据库的性能肯定吃不销，如果真的给我们去处理，我能想到最有效的方法的就是分表和分区，然后通过Java代码进行过滤，快速定位到数据所在地。
如果上千万的数据存在一张表里，我觉得搁在大多数的开发身上都会觉得头大，这个时候还是多多请教前辈比较好，因为数据不容有失，否则就要跑路了。
OK，今天就说到这里，觉得文章和小程序还不错，请多多转发
