性能优化-数据库

数据库优化涉及的内容比较多，并且它是一个长期的过程！

同样本篇和其他一样，不讲类似数据库三范式这样的东西，因为我认为这不算优化的范围！直接进入正文吧。

索引

有人说过，懂得如何使用索引，就懂得如何优化数据库了。当然，这肯定有一些夸张，但是从侧面反映了索引的重要性。

索引有多种形式，首先是主键索引，对于主键索引，是普通索引外加唯一约束。建议尽量不要使用。因为要确保唯一性，在插入时，会锁住全表，进行唯一检查。

其次是普通索引，在主要的列上创建索引，不要建在数据量大的列上，因为大数据的列，索引本身的数据会非常大，难以检索。

最后是组合索引，组合索引在多列联合查询时效率远远高于单列索引。在使用组合索引的时候，一定要牢记：条件的顺序和组合索引的列顺序保持一致，不然组合索引没有任何作用。

既然索引如此管用，肯定有人会想，那是否可以在所有列上都创建索引 ？

肯定不能！因为索引的列过多，索引本身的数据也会变大，会拉低检索的速度。同时，在更新数据时，需要更新所有索引数据，索引过多，你就等着哭吧。

查询缓存

又是缓存，数据库也有缓存？ 你没看错。数据库也有缓存！多数数据库需要手动开启查询缓存。缓存根据SQL本身作为KEY进行缓存。开启缓存后，数据库不用再次解析SQL，有效提升查询的效率。

既然提升效率，为什么数据库没有默认开启呢？ 因为查询是很频繁的操作，大多数数据也是碎片化；加上更新任何表数据，就会清空相应的缓存。这样的频繁且细小的操作，不可避免的会产生很多的内存碎片，需要DBA定时整理相关的内存碎片，不然就会导致Server机整体的性能变慢。所以使用查询缓存时，请考虑这方面的因素。

分析查询

很多开发人员，在执行SQL时，根本不知道SQL的瓶颈在哪里，又何谈优化呢？

今天我就给大家推荐数据库内置功能：Explain分析。对你不确定的查询进行分析，数据库会告诉你瓶颈在哪里，

这是个非常强大的功能，强烈推荐！

开启慢查询

开篇我就强调，数据库优化是一个长期的过程。为什么这么说呢？因为系统刚做好时，开发人员根本不能预测那些功能使用较多，更加预测不了那些SQL拉低系统的性能。这时候就需要开启数据库的慢查询，数据库会自动记录所有SQL的执行次数以及执行所花费的时间，有了这些数据，是不是就有了优化的方向？

分表

在你正确的创建索引，也成功解决了数据库的所有的慢查询，这时候由于单表数据实在过大，比如百万数据，基数太大，如何优化都解决不了问题。这时候你就要考虑分表了。

针对大数据的表，根据特定的栏位（日期/主键），让数据库根据自动拆分为多个小表。

在查询时，数据库也会自动到特定的分区表查询，应用端根本不用关心这些逻辑。是不是很心动？动手试试吧。

读写分离

数据库有两种锁，一种是表锁，另外一种是行锁。数据库默认的锁都是表锁，至于表锁和行锁的对比，请自行百度。

一旦有数据更新，就会锁住整张表，查询也要等待锁释放。

虽说有二八定律（更新和查询比例是二八分成），但是在一些管理系统中，这个比例是不靠谱的！！ 如果有一定的数据量，频繁的锁会拉低查询的性能，如何优化都不会有任何效果。

这时候就需要用到读写分离。使用主从数据库，主数据库接受更新，并实时同步到从数据库。而上篇中，我们讲到在应用层实现查询和更新的分离, 两者结合，所向披靡呀！！

在一些小型的系统中，以上方法足以应付大部分情况了，而且实施的成本都不太高。

截止目前为止，【性能优化】篇已经写完。下一阶段的主题还在寻觅，如果你有好的建议，请回复公众号，或者回复文章即可。

如果您对我的文章有兴趣，请关注我的微信公众号，谢谢