数据库的使用你可能忽略了这些 (续)

前言

以前写过一篇文章《数据库的使用你可能忽略了这些》，主要是从一些你们使用使用时容易忽略的地方，如：字段长度、表设计等来讲明，这篇文章一样也是这样的主题，只是从另外的几个方面来讲说数据库使用中，容易忽略，致使入坑的地方。

合理预估数据量

在数据库进行表设计的时候，就应该评估可能产生的数据量，数据量会对整个开发和代码的健壮性有很大的影响。开发一个数据量万级别、十万级别、百万级别、千万以上级别数量的应用，在开发思路、技术选型、架构都能都要很大的差异。
基本上的个人原则是：

• 万级别的数据库，能够随意一点，SQL编写有好的习惯；
• 十万级别，注意索引，注意联表性能；
• 百万级别，尽可能减小联表，尽可能不要作汇总查询，如查总数 ；
• 千万以上级别，除缓存以外，使用分表分库 ；

不少系统由于在设计表的时候，没有很好的预估的后期系统的发展，致使上线不久就出现没法支撑的状况，代码上太多的联表查询，不在意基础的SQL性能，致使数据库的瓶颈很快就显现出来，不得不重构系统。设计数据库的时候，必定是基于业务进行设计的，对业务的发展有必定的预估，看得长远一点。

合理预估并发访问量

数据库有自然的瓶颈，就是并发量。咱们通常会经过缓存来减小数据库的并发链接，以及对数据库的操做，数据库的并发，不是只有大型平台才会遇到，不少中小平台其实也会面临这样的问题，例如：

循环进行数据库的操做

这个问题，上一篇文章我也提到过，不要在循环里进行数据库的操做，这个会直接致使数据库链接数暴增，影响很是严重。虽然是个比较低级的问题，可是出现的几率实际上是很是高的，在我身边看到不少不少这种案例了，这种问题，就是须要程序员本身自己避免这些问题，固然，也能够经过一些手段去监控，找到这些问题，只是会比较麻烦一点。

业务自己的高频次数据请求

其实有些业务，即便是中小型的平台，也会有高并发请求数据库的状况，常见的例子如：日志。例如，咱们须要抓取到全部人的操做日志，或者全部模块的加载时间，而且持久化保存。若是，当初选型经过Mysql去记录这些数据，那么就很容易遇到高并发的问题。这种就是属于选型的错误了。

数据库对高并发的处理一直是短板，因此应该尽可能避免高并发的数据库操做，查询经过缓存处理，增删改这能够经过MQ或者Kafka这样的工具异步进行处理，若是对数据库的结构化要求不高，则能够用hbase或者hive进行数据库的保存。

数据库线程池的合理使用

如今数据库的操做都是使用线程池的，线程池主要是用来控制数据库的链接数，其实链接池是不属于数据库范畴，可是，通常咱们使用和数据库结合很是紧密，因此在这里一并说明。
通常线程池都会有这样的几个参数：

参数	说明
最小链接数	不论是否有数据库的操做，这几个链接都会一直存在，
最大链接数	容许的最大的链接数，若是超过了这个数据，则没法申请链接，只能等待，或者异常
回收时间	多长时间会对全部的链接进行一次断开，而后从新链接。
释放时间	多长时间没有进行操做的链接，会释放

基本全部的链接池都会有这几个参数，可能不一样的链接池参数名不一样，可是做用是同样的。 这里咱们重点说一下最大链接数，这个是很容易忽略的一个设置。
不少人设置最大链接数的时候，喜欢设置的很大，例如设置为5000，可是通常mysql的数据库一个实例链接默认才1000，链接数超过这个了数据库也没法处理，设置的再大实际上是没用的。

服务器数量 * 最大链接数 < 数据库最大链接数

并且，这仍是在一个实例，一个数据库的状况下，至于多个数据库：
我建议

服务器数量 * 最大链接数 * 数据库数量 < 数据库最大链接数

若是单个数据库占用了太多的数据库链接，会影响到其余数据库，致使其余数据库也没法使用。
固然，这个值你们能够根据业务去进行合理的估算，高频的业务分配多一点，低频的业务分配少一点。不要盲目的一味设置链接池的最大值。

总结

现在，虽然各类各样的存储方式出现，可是关系数据库一直是咱们系统的最重要的组成部分，尽可能不要过早暴露数据库应对并发的短板，设计数据库和操做数据库在咱们的开发中应该是一件很神圣的事情，认证对待关系的数据库的每个操做才是明智之举。

扩展阅读：
数据库的使用你可能忽略了这些
学会数据库读写分离、分表分库——用Mycat，这一篇就够了！

---

欢迎你们关注个人公众号交流、学习、第一时间获取最新的文章。
微信号：itmifen