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

数据库的管理是一个非常专业的事情,对数据库的调优、监控一般是由数据库工程师完成,但是开发人员也经常与数据库打交道,即使是简单的增删改查也是有很多窍门,这里,一起来聊聊数据库中很容易忽略的问题。

字段长度省着点用

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

列类型

存储长度

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的规范有很多可以吸取的地方,以上也是自己工作中的一些总结。 (完)


原文发布于微信公众号 - IT米粉(itmifen)

原文发表时间:2017-11-01

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏醒者呆

EOS技术研究:合约与数据库交互

2585
来自专栏阿杜的世界

JVM源码分析之perfData文件的创建

看泉子的一篇文章:JVM源码分析之Jstat工具原理完全解读 - 你假笨 里提到了两个JVM参数,可以控制perfdata文件是否共享,引用泉子对这两个参数的解...

1631
来自专栏Python中文社区

使用Python分析nginx日志

使用Python分析nginx日志 专栏作者:熊球 ♚土木工程毕业,现从事web后端开发方面的工作,擅长python,flask框架等。 博客:codechat...

27510
来自专栏.NET开发者社区

什么是ORM?为什么用ORM?浅析ORM的使用及利弊

什么是ORM ORM(Object-relational mapping),中文翻译为对象关系映射,是一种为了解决面向对象与关系数据库存在的互不匹配的现象的技术...

20110
来自专栏小樱的经验随笔

CTF---Web入门第十二题 程序逻辑问题

程序逻辑问题分值:20 来源: 实验吧 难度:中 参与人数:6909人 Get Flag:1993人 答题人数:2070人 解题通过率:96% 绕过 解题链接:...

3446
来自专栏吉浦迅科技

DAY70:阅读API Reference

我们正带领大家开始阅读英文的《CUDA C Programming Guide》,今天是第70天,我们正在讲解CUDA 动态并行,希望在接下来的30天里,您可以...

1894
来自专栏风火数据

hadoop大数据面试题

以下资料来源于互联网,很多都是面试者们去面试的时候遇到的问题,我对其中有的问题做了稍许的修改了回答了部分空白的问题,其中里面有些考题出的的确不是很好,但是也不乏...

2672
来自专栏电光石火

PHP中HTTP防盗链技术

 盗链是指服务提供商自己不提供服务的内容,通过技术手段绕过其它有利益的最终用户界面(如广告),直接在自己的网站上向最终用户提供其它服务提供商的服务内容,骗取...

2745
来自专栏程序员八阿哥

王老板Python面试(2): 常见的Python爬虫面试题,让你轻松拿offer!

有些自学爬虫(python)的同学因为没有经历过专业面试,所以在找工作之前难免有些抓不住重点。即便掌握技术熟练,却因为发挥不好而错失工作机会。今天就和大家分享几...

1191
来自专栏张狗蛋的技术之路

数据库内部存储结构探索

 本文是左耳耗子推荐的Medium上的一篇关于MySQL的文章Some study on database storage internals,本人觉得文章十分...

2662

扫码关注云+社区