Mysql从会用到用好

哈喽！今天心血来潮给大家带来了《Mysql从会用到用好》，想必大家应该对数据库都不陌生吧，那么阅读本文就都不会很困难，以下内容主要涉及到MySQL、Java、后端，若是你正在学习数据库，千万别错过这篇文章~希望能帮助到你！

Mysql可以说是每个后端研发混饭吃的必备技能，我写了10年代码，但是发现大部分同学只是会用，能写写增删改查的业务逻辑，真能用好的寥寥无几~
废话少说，直接上干货！

一、建表时用自增id作为主键（实用指数：5星，装逼指数：1星）

这其实是一条Mysql开发的军规，经常有好事之徒会来挑战。
先说结论
对于绝大部分业务系统（追求极致效率或者接入了统一id生成器例外），采用int或bigint自增id作为主键是最好的选择，建表的时候无脑加就行了
再说原理

• 自增id是顺序增加，插入效率明显高于随机插入，且索引空间利用率更高
• int只占4字节，bigint占8字节，并且所有普通索引的叶子节点都是存的主键，因此相比绝大部分其它字段（身份证号、uuid等等），索引存储空间节约不少
• 大公司很多时候会有专门团队进行数据备份、提取、增量同步等操作，统一的自增id作为表主键，会给他们的工作带来极大的方便

二、建表时必备5字段（实用指数：5星，装逼指数：1星）

对于普通业务系统，建表时一般都会加入creator、create_time、operator、update_time、status这五个字段。不要怕浪费存储空间，等你哭着喊着认同这条内容的时候，可能已经被坑出xiang了，因为它们真正的名字叫：

• creator（始作俑者）
• create_time（多年以前）
• operator（背锅人，就是他乱改这条数据的！）
• update_time（线上事故发生的时间）
• status（幸好只是逻辑删除，还能恢复）

三、where后条件必用索引字段（实用指数：5星，装逼指数：1星）

这条没啥可说的，严格执行就好了。虽然建表的时候数据不多，加不加索引影响不大，甚至写个“where 1”的语句也察觉不出来。但是等数据多的时候你肯定也忘了当年没加索引，唤醒你记忆的通常是一场线上事故。

四、like尽量只支持右模糊（实用星级：4星，装逼指数：3星）

技术原理
模糊查询想必程序员都不陌生，只支持右模糊原理也很简单，因为采用左右两边模糊会造成索引失效全表遍历。轻则引发慢查询，连接数上升；重则线上事故，追悔莫及。
产品思维
真能做好这一条的同学考验你的并不是技术能力，而是产品能力，如何说服产品经理接受你的建议只支持右模糊。你得考虑在这个场景下真的需要双向模糊吗？特别是ToB的产品，通常都是精确匹配，并不需要模糊一大堆结果出来。
技术选型
当然有很多场景特别是C端产品确实需要模糊查询的功能，如果数据量很大我们是不是该考虑采用Elasticsearch或者其它方案，而不是两边加引号。

五、加事务请谨慎，再谨慎（实用星级：4星，装逼指数：5星）

这是一条5星装逼建议，当然实用性也非常非常高，因为能做好的人实在是太少了，通常都是测试环境或者线上出了问题以后，才能排查出来。

讲一个真实案例，我们有个系统需要定时执行批量计算任务，流程是先查数据，然后修改任务表的状态，计算结果，最后把结果插入几张结果表。为了保证事务性，不会因为某一张表插入失败导致数据不一致，研发小哥直接在代码里面给上述整个流程加了个事务。结果就是上线以后，慢SQL数量暴增，连接数暴增，数据库跪了，然后回滚代码，写事故报告。

细想一下，这个流程真的需要加事务吗？对于插数据失败这种极小概率的问题，我们是否可以把任务状态置为失败，或者启个定时任务扫描超时未完成的任务，然后重新执行一次就可以了。从业务流程上去保证事务性，而不是代码上加个大事务。
当你平静的给小弟们讲完这个道理，然后转身继续撸代码的时候，这个逼装得满分！

今天写得有点晚了，明天继续讲述心路历程（血泪史）

今天关于《Mysql从会用到用好》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于mysql的内容请关注golang学习网公众号！