房地产网站开发,计算机网络设计主要学什么,wordpress 密码加密方式,有单做平台app前言
最近回顾了下MySQL相关的知识#xff0c;比如索引、几大日志、事务、MVCC、SQL执行流程、Buffer Pool等等。理论知识看了一大堆#xff0c;自然还是需要实践的#xff0c;第一个反应就是数据库设计规范。项目开发中#xff0c;数据库设计自然是重要的一环#xff0c…前言
最近回顾了下MySQL相关的知识比如索引、几大日志、事务、MVCC、SQL执行流程、Buffer Pool等等。理论知识看了一大堆自然还是需要实践的第一个反应就是数据库设计规范。项目开发中数据库设计自然是重要的一环但是目前大多都忽略了成了一个不那么重要的环节但往往是设计阶段留下的坑开发阶段来填。没有统一的规范大多数开发人员都是按照之前的数据库设计进行惯性开发不犯错就是最大的正确。我搜了下相关文章发现还是有不少好文章说的很清楚让我一瞬间放下再写一篇文章的念头但是我发现这些文章普遍阅读量不高那就让我的这篇文章作为引子给大家学习数据库设计规范提供一个好的平台。
表设计
重点规范
【强制】表达是与否概念的字段必须使用 is_xxx 的方式命名数据类型是 unsigned tinyint 1 表示是0 表示否。 :::info 注意POJO 类中的任何布尔类型的变量都不要加 is 前缀所以需要在设置从 is_xxx 到 Xxx 的映射关系。数据库表示是与否的值使用 tinyint 类型坚持 is_xxx 的命名方式是为了明确其取值含 义与取值范围。 正例表达逻辑删除的字段名 is_deleted1 表示删除0 表示未删除。 补充切记建表字段长度不要选1不然mybatis-plus会自动转换成布尔值 ::: 【强制】表名、字段名必须使用小写字母或数字禁止出现数字开头禁止两个下划线中间只 出现数字。数据库字段名的修改代价很大因为无法进行预发布所以字段名称需要慎重考虑。 :::info 说明MySQL 在 Windows 下不区分大小写但在 Linux 下默认是区分大小写。因此数据库名、表名、 字段名都不允许出现任何大写字母避免节外生枝。 正例aliyun_adminrdc_configlevel3_name 反例AliyunAdminrdcConfiglevel_3_name ::: 【强制】表必备三字段id, create_time, update_time。 :::info 说明其中 id 必为主键类型为 bigint unsigned、单表时自增、步长为 1。create_time, update_time 的类型均为 datetime 类型前者现在时表示主动式创建后者过去分词表示被动式更新。 ::: 【推荐】字段允许适当冗余以提高查询性能但必须考虑数据一致。冗余字段应遵循 :::info 不是频繁修改的字段。 不是唯一索引的字段。 不是 varchar 超长字段更不能是 text 字段。 正例各业务线经常冗余存储商品名称避免查询时需要调用 IC 服务获取。 :::
规范汇总
表字段、索引名、表名等都要见名知意选择合适的字段类型—最基本的一步了不要省事让别人看不懂。字段类型根据业务来定允许范围内越精简越好主键推荐自增选择bigint即可自增主键性能很好非分库分表设计首选除了上面的固定三字段一般会有逻辑删除字段is_deleted创建人修改人。业务允许的情况下尽量别用null做默认值–坏处一大把问题是大家都懒得设置哈哈单表字段不宜过多做好冷热字段分离比如列表就属于热数据具体数据需要点进去详情页看这些字段就属于冷数据这两部分就可以分开建表用一个base_id关联时间字段推荐使用datetime范围大。timestamp就到2038年…
简要总结
我个人在设计表的时候是推荐尽量将表设计成独立的可以单表查询为此可以增加冗余字段表与表之间通过字段关联。凡是写了很冗长的SQL说明要么是业务实在是复杂要么就是当初表设计考虑不足或者压根是叠shi山来一坨垒一坨。上面的重要规范是摘抄的阿里开发手册的一些我觉得非常重要的部分全文我放在了好文推荐一栏值得大家一看。 MySQL本身不易扩展并且相对娇弱所以设计思路一定要把复杂的动作放在应用程序去处理避免MySQL做过重的逻辑操作做好存储和简单的查询即可尽量不要让MySQL成为性能瓶颈。应用程序可以从以下三个方面给MySQL减负
减少函数的使用例如数据转换之类的交由应用程序处理同时也避免了索引可能不生效的情况。外键肯定不能用了要增加冗余字段在应用程序侧去做主动关联例如主表和扩展表通过一个base_id字段去关联拆分大SQL应用程序来做数据关联应用侧缓存、多线程用上一般不会比MySQL慢
索引设计
重点规范
索引列建议 出现在 SELECT 、 UPDATE 、 DELETE 语句的 WHERE 从句中的列包含在 ORDER BY 、 GROUP BY 、 DISTINCT 中的字段多表 JOIN 的关联列
注意 并不要将符合 1 和 2 中的字段的列都建立一个索引通常将 1 、 2 中的字段建立联合索引效果更好
如何选择联合索引列的顺序 区分度最高的放在联合索引的最左侧区分度 列中不同值的数量 / 列的总行数尽量把字段长度小的列放在联合索引的最左侧因为字段长度越小一页能存储的数据量越大 IO 性能也就越好使用最频繁的列放到联合索引的左侧这样可较少的建立一些索引。
规范汇总
索引不要过多5个左右即可–索引也是数据并且增删改还会重建索引影响数据库处理速度优先建联合索引—覆盖索引、最左匹配多舒服注意区分度高的放在左边
简要总结
索引这个我之前写从零开始的SQL修炼手册那块已经说的很清楚了。对于查询的提升是非常大的特别是覆盖索引优化救星。 建索引相当于必修课吧对我们理解MySQL也是很有用的相关的索引结构、优化特性、设计思路都很有参考价值。上一篇大数据查询接口我在构想解法的时候第一时间就想到了类似索引这种目录检索的方法包括ES也是相似的解法。所以了解索引也是开阔我们的技术视野。
好文推荐
重点来了以下几篇文章写的都太好了理论这块还得多看看大佬们。还是老样子文章提供链接会配上我的读后感。 Java开发手册-嵩山版 阿里及社区一众大佬们合力写的规范包含很多维度的开发建议绝对是Java的必读手册。数据库是其中一部分写的很好建议都很中肯但是限于篇幅限制吧还是有很多地方没有涉及适合有一点数据库基础的读者们观看。所有建议均有正例反例绝了朋友们上车了本次列车是宝宝巴士。 MySQL数据库设计开发规范汇总篇 这一篇属实太全了本来我想写个汇总结果一看这篇直接给我干碎面面俱到给我整不会了。初学者一定要看绝对是养成好习惯的基石配合上面阿里小册观感更佳。 archer-MySQL数据库设计规范 推荐这个主要是连带着这个GitHub项目比较有意思规范写的还不错。项目几年不维护了不过是开源项目我没用过不过看着挺有意思。
