点击蓝色“有关SQL”关注我哟
加个“星标”，天天与10000人一起快乐成长
学一门技术要体系化，前两天还在文章中，提出这样的概念。不知道，你们是不是都忘记了？
我看是的，忘得都差不多了。连打卡拿书都忘记了，还有是什么忘不了的。
就在那篇文章刚发出的当天，小伙伴就在群里提出问题了，“我的数据库表有600多万数据了，以前拍着胸脯点给老板看，多快，多快，一点问题没有。现在老板来了，我都假装去WC”
咳咳，才600万，遇到 6 个亿的表，你是不是要哭了。
是的，数据量少，什么都好说。老板让你勾着他的肩，搭着他的背，彷佛明天流量就上亿，后天就可以去街上敲钟了。但没想到的是，数据库宕机在明天的晚上。到时，老板就该请你吃茶了。
为什么？流量上亿了，你那破表还仅仅只有600万数据么，当KPMG，DTT都是吃素的么。
所以，言归正传，业务总是在发展的，数据也总是在不断生长的。他们都需要加倍的呵护，如果连个生辰都不给他们，是不是太敷衍了。
一切为了集成
数据集成，对于做数据库的同学来说，简直太熟悉不过了。除非你还是在做课堂练习，除了简单CRUD的练习，Spring Boot This, Spring Boot That, 而对于数据集成一无所知，那确实不能怪你。项目不大，则数据流无意义。
等到进入正式的项目组，组与组之间的数据交流，就是避无可避的天坑了。如果不再数据表中，加入 CreateDate 和 UpdateDate 来标注下数据的新鲜度，那么当其他组要拿你数据时，每次都能把你的数据库都拖垮。因为你没办法啊，只能一次全给咯。
当你加入了这两个字段，还真对的起所有人。对方来拿数据的小伙伴，看见你都亲三分，利他就是利己吗，谁不愿意自己的程序拉数据，快快的呢。剩下时间，好摸鱼啊。这位同学想啥呢，摸鱼是指多学其他本事！可谁说，开两把黑，不是锻炼了手脚上的本事呢？！
这是最好理解的一个功能。比如对方要拿你某个表的数据，你总不希望他每次都是全量抽取吧，显然，一天天拿或者一小时一小时的抽，对你们的系统压力更小，对他们的数据写入，响应也更快。
性能要长远打算
有些事情，早就是优势。晚做比早做，成本更大。一张表，明知道会积累大量数据，那么一开始，就要把性能影响策略考虑周全。
比如，把600万的数据，全都放在一张裸表，显然不如加上几个常规索引的设计。
有数据存在的系统，基本都离不开时间这个维度。谈到优化性能时，尽最大努力减少数据范围，是一个策略。抽一年的数据，和抽一个月的数据，一个小时的数据，花费的成本显然是不同的。以时间作为限制条件，是最常规的优化方法。所以加上CreateDate,UpdateDate，并在上面加索引，可以明显的提高查询速度。
仅加索引的策略，当然也比不上做分区管理的设计。那么分区表，你知道有哪些方法吗，最简单的，莫过于按照时间刻度来划分。比如一年，或者一个自然月。分区相当于把表拆分成几个子表，数据范围进一步又缩小了。每个分区段，还可以互不干扰。优化又进一步！
解决万恶的bug
遇到不止一次，用户与用户，程序员与程序员，用户与程序员之间的互撕。为什么呢，肯定是信任问题咯。用户认为他的操作没问题，是程序问题；而程序员呢，我的程序肯定没问题，一定你操作失误，你再来一遍，我看着。
于是呢，Bug就产生了。程序员就要背锅了。喏，用户操作给你看了，数据是没了呢。
首先，数据库肯定不是一个人用的，那么在多人使用的情况下，谁做了什么操作，什么时间做的这个操作，最好都要记录下来。
为了这样的目的，最好还要设置CreateDate,UpdateDate这两个字段自动更新，以证明公平性。除此之外，还要设计CreateBy,UpdateBy,前者是数据生产者，后者是使用者。
这样，什么时间，谁谁谁做了操作，一目了然，没法撕了。
处理bug是高级活儿，这里面涉及到对整个系统，上千个存储过程或者class的处理逻辑，数十万行，甚至百万行代码的熟悉程度。所以，若不给数据一个时间戳，就像掉入了时空穿梭机一样，但手柄特么的忘带了，就只能靠菠萝菠萝蜜口诀（致敬星爷的大话西游）
好，1：30了，只能先扯到这里了。知道你们肯定有补充，下方尽情留言，不要客气！
--完--
往期精彩：
239
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
