随着互联网信息产业的发展，每个公司的数据量都在稳步提升，甚至有的是指数性质的增长，除了有的公司直接跨入大数据之外，对自己公司的数据库压力可想而知，在遇到这些问题之后，勤劳的程序员们就像各种办法对数据库瓶颈进行解决，于是产生了下面的这几种数据库调优方案，大家一起看一下，说不定对你有用呢？注：本文主要以分库分表为重点，后面也有一些其他的性能调优方案
一、数据库瓶颈
不管是IO瓶颈，还是CPU瓶颈，最终都会导致数据库的活跃连接数增加，进而逼近甚至达到数据库可承载活跃连接数的阈值。在业务Service来看就是，可用数据库连接少甚至无连接可用。接下来就可以想象了吧（并发量、吞吐量、崩溃）。
1、IO瓶颈
第一种：磁盘读IO瓶颈，热点数据太多，数据库缓存放不下，每次查询时会产生大量的IO，降低查询速度 -> 分库和垂直分表。
第二种：网络IO瓶颈，请求的数据太多，网络带宽不够 -> 分库。
2、CPU瓶颈
第一种：SQL问题，如SQL中包含join，group by，order by，非索引字段条件查询等，增加CPU运算的操作 -> SQL优化，建立合适的索引，在业务Service层进行业务计算。
第二种：单表数据量太大，查询时扫描的行太多，SQL效率低，CPU率先出现瓶颈 -> 水平分表。
二、分库分表
1、水平分库
概念：以字段为依据，按照一定策略（hash、range等），将一个库中的数据拆分到多个库中。
结果：
- 每个库的结构都一样；
- 每个库的数据都不一样，没有交集；
- 所有库的并集是全量数据；
场景：系统绝对并发量上来了，分表难以根本上解决问题，并且还没有明显的业务归属来垂直分库。
分析：库多了，io和cpu的压力自然可以成倍缓解。
2、水平分表
概念：以字段为依据，按照一定策略（hash、range等），将一个表中的数据拆分到多个表中。
结果：
- 每个表的结构都一样；
- 每个表的数据都不一样，没有交集；
- 所有表的并集是全量数据；
场景：系统绝对并发量并没有上来，只是单表的数据量太多，影响了SQL效率，加重了CPU负担，以至于成为瓶颈。推荐：一次SQL查询优化原理分析
分析：表的数据量少了，单次SQL执行效率高，自然减轻了CPU的负担。
3、垂直分库
概念：以表为依据，按照业务归属不同，将不同的表拆分到不同的库中。
结果：
- 每个库的结构都不一样；
- 每个库的数据也不一样，没有交集；
- 所有库的并集是全量数据；
场景：系统绝对并发量上来了，并且可以抽象出单独的业务模块。
分析：到这一步，基本上就可以服务化了。例如，随着业务的发展一些公用的配置表、字典表等越来越多，这时可以将这些表拆到单独的库中，甚至可以服务化。再有，随着业务的发展孵化出了一套业务模式，这时可以将相关的表拆到单独的库中，甚至可以服务化。
4、垂直分表
概念：以字段为依据，按照字段的活跃性，将表中字段拆到不同的表（主表和扩展表）中。
结果：
- 每个表的结构都不一样；
- 每个表的数据也不一样，一般来说，每个表的字段至少有一列交集，一般是主键，用于关联数据；
- 所有表的并集是全量数据；
场景：系统绝对并发量并没有上来，表的记录并不多，但是字段多，并且热点数据和非热点数据在一起，单行数据所需的存储空间较大。以至于数据库缓存的数据行减少，查询时会去读磁盘数据产生大量的随机读IO，产生IO瓶颈。
分析：可以用列表页和详情页来帮助理解。垂直分表的拆分原则是将热点数据（可能会冗余经常一起查询的数据）放在一起作为主表，非热点数据放在一起作为扩展表。这样更多的热点数据就能被缓存下来，进而减少了随机读IO。拆了之后，要想获得全部数据就需要关联两个表来取数据。
但记住，千万别用join，因为join不仅会增加CPU负担并且会讲两个表耦合在一起（必须在一个数据库实例上）。关联数据，应该在业务Service层做文章，分别获取主表和扩展表数据然后用关联字段关联得到全部数据。
三、分库分表工具
- sharding-sphere：jar，前身是sharding-jdbc；
- TDDL：jar，Taobao Distribute Data Layer；
- Mycat：中间件。
注：工具的利弊，请自行调研，官网和社区优先。
四、分库分表步骤
根据容量（当前容量和增长量）评估分库或分表个数 -> 选key（均匀）-> 分表规则（hash或range等）-> 执行（一般双写）-> 扩容问题（尽量减少数据的移动）。
扩展：MySQL：分库分表与分区的区别和思考
五、分库分表问题
1、非partition key的查询问题
基于水平分库分表，拆分策略为常用的hash法。
端上除了partition key只有一个非partition key作为条件查询
映射法
基因法
注：写入时，基因法生成user_id，如图。关于xbit基因，例如要分8张表，23=8，故x取3，即3bit基因。根据user_id查询时可直接取模路由到对应的分库或分表。根据user_name查询时，先通过user_name_code生成函数生成user_name_code再对其取模路由到对应的分库或分表。id生成常用snowflake算法。
端上除了partition key不止一个非partition key作为条件查询
映射法
冗余法
注：按照order_id或buyer_id查询时路由到db_o_buyer库中，按照seller_id查询时路由到db_o_seller库中。感觉有点本末倒置！有其他好的办法吗？改变技术栈呢？
后台除了partition key还有各种非partition key组合条件查询
NoSQL法
冗余法
2、非partition key跨库跨表分页查询问题
基于水平分库分表，拆分策略为常用的hash法。
注：用NoSQL法解决（ES等）。
3、扩容问题
基于水平分库分表，拆分策略为常用的hash法。
水平扩容库（升级从库法）
注：扩容是成倍的。
水平扩容表（双写迁移法）
- 第一步：（同步双写）修改应用配置和代码，加上双写，部署；
- 第二步：（同步双写）将老库中的老数据复制到新库中；
- 第三步：（同步双写）以老库为准校对新库中的老数据；
- 第四步：（同步双写）修改应用配置和代码，去掉双写，部署；
注：双写是通用方案。
其他性能优化方案
1. 永远为每张表设置一个 ID
每张表都应该设置一个 ID 字段为主键，该主键应为 INT 或 UNSIGNED 类型，并设置上自动增加的 AUTO_INCREMENT 标志。因为使用 VARCHAR 类型的主键，会使得性能下降。
这里，只有一个情况是例外，那就是 “关联表” 的 “外键”，也就是说，这个表的主键，通过若干个别的表的主键构成。我们把这个情况叫做 “外键”。比如：有一个 “学生表” 有学生的 ID，有一个 “课程表” 有课程 ID，那么，“成绩表” 就是 “关联表” 了，其关联了学生表和课程表，在成绩表中，学生 ID 和课程 ID 叫 “外键” 其共同组成主键。
2. 为搜索字段建索引
这个简单来说就是创建表时，如果后面针对这个表的查询总会涉及到某个字段，或者在代码里面写好了的字段，这种就可以考虑去建索引。
3. 使用 ENUM 而不是 VARCHAR
ENUM 类型是非常快和紧凑的。在实际上，其保存的是 TINYINT，但其外表上显示为字符串。这样一来，用这个字段来做一些选项列表变得相当的完美。
如果你有一个字段，比如 “国家”，你知道这些字段的取值是有限而且固定的，那么，你应该使用 ENUM 而不是 VARCHAR。
ENUM 是 MySQL 数据库特有的字段类型，使用后会影响迁移到其它数据库。所以，如果以后要改数据库的情况，一定要慎用。
4. 尽可能的使用 NOT NULL
应该总是让你的字段保持 NOT NULL，这样相对比较节省空间（NULL 也是需要空间的）。
5. 把IP地址存成 UNSIGNED INT
如果使用整形来存放 IP 而不是 VARCHAR(15) 字段，节省了很多的空间（需要写一个 IP 转换的函数）。
6.必须使用UTF8字符集
万国码，无需转码，无乱码风险，节省空间
7.EXPLAIN 你的 SELECT 查询
使用 EXPLAIN 关键字可以让你知道 MySQL 是如何处理你的 SQL 语句的。这可以帮你分析你的查询语句或是表结构的性能瓶颈。
查看 rows 列可以让我们找到潜在的性能问题。
8.从 PROCEDURE ANALYSE() 取得建议
PROCEDURE ANALYSE() 会让 MySQL 去分析字段和其实际的数据，并会提供一些有用的建议（只是建议）。只有表中有实际的数据，这些建议才会变得有用，因为要做一些大的决定是需要有数据作为基础的。
mysql>select * from mysql.user procedure analyse();优化 SQL 语句
1. 使用查询缓存
查看是否开启缓存：
mysql> select @@query_cache_type;开启缓存，修改 my.cnf，在末尾加入，重启MySQL生效：
query_cache_type = 1query_cache_size = 600000启用MySQL查询缓存可以极大地减低数据库服务器的CPU使用率，实际使用情况是：开启前CPU使用率120%左右，开启后降到了10%。不过使用查询的缓存的限制非常多。当使用场景中以只读为主，很少有更新的情况时，再考虑开启查询缓存。
2. 当只要一行数据时使用 LIMIT 1
在这种情况下，加上 LIMIT 1 可以增加性能。这样一样，MySQL 数据库引擎会在找到一条数据后停止搜索，而不是继续往后查少下一条符合记录的数据。
3. 在 JOIN 表的时候使用相当类型的例，并将其索引
如果有很多 JOIN 的操作，JOIN 的字段应该加索引，同时保证这些字段的类型一致。
4. 避免 SELECT *
从数据库里读出越多的数据，那么查询就会变得越慢。所以，应该养成需要什么就取什么的好的习惯。
5. 拆分大的 DELETE 或 INSERT 语句
如果你需要在一个在线的网站上去执行一个大量的 DELETE 或 INSERT 查询，你需要非常小心，要避免你的操作让你的整个网站停止相应。因为这两个操作是会锁表的，表一锁住了，别的操作都进不来了。
执行这种大量的 DELETE 和 INSERT，可以分成几部分执行，每执行一部分就暂停一下再执行。
基本对于sql的调优方案，就是在最初设计表----中间进行sql的调优---最后直接调整表，希望这份文档对大家有帮助，欢迎关注+点赞+转发，谢谢