天天看点

dz论坛mysql 占用cpu_细说mysql数据库实战规范前言命名规范基础设计规范字段设计规范索引设计规范SQL开发规范总结

dz论坛mysql 占用cpu_细说mysql数据库实战规范前言命名规范基础设计规范字段设计规范索引设计规范SQL开发规范总结

前言

我们小伙伴们经常使用到mysql数据库,一般就这么一用,很少会考虑mysql里面的细节问题,如sql语句的规范,或索引有没有起到相应的效果,今天老顾就给大家介绍一下mysql实战

命名规范

1、所有数据库对象都要小写字母、并用下划线分割

2、所有数据库对象*不要用mysql关键字命名

3、库表的命名要达到看到此名称,就大概知道是干嘛的

4、临时库表要以tmp_为前缀,日期为后缀

5、备份库表要以bak_为前缀,日期为后缀

6、相同的数据,在所有表中的列名和类型要一致

基础设计规范

1、在新建表时,要使用InnoDB引擎

因为InnoDB支持事务、行锁、性能更好

2、新库使用utf8mb4字符集

兼容更好,可以避免产生乱码,防止索引创建失败

3、表和字段必须加入中文注释

方便以后的系统维护

4、禁止使用存储过程、视图、触发器、Event

能够不占用数据库的资源,就不要占用;让这些计算上移到服务层。将来的进行数据拆分方便,存储过程等是针对单实例的,无法适用分库分表的架构

5、单表数据量,控制在500万以内

当然mysql可以存储1000万数据,但过大后会影响mysql 的性能以及维护工作。想要存储更多的数据,可以对数据进行拆分,分库分表设计来控制单表数据量

6、谨慎利用Mysql分区功能

在分区表中物理上面是多个文件,但逻辑上是一个文件,灵活度不够,而且跨分区查询效率低;还是建议使用物理分区,市面上也有一些中间件mycat、sharding-jdbc等

7、减少表的宽度、冷热数据分离、必须有主键

a、mysql表的列数限制可以为4096列,每一行的数据大小不能超过65535字节;宽度越大,加载在内存中占用内存就越大,IO消耗越大。表的宽度建议在30左右, b、要把经常用的数据列放在一起,这样可以一次性读取出来;把经常用不到的数据分离出去,这样极大提高效率 c、主键的好处,就是更好的利用索引,提高查询效率。不明白原理,可以看老顾之前的文章

8、禁止使用外键,交给程序控制

这个是不是和我们理解的不一样,为什么不要外键?外键会导致表与表之间耦合,这样更新操作都会涉及到相关联的表,十分影响sql的性能,且容易造成死锁。

9、禁止使用预留字段

很多小伙伴为了以后的业务扩展,都喜欢在表中建立类似DEMO1、DEMO2字段,列名没有任何业务含义,而且类型都是用String代替。预留字段另一个好处就是业务改变后,利用预留字段,SQL语句不需要改变,其实这个问题用一些ORM工具就能够很好的解决

字段设计规范

1、优先选择符合业务的最小存储类型

可以有效节省数据库的空间,查询的时候也能够减少IO消耗

2、字段定义为Not Null,且提供默认值

null值的列,很难对索引优化;null的列对占用更多的空间,因为需要额外的空间来标识。null的查询操作,也过于麻烦,只能采用is null或is not null,而不能采用=、in、、not in 、!=操作符,如:where name!='laogu',是不会查询出name为null的值的。

3、禁止使用Text、BLOB类型

Mysql内存临时表不支持Text、Blob类型,如果查询中包含这些类型,就不能使用内存临时表,而会采用磁盘临时表,导致性能很差会浪费更多的磁盘和内存空间,导致数据库内存命中率低,影响数据库性能 如果一定要使用,建立单独的扩展表

4、禁止使用ENUM、可用Tinyint代替

修改Enum值时,需要使用alter语句 order by操作效率低

5、禁止使用小数

直接使用整数,小数容易有精度差异,导致金额对不上

6、使用Timestamp或Datetime类型存储时间

经常小伙伴们用String类型储存时间缺点1:无法用日期函数进行计算比较缺点2:用户字符串存储,占用更多的空间

索引设计规范

1、每张表索引不要超过5个一般常识索引可以增加查询效率,但同样降低了插入和更新的效率。

但针对查询,索引也不是越多越好。因为mysql优化器在选择如何优化查询时,会根据查询信息,对每一个用到的索引进行评估,以生成一个最好的执行计划,如果有很多个索引,就会增加mysql优化器的执行时间,反而降低了查询性能

2、区分度不高、更新频繁的列 不建议加索引

更新频繁会变更B+树,大大降低数据库的性能。区分度(区分度=列中不同值的数量/列的总行数),区分度不高(如:性别,只有男、女、未知)建立索引没有意义,性能和全表扫描差不多

3、联合索引时,把区分度高的放到最左侧因为mysql的索引结构原理,联合索引有一个原则,就是最左索引原则。

a、尽量把区分度高的放在联合索引的最左侧 b、把查询频繁的列放在最左侧 c、把字段长度小的放到最左侧,这样内存页存储数据量越大,IO性能越好

SQL开发规范

1、禁止使用select 要用select 列名 代替 select 

原因:1、消耗更多的CPU、IO开销 2、无法使用覆盖索引 3、可减少表结构的改动,带来的代码影响

2、禁止使用属性隐式转换

隐式转换会导致索引失效,如:select name from customer where id='1000';id为整型,正确的写法select name from customer where id=1000

3、建议使用预编译语句进行数据库操作

预编译语句可以重复使用优化计划,减少SQL编译时间,避免SQL注入

4、禁止使用不含字段的insert语句

如:insert into txxxx values(xxx,xxx,xxx) 应使用insert into txxx(c1,c2,c3) values(xxx,xxx,xxxx)防止表结构变化

5、禁止负向查询,以及%开头的模糊查询

负向查询为:not、!=、<>、not in、not like等,会导致全表扫描 %开头也会导致全表扫描

6、一个SQL只能利用复合索引中的一列进行范围查询

如:有c1、c2、c3三个列建立联合索引,在查询条件中有c1列的范围查询,则在c2、c3列上的索引将不会被用到。如果一定要用c1做范围查询,那把c1列放到联合索引的最右侧

7、禁止在where条件上对属性使用函数或表达式

如:select id from torder where fromunixtime(createtime) >= '20190101' 应改为 select id from torder where createtime >= unixtimestamp('20190720')

8、禁止大表使用join查询,禁止大表使用子查询

会产生临时表,消耗较多的内存、cpu资源,影响性能

9、避免使用JOIN关联太多的表

对于Mysql来说,是有关联缓存的,缓存的大小是由joinbuffersize参数进行设置。对于同一个SQL多关联一个表,就会多分配一个关联缓存,越多的join,就消耗越多的内存。如果joinbuffersize设置不合理,就会导致数据库内存溢出,影响性能和稳定性

10、禁止使用OR条件,必须改为IN查询

绝大多数情况下,Mysql的OR查询是不能命中索引的

11、尽量减少与数据库的交互次数

能够一次性读取尽可能多的数据,减少和数据库的交互,可以极大提升数据库的吞吐量

12、禁止使用order by rand()进行排序

会把表中的所有数据都加到内存中,然后在对内存的数据进行随机排序,会消耗较多的CPU、IO以及内存资源 推荐在程序中生成一个随机值,传给数据库的方式

总结

上面有很多规范,也许小伙伴一时间记不住,慢慢练习就会越熟练。老顾这里给大家分享一个索引口诀,方便记忆

索引优化口诀全值匹配我最爱,最左前缀要遵守;带头大哥不能死,中间兄弟不能断;索引列上少计算,范围之后全失效;Like百分写最右,覆盖索引不写星;不等空值还有or,索引失效要少用;VAR引号不可丢,SQL高级也不难!

如果不能够理解,可以私信老顾哦!谢谢!!!

后台回复【4】加入享学课堂粉丝交流群,相亲交友,技术交流

推荐阅读:

基于RocketMq的分布式事务解决方案

快速鸟瞰并发编程, 呕心沥血整理的架构技术【3】

快速鸟瞰并发编程, 呕心沥血整理的架构技术【2】

今日课题:

dz论坛mysql 占用cpu_细说mysql数据库实战规范前言命名规范基础设计规范字段设计规范索引设计规范SQL开发规范总结

↑点击图片直接跳转观看免费直播课程↑

dz论坛mysql 占用cpu_细说mysql数据库实战规范前言命名规范基础设计规范字段设计规范索引设计规范SQL开发规范总结

继续阅读