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

数据库的管理是一个很是专业的事情，对数据库的调优、监控通常是由数据库工程师完成，可是开发人员也常常与数据库打交道，即便是简单的增删改查也是有不少窍门，这里，一块儿来聊聊数据库中很容易忽略的问题。

字段长度省着点用

先说说咱们经常使用的类型的存储长度：

列类型	存储长度
tinyint	1字节
smallint	2字节
int	4字节
bigint	8字节
float	4字节
decimal(m,d)	0-4字节
datetime	8字节
timestamp	4字节
char(m)	m个字节
varchar(m)	可变长度
text	可变长度

很明显，不一样的类型存储的长度有很大区别的，对查询的效率有影响，字段长度对索引的影响是很大的。

• 字符串字段长度都差很少的，能够预估长度的，用char
• 字符串长度差别大，用varchar,限制长度，不要浪费空间
• 整型根据大小，选择合适的类型
• 时间建议用timestamp
• 建议使用decimal，不建议使用float,若是是价格，能够考虑用int或bigint，如1元，存储的就是100

放弃uuid(guid)的使用

不论是uuid，仍是guid，使用的时候都是为了不同时生成重复的ID，可是建议考虑其余方案，缘由以下：

• uuid没有顺序
• uuid太长
• uuid规则彻底不可控

推荐的方案用bigint（首选），或者char来存储，生成方式参考snowflake的算法，有顺序、长度固定、比uuid更短，固然，也几乎不会重复。

大表减小联表，最好是单表查询

单表查询的优点不少，查询效率极高，便于分表分库扩展，可是不少时候你们都以为真正实现起来不太现实，彻底失去了关系数据库的意义，可是单表的性能优点太明显，通常总会有办法解决的:

• 合理的冗余字段
• 配合内存数据库（redis\mongodb）使用
• 联表变屡次查询（下文会有说明）

若是考虑都后期数据量大，须要分表分库，就应该尽早实时单表查询，如今的数据库分表分库的中间件基本都没法支持联表查询。即便如mycat最多支持两个表的联表查询，可是也有很明显的性能损耗。

索引的正确处理方式

索引的优点这里就很少说了，索引使用不当会有反效果：

• 数据量很小的表，不须要索引
• 一个表的索引不宜过多，建议最多就5个，索引不可能知足全部的场景，可是了个知足绝大部分的场景
• mysql 和 sqlserver的索引差异还挺大的，须要注意。例如：
  mysql索引字段的顺序对性能有很大影响，sqlserver优化过，影响很小

多查几回比联表可能要好

提出这个方案相信会获得不少人的反对，可是我相信这个结论仍是很是适合数据量大的场景。多查几回数据库有这么几个弊端：

• 增长了网络消耗
• 增长了数据库的链接数

其实，这两个问题在如今基本均可以忽略的，数据库和应用的链接基本都是内网，这个网络链接的效率仍是很高的。数据库对链接池的优化已经比较成熟了，链接数只要不是太多，影响也不会太严重，可是多查几回的优点却不少：

• 单表效率更高
• 便于后期扩展分表分库库
• 有效利用数据库自己的结果缓存
• 减小锁表，联表会锁多个表

固然，多查几回这个度必定要把握。千万不要在一个循环里面查询数据库。咱们也应该尽可能减小查询数据库的次数。咱们能够接受1次查询变2次查询，若是你变成10次查询，那就要放弃了。
举个例子：
查询商品的时候，须要显示分类表的分类名

select category.name,product.name from product  inner join category on p.categoryid=category.id复制代码

建议的方式：

select categoryid,name  from product 
select categoryname from category where categoryid in ('','','','')复制代码

固然，你能够再优化一下，查询分类名以前，对product的categoryid排序一下，这样速度更快。由于咱们前面已经用snowflake生成了有顺序的主键了。
补充一下，in的效率并非你想象的那么慢，若是保持在100个节点（不少书籍介绍1000个节点，咱们保守一点），性能仍是很高的。

尽可能使用简单的数据库脚本

不少用过 .net Entity Framework 的人都说这个框架太慢，其实慢主要是两点：错误的使用延迟加载（外键关联）、生成SQL编译太慢。Entity Framework生成的SQL脚本有太多没用的东西，致使编译太慢。
数据库脚本尽可能使用简单的，不要用太长的一个SQL脚本，会致使初次执行的时候，编译SQL脚本花费太多的时间。

尽可能去避免聚合操做

聚合操做如count,group等，是数据库性能的大杀手，常常会出现大面积的表扫描和索表的状况，因此你们能看到不少平台都把数量的计算给隐藏了，商品查询不去实时显示count的结果。如淘宝，就不显示查询结果的数量，只是显示前100页。
避免聚合操做的方法就是将实时的count计算结果用字段去存储，去累加这个结果。固然，也能够考虑用spark等实时计算框架去处理，这种高深的技术，不在这次讨论范围内。（PS:主要是我也不懂）

总结

程序的优化不少时候都是一些细节的问题，更应该注意平时的积累，阿里SQL的规范有不少能够吸收的地方，以上也是本身工做中的一些总结。
（完）

---

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