原文地址：https://www.toutiao.com/i6600157332582171150

调优的目的

多数时候数据库会成为整个系统的瓶颈，比如大的数据量的插入与修改，频繁的亦或是高流量的访问，都会对数据库系统带来很大的压力。以下是小编工作时总结的经验，提供给大家，仅供参考。

调优的手段

1、缓存。缓存是解决这类问题的一把手。它既可以加快整个系统（并非数据库系统，使用缓存的时候并没有去访问数据库）的访问速度，也可以减少数据库负载的压力。而缓存一般都是在查询中使用，我们并不希望每一次的查询都要去访问数据库。那么我们的缓存做到哪里呢？一般情况下版的系统都会存在服务层这一结构层次，而数据访问层一般都只是对于数据库的增删改查的接口的定义，所以我们的缓存就需要在服务层进行。而mybatis中的一级缓存，通过判断查询条件是否要访问数据库，查询条件与某一次相同，则直接返回缓存中的数据，查询条件不同则需要访问数据库，并且将结果放到缓存中。

2、当只需要一条数据时使用LIMIT 1.我们作为开发者，是能够知道我们需要的数据的条数的，若已经知道结果只有一条的时候，一定要使用limit 1 ，这样一来，MySQL在查询到一条数据之后，会立即停止搜索，这会带来性能上的提升。

3、避免select * ，取之所需。公司里的一些同事，无论查询什么都是直接select *，然后再从结果中取想要的字段。这样做的话，平白无故的给MySQL带来了不必要的负担，因为从数据库中读出越多的数据，查询就会变得越慢。所以，以后看到select * 的时候，想一下是否可以在这里进行一些优化。

4、为每张表设置一个id作为其主键。这个id最好是一个int类型的，推荐使用unsigned，并将其设置为自动增加auto_increment。之前就出现过一个同事将varchar的字段作为主键的情况， 然后在数据量较大的时候，数据库这个环节速度变得不是很友好，所以尽量不要使用varchar来当主键，它会使得性能出现下降。而且在某些情况下，id这个主键字段是非常重要的。

5、使用enum而不是varchar。实际上，enum保存的是tinyint类型，但其显示为字符串。用这个字段来作一些选项列表就变得很合适了。比如你有一个字段，比如“性别”、“状态”或“所属部门”等，你知道这些字段的值是固定且有限的，那么可以考虑使用enum。对于性别这个字段，一般分为两种，有可能还有保密这种情况，我们可以使用数字1、2、3来分别表示这三张情况，而对于这些数字含义的区分则是业务层的事情了。我们需要将一些繁琐的需要计算的步骤全部放到业务层（或者说是服务层），因为系统的瓶颈在数据库，我们不能将过多的计算过程压到数据库上面去。数据库存储的数据应该尽量简单，但是，我们会在业务层结合具体的业务，对这些简单的数据进行分析。

6、尽可能的使用not null。除非你有一个很特别的原因要去使用null值，你应该总让你的字段保持为not null。

7、选择正确的存储引擎。myisam适合一些需要大量查询的应用。但其对于大量写操作并不是很好。因为它使用到的是表级锁，所以在你更新的时候，整张表都会被锁起来，试想一下，当你在更新某一行数据的时候，导致其他的行都无法被访问，这会不会 很难受呢。另外，myisam对于select count(*)这类操作的计算时很快的。而至于innodb而言，对于一些小的应用，它会比myisam还慢。它支持的是行级锁，于是写操作较多的时候，它会更加优秀。它还支持一些更高级的应用，比如说：事务。

8、拆为搜索的字段建立索引。不要以为只有标的逐渐可以建立索引，如果某个字段你总要拿来做搜索，那么为它简历索引吧。但是，不要以为建立索引，就可以为所欲为。其中有一些常用的规则需要去遵循以下的。

建立索引常用的规则

1、表的主键、外键必须有索引；

2、数据量超过300的表应该有索引；

3、经常与其他表进行连接的表，在连接字段上应该建立索引；

4、经常出现在Where子句中的字段，非凡是大表的字段，应该建立索引；

5、索引应该建在选择性高的字段上（枚举型字段不建索引）；

6、索引应该建在小字段上，对于大的文本字段甚至超长字段，不要建索引；

7、复合索引的建立需要进行仔细分析；尽量考虑用单字段索引代替：

A、正确选择复合索引中的主列字段，一般是选择性较好的字段；

B、复合索引的几个字段是否经常同时以AND方式出现在Where子句中？单字段查询是否极少甚至没有？假如是，则可以建立复合索引；否则考虑单字段索引；

C、假如复合索引中包含的字段经常单独出现在Where子句中，则分解为多个单字段索引；

D、假如复合索引所包含的字段超过3个，那么仔细考虑其必要性，考虑减少复合的字段；

E、假如既有单字段索引，又有这几个字段上的复合索引，一般可以删除复合索引；

8、频繁进行数据操作的表，不要建立太多的索引；

9、删除无用的索引，避免对执行计划造成负面影响；

以上是一些普遍的建立索引时的判定依据。一言以蔽之，索引的建立必须慎重，对每个索引的必要性都应该经过仔细分析，要有建立的依据。因为太多的索引与不充分、不正确的索引对性能都毫无益处：在表上建立的每个索引都会增加存储开销，索引对于插入、删除、更新操作也会增加处理上的开销。另外，过多的复合索引，在有单字段索引的情况下，一般都是没有存在价值的；相反，还会降低数据增加删除时的性能，凡是对频繁更新的表来说，负面影响更大.

当然还有很多其他的调优方法，例如读写分离，表分区等，后续会带大家更深入的了解。

注意：本文归作者所有，未经作者允许，不得转载