前言
可能说起mysql，哪怕一个刚入门的小白都会跟我说，太低级了，这玩意有什么可整的，没啥意思，除了增删改查，索引，序列，还有什么呢？真当哥们是二B了呀
我就哈哈一笑，小伙子，还是太年轻啊，来看这张图（平台原因，像素不够，需要高清图，私信“架构图”获取）
怎么样，兄弟，密集恐惧症是不是犯了啊，还敢说mysql简单嘛？但是这样说的话是不是跟我的题目有点不一样啊，别着急，接着往下看
增删改查什么的都不说，咱就以mysql的优化为例，来证明一下，为什么我说真的不难
既然要说MySQL优化，那我们起码要先知道现在的MySQL已经为了让操作更容易，给我们提供了那些方便吧
MySQL24种系统特性
1．使用 C和C++编写，并使用了多种编译器进行测试，保证了源代码的可移植性。
2．支持AIX、FreeBSD、HP-UX、Linux、Mac OS、NovellNetware、OpenBSD、OS/2 Wrap、Solaris、Windows等多种操作系统。
3．为多种编程语言提供了API。这些编程语言包括C、C++、Python、Java、Perl、PHP、Eiffel、Ruby,.NET和 Tcl 等。
4．支持多线程，充分利用 CPU 资源。
5．优化的SQL查询算法，有效地提高查询速度。
6．既能够作为一个单独的应用程序应用在客户端服务器网络环境中，也能够作为一个库而嵌入到其他的软件中。
7．提供多语言支持，常见的编码如中文的GB 2312、BIG5，日文的Shift_JIS等都可以用作数据表名和数据列名。
8．提供TCP/IP、ODBC 和JDBC等多种数据库连接途径。
9．提供用于管理、检查、优化数据库操作的管理工具。
10．支持大型的数据库。可以处理拥有上千万条记录的大型数据库。
11．支持多种存储引擎。
12.MySQL 是开源的，所以你不需要支付额外的费用。
13.MySQL 使用标准的SQL数据语言形式。
14.MySQL 对 PHP 有很好的支持，PHP是比较流行的 Web 开发语言。
15.MySQL是可以定制的，采用了GPL协议，你可以修改源码来开发自己的 MySQL 系统。
16.在线 DDL/更改功能，数据架构支持动态应用程序和开发人员灵活性（5.6新增）
17.复制全局事务标识，可支持自我修复式集群（5.6新增）
18.复制无崩溃从机，可提高可用性（5.6新增）
19.复制多线程从机，可提高性能（5.6新增）
20.3倍更快的性能（5.7[7]新增）
21.新的优化器（5.7新增）
22.原生JSON支持（5.7新增）
23.多源复制（5.7新增）
24.GIS的空间扩展[8]（5.7新增）
好哒，那知道了这些之后，我们接下来看调优，这也是在面试的过程中被经常问到的一些问题，而且随着互联网的发展，数据量的增大，不想引入大数据体系的，那只能在数据库上下功夫了，那么对于数据库的调优，不知道各位觉得难吗？其实真的不难，不信，看下面
MySQL调优思维导图
看到这张思维导图，从上往下，不知道在看这篇文章的你有没有回想一下自己的知识体系中，这些方面是不是很清晰呢？
好，看完这句话，我的重点要来了，你在回想这些知识点的时候，是不是对你的知识点进行了一个回顾和梳理，查漏补缺，你也知道了自己知识点上的不足，是不是可以有针对性的进行学习呢？
我们以分库和分表为例去进行一个商讨
分库分表：
1、水平分库
概念：以字段为依据，按照一定策略（hash、range等），将一个库中的数据拆分到多个库中。
结果：
每个库的结构都一样；
每个库的数据都不一样，没有交集；
所有库的并集是全量数据；
场景：系统绝对并发量上来了，分表难以根本上解决问题，并且还没有明显的业务归属来垂直分库。
分析：库多了，io和cpu的压力自然可以成倍缓解。
2、水平分表
概念：以字段为依据，按照一定策略（hash、range等），将一个表中的数据拆分到多个表中。
结果：
每个表的结构都一样；
每个表的数据都不一样，没有交集；
所有表的并集是全量数据；
场景：系统绝对并发量并没有上来，只是单表的数据量太多，影响了SQL效率，加重了CPU负担，以至于成为瓶颈。推荐：一次SQL查询优化原理分析
分析：表的数据量少了，单次SQL执行效率高，自然减轻了CPU的负担。
3、垂直分库
概念：以表为依据，按照业务归属不同，将不同的表拆分到不同的库中。
结果：
每个库的结构都不一样；
每个库的数据也不一样，没有交集；
所有库的并集是全量数据；
场景：系统绝对并发量上来了，并且可以抽象出单独的业务模块。
分析：到这一步，基本上就可以服务化了。例如，随着业务的发展一些公用的配置表、字典表等越来越多，这时可以将这些表拆到单独的库中，甚至可以服务化。再有，随着业务的发展孵化出了一套业务模式，这时可以将相关的表拆到单独的库中，甚至可以服务化。
4、垂直分表
概念：以字段为依据，按照字段的活跃性，将表中字段拆到不同的表（主表和扩展表）中。
结果：
每个表的结构都不一样；
每个表的数据也不一样，一般来说，每个表的字段至少有一列交集，一般是主键，用于关联数据；
所有表的并集是全量数据；
场景：系统绝对并发量并没有上来，表的记录并不多，但是字段多，并且热点数据和非热点数据在一起，单行数据所需的存储空间较大。以至于数据库缓存的数据行减少，查询时会去读磁盘数据产生大量的随机读IO，产生IO瓶颈。
分析：可以用列表页和详情页来帮助理解。垂直分表的拆分原则是将热点数据（可能会冗余经常一起查询的数据）放在一起作为主表，非热点数据放在一起作为扩展表。这样更多的热点数据就能被缓存下来，进而减少了随机读IO。拆了之后，要想获得全部数据就需要关联两个表来取数据。
但记住，千万别用join，因为join不仅会增加CPU负担并且会将两个表耦合在一起（必须在一个数据库实例上）。关联数据，应该在业务Service层做文章，分别获取主表和扩展表数据然后用关联字段关联得到全部数据。
好了，到这里，分库和分表的操作基本就完成了，不知道大家有没有什么感觉，如果知识只是单纯的去看这些知识点，你能记住多久呢？反正如果我长时间不看，就忘了，，但是我不怂 啊，因为我有这张图，而且比展示出来的更加详细，所以当我需要用到时候就可以看了，直接就可以拿出来看，哪怕只有10分钟就够了。
不知道你怎么感觉，其实我觉得你也可以，当你学完之后，在我的这张知识图谱上，把会的知识点进行整理，不会的知识点在学完之后也可以整理到这份图谱中，即使后面用不到有所遗忘，但是当你需要这些资料的时候，比方说你要面试了，那你会觉得慌嘛？是不是拿出来这张图就可以啊，想看那个知识点点开看一下就可以了。
其实，今天的标题是有一点不是特别准确，其实每一个程序员们都清楚，不仅仅是数据库，其他 的技术也是这样，从Java基础（源码等）---架构师---大数据----人工智能，哪怕你不从事这一行，难道就不能去学习了吗？互联网发展这么快，天知道那天就能用到呢？
人无远虑必有近忧，好了，兄弟们，今天就到这里吧
关注我，后期不断更新新的文章，包括面试、技术、学习等技术，关注我，不迷路，有什么问题，也可以在评论区或者私信和我交流