放弃uuid(guid)的应用

数据库的治理是一个异常专业的工作，对数据库的调优、监控一般是由数据库工程师完成，然则开辟人员也经常与数据库打交道，即使是简单的增删改查也是有很多桥绫桥，这里，一路来聊聊数据库中很轻易忽视的问题。

字段长度省着点用

先说说我们常用的类型的存储长度：

不管是uuid，照样guid，应用的时刻都是为了避免同时生成反复的ID，然则建议推敲其他筹划，原因如下：

• uuid没有次序
• uuid太长
• uuid规矩完全弗成控

推荐的筹划用bigint(首选)，或者char来存储，生成方法参考snowflake的算法，有次序、长度固定、比uuid更短，当然，也几乎不会反复。

大年夜表削减联表，最好是单表萌芽

单表萌芽的优势很多，萌芽效力极高，便于分表分库扩大，然则很多时刻大年夜家都认为真正实现起来不太实际，完全掉去了关系数据库的意义，然则单表的机能优势太明显，一般总会有办法解决的:

• 合理的冗余字段
• 合营内存数据库(redis\mongodb)应用
• 联表变多次萌芽(下文会有解释)

如不雅推敲都后期数据量大年夜，须要分表分库，就应当尽早及时单表萌芽，如今的数据库分表分库的中心件根本都无法支撑联表萌芽。即使如mycat最多支撑两个表的联表萌芽，然则也有很明显的机能损耗。

索引的┞俘确处理方法

索引的优势这里就不多说了，索引应用欠妥会有反效不雅：

• 数据量很小的表，不须要索引
• 一个表的索引不宜过多，建议最多就5个，索引弗成能知足所有的场景，然则了个知足绝大年夜部分的场景
• mysql 和 sqlserver的索引差别还挺大年夜的，须要留意。例如：

mysql索引字段的次序对机能有很大年夜影响，sqlserver优化过，影响很小

多成就次比联表可能要好

提出这个筹划信赖会获得很多人的否决，然则我信赖这个结论照样异常合适数据量大年夜的场景。多成就次数据库有这么几个弊病：

• 增长了收集消费
• 增长了数据库的连接数

其实，这两个问题在如今根本都可以忽视的，数据库和应用的连接根本都是内网，这个收集连接的效力照样很高的。数据库对连接池的优化已经比较成熟了，连接数只要不是太多，影响也不会太严重，然则多成就次的优势却很多：

• 单表效力更高
• 便于后期扩大分表分库库
• 有效应用数据库本身的结不雅缓存
• 削减锁表，联表会锁多个表

当然，多成就次这个度必定要把握。切切不要在一个轮回琅绫擎萌芽数据库。我们也应当尽量削减萌芽数据库的次数。我们可以接收1次萌芽变2次萌芽，如不雅你变成10次萌芽，那就要放弃了。

举个例子：

萌芽商品的时刻，须要显示分类表的分类名

很明显，不合的类型存储的长度有很大年夜区其余，对萌芽的效力有影响，字段长度对索引的影响是很大年夜的。

• 字符串字段长度都差不多的，可以预估长度的，用char
• 字符串长度差别大年夜，用varchar,限制长度，不要浪费空间
• 整型根据大年夜小，选择合适的类型
• 时光建议用timestamp
• 建议应用decimal，不建议应用float,如不雅是价格，可以推敲用int或bigint，如1元，存储的就是100

select category.name,product.name from product inner join category on p.categoryid=category.id 

建议的方法：

很多用过 .net Entity Framework 的人都嗣魅这个框架太慢，其实慢主如果两点：缺点的使悠揭捉?迟加载(外键接洽关系)、生成SQL编译太慢。Entity Framework生成的SQL脚本有太多没用的器械，导致编译太慢。

select categoryid,name from product 
 
select categoryname from category where categoryid in ('','','','')  

当然，你可以再优化一下，萌芽分类名之前，对product的categoryid排序一下，如许速度更快。因为我们前面已经用snowflake生成了有次序的主键了。

弥补一下，in的效力并不是你想象的那么慢，如不雅保持在100个节点(很多书本介绍1000个节点，我们保守一点)，机能照样很高的。

　　推荐阅读

　　数字经济进入新时代：互联网是龙头，大数据、人工智能是亮点

国富平易近强离不开坚实的经济基本。党的十九大年夜申报提出，“推动互联网、大年夜数据、人工智能和实体经济深度融合”，培养新增长点、形成新动能;加快科技立异，扶植收集强国>>>详细阅读

本文标题：数据库的使用你可能忽略了这些

地址：http://www.17bianji.com/lsqh/38431.html

 1/2    1