MySQL 使用规范总结

1.必须使用InnoDB存储引擎

有更好的CPU和IO性能,更好的备份和锁表机制,提高统计和调试效率。

另外,作为一 个系统,InnoDB支持多种关键功能,其中最重要的是事务日志和行级锁。事务日志记录真正的数据库事务,但更重要的是数据崩溃恢复和回滚。

基于 InooDB方式的IO,能给予更安全数据保护和更好性能表现。另外,在大多数的情况下,行级锁可以提供更高的并发性能,因为用户只锁定他们正在写的数据,而读数据永远不会被阻塞 。

2.数据表、数据字段必须加入中文注释

方便日后新人小哥,更快理解熟悉;并且可读性更好。同时在status这类字段上标注:0表示删除,1表示正常 等枚举值。

3.必须使用UTF8mb4字符集

utf8是通用的字符集,mb4 在utf8上进行了扩展,支持emoj等新的字符。

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

高并发大数据的互联网业务,架构设计思路是“解放数据库CPU,将计算转移到服务层”,数据库擅长存储与索引,CPU计算在业务层更合理。

5.禁止存储大文件或者大照片

当人员照片较多时,分页查询速度明显变慢,之前1秒内响应,加了照片字段后,需要4~5秒左右才能响应。
大文件和照片存储在文件系统,数据库里存URI更好

6.表必须有主键,例如自增主键

a)主键递增,数据行写入可以提高插入性能,可以避免Page分裂,减少表碎片提升空间和内存的使用。
b)使用数字类型主键,较短的数据类型可以有效的减少索引的磁盘空间,提高索引的缓存效率。
c)无主键的表删除,在ROW模式的主从架构,会导致备库夯住。
d) 更多使用业务主键,在分库分表会有更多便利性。

7.禁止使用外键,如果有外键完整性约束,需要应用程序控制

外键会导致表与表之间耦合,Update与Delete操作都会涉及相关联的表,十分影响SQL的性能,甚至会造成死锁。

8.必须把字段定义为NOT NULL并且提供默认值

a)null的列使索引/索引统计/值比较都更加复杂,对MySQL来说更难优化。
b)null 这种类型MySQL内部需要进行特殊处理,增加数据库处理记录的复杂性;同等条件下,表中有较多空字段的时候,数据库的处理性能会降低很多。
c)null值需要更多的存储空,无论是表还是索引中每行中的null的列都需要额外的空间来标识。
d)对null 的处理时候,只能采用is null或is not null,而不能采用=、in、<、<>、!=、not in这些操作符号。

如:where name!='nx',如果存在name为null值的记录,查询结果就不会包含name为null值的记录。

9.禁止使用TEXT、BLOB类型

会浪费更多的磁盘和内存空间,非必要的大量的大字段查询会淘汰掉热数据,导致内存命中率急剧降低,影响数据库性能。

10.禁止使用小数存储货币

使用整数吧,小数容易导致钱对不上。

11.必须使用varchar(20)存储手机号

a)涉及到区号或者国家代号,可能出现+-()
b)手机号会去做数学运算么?
c)varchar可以支持模糊查询,例如:like“138%”

12.禁止使用ENUM,可使用TINYINT代替

a)增加新的ENUM值要做DDL操作
b)ENUM的内部实际存储就是整数,你以为自己定义的是字符串?

13.关于索引设计

(1)单表索引建议控制在5个以内

索引并不是越多越好!索引可以提高效率同样可以降低效率。

索引可以增加查询效率,但同样也会降低插入和更新的效率,甚至有些情况下会降低查询效率。

因为MySQL优化器在选择如何优化查询时,会根据统一信息,对每一个可以用到的索引来进行评估,以生成出一个最好的执行计划,如果同时有很多个索引都可以用于查询,就会增加MySQL优化器生成执行计划的时间,同样会降低查询性能。

(2)禁止在更新十分频繁、区分度不高的属性上建立索引

a)更新会变更B+树,更新频繁的字段建立索引会大大降低数据库性能
b)“性别”这种区分度不大的属性,建立索引是没有什么意义的,不能有效过滤数据,性能与全表扫描类似

(3)建立组合索引,必须把区分度高的字段放在前面

理由:能够更加有效的过滤数据

14.关于SQL使用规范

(1)禁止使用INSERT INTO t_xxx VALUES(xxx),必须显示指定插入的列属性

理由:容易在增加或者删除字段后出现程序BUG

(2)禁止在WHERE条件的属性上使用函数或者表达式

理由:SELECT uid FROM t_user WHERE from_unixtime(day)>='2019-10-09' 会导致全表扫描
正确的写法是:SELECT uid FROM t_user WHERE day>= unix_timestamp('2019-10-09 00:00:00')

(3)禁止负向查询,以及%开头的模糊查询

理由:
a)负向查询条件:NOT、!=、<>、!<、!>、NOT IN、NOT LIKE等,会导致全表扫描
b)%开头的模糊查询,会导致全表扫描

(4)禁止大表使用JOIN查询,禁止大表使用子查询

理由:会产生临时表,消耗较多内存与CPU,极大影响数据库性能

(5)禁止使用OR条件,必须改为IN查询

理由:旧版本Mysql的OR查询是不能命中索引的,即使能命中索引,为何要让数据库耗费更多的CPU帮助实施查询优化呢?

(6)应用程序必须捕获SQL异常,并有相应处理

以上就是MySQL 使用规范总结的详细内容,更多关于MySQL 使用规范的资料请关注我们其它相关文章!

(0)

相关推荐

  • MySQL开发规范与使用技巧总结

    1.命名规范 1.库名.表名.字段名必须使用小写字母,并采用下划线分割. a)MySQL有配置参数lower_case_table_names,不可动态更改,linux系统默认为 0,即库表名以实际情况存储,大小写敏感.如果是1,以小写存储,大小写不敏感.如果是2,以实际情况存储,但以小写比较. b)如果大小写混合使用,可能存在abc,Abc,ABC等多个表共存,容易导致混乱. c)字段名显示区分大小写,但实际使⽤用不区分,即不可以建立两个名字一样但大小写不一样的字段. d)为了统一规范, 库名

  • 超详细MySQL使用规范分享

    最近涉及数据库相关操作较多,公司现有规范也不是太全面,就根据网上各路大神的相关规范,整理了一些自用的规范用法,万望指正. 数据库环境 dev: 开发环境 开发可读写,可修改表结构.开发人员可以修改表结构,可以随意修改其中的数据但是需要保证不影响其他开发同事. test: 测试环境 开发可读写,开发人员可以通过工具修改表结构. online: 线上环境 开发人员不允许直接在线上环境进行数据库操作,如果需要操作必须找DBA进行操作并进行相应记录,禁止进行压力测试. 重点的问题,各个环境的mysql服

  • MYSQL 数据库命名与设计规范

    1.设计原则 1) 标准化和规范化 数据的标准化有助于消除数据库中的数据冗余.标准化有好几种形式,但Third Normal Form(3NF)通常被认为在性能.扩展性和数据完整性方面达到了最好平衡.简单来说,遵守3NF 标准的数据库的表设计原则是:"One Fact in One Place"即某个表只包括其本身基本的属性,当不是它们本身所具有的属性时需进行分解.表之间的关系通过外键相连接.它具有以下特点:有一组表专门存放通过键连接起来的关联数据. 举例:某个存放客户及其有关定单的3

  • mysql数据库开发规范【推荐】

    最近一段时间一边在线上抓取SQL来优化,一边在整理这个开发规范,尽量减少新的问题SQL进入生产库.今天也是对公司的开发做了一次培训,PPT就不放上来了,里面有十来个生产SQL的案例.因为规范大部分还是具有通用性,所以也借鉴了像去哪儿和赶集的规范,但实际在撰写本文的过程中,每一条规范的背后无不是在工作中有参照的反面例子的.如果时间可以的话,会抽出一部分或分析其原理,或用案例证明. 一. 命名规范 1.库名.表名.字段名必须使用小写字母,并采用下划线分割 (1)MySQL有配置参数lower_cas

  • MySQL数据库命名规范及约定

    一.[操作规范]1. 如无备注,则表中的第一个id字段一定是主键且为自动增长:2. 如无备注,则数值类型的字段请使用UNSIGNED属性:3. 如无备注,排序字段order_id在程序中默认使用降序排列:4. 如无备注,所有字段都设置NOT NULL,并设置默认值:5. 如无备注,所有的布尔值字段,如is_hot.is_deleted,都必须设置一个默认值,并设为0:6. 所有的数字类型字段,都必须设置一个默认值,并设为0:7. 针对varchar类型字段的程序处理,请验证用户输入,不要超出其预

  • Mysql建表与索引使用规范详解

    一. MySQL建表,字段需设置为非空,需设置字段默认值.二. MySQL建表,字段需NULL时,需设置字段默认值,默认值不为NULL.三. MySQL建表,如果字段等价于外键,应在该字段加索引.四. MySQL建表,不同表之间的相同属性值的字段,列类型,类型长度,是否非空,是否默认值,需保持一致,否则无法正确使用索引进行关联对比.五. MySQL使用时,一条SQL语句只能使用一个表的一个索引.所有的字段类型都可以索引,多列索引的属性最多15个.六. 如果可以在多个索引中进行选择,MySQL通常

  • 老鸟带你开发专业规范的MySQL启动脚本

    每一个合格的Linux运维人员都应该做到熟练或精通Shell脚本编程,因为Shell脚本语言差不多是所有编程语言里最简单的语言,如果Shell脚本不行,意味着运维之路可能还没开始就将要终结.--老男孩老师 #!/bin/bash # chkconfig: 2345 64 36 #配置系统自启动 # description: A very fast and reliable SQL database engine. #########################################

  • MySQL数据库使用规范总结

    导读: 关于MySQL数据库规范,相信大家多少看过一些文档.本篇文章给大家详细分类总结了数据库相关规范,从库表命名设计规范讲起,到索引设计规范,后面又给出SQL编写方面的建议.相信这些规范适用于大多数公司,也希望大家都能按照规范来使用我们的数据库,这样我们的数据库才能发挥出更高的性能. 关于库: 1.[强制]库的名称必须控制在32个字符以内,英文一律小写. 2.[强制]库的名称格式:业务系统名称_子系统名. 3.[强制]库名只能使用英文字母,数字,下划线,并以英文字母开头. 4.[强制]创建数据

  • MySQL 使用规范总结

    1.必须使用InnoDB存储引擎 有更好的CPU和IO性能,更好的备份和锁表机制,提高统计和调试效率. 另外,作为一 个系统,InnoDB支持多种关键功能,其中最重要的是事务日志和行级锁.事务日志记录真正的数据库事务,但更重要的是数据崩溃恢复和回滚. 基于 InooDB方式的IO,能给予更安全数据保护和更好性能表现.另外,在大多数的情况下,行级锁可以提供更高的并发性能,因为用户只锁定他们正在写的数据,而读数据永远不会被阻塞 . 2.数据表.数据字段必须加入中文注释 方便日后新人小哥,更快理解熟悉

  • MySQL学习第四天 Windows 64位系统下使用MySQL

    一.启动/关闭MySQL         (1)启动MySQL服务:net start mysql  (2)停止MySQL服务: net stop mysql 二.登录/退出MySQL 首先我们先来看看一些重要的mysql参数,下面表中列出了一些重要的mysql参数: (1)查看版本号:输入mysql -V或mysql --version,注意这里的-V是大写.  (2)登录MySQL mysql后面要加参数才行.格式是:mysql  -u root (用户)  -p -P 端口号  -h  m

  • MySQL中主键与rowid的使用陷阱总结

    前言 大家在MySQL中我们可能听到过rowid的概念,但是却很难去测试实践,不可避免会有一些疑惑,比如: 如何感受到rowid的存在: rowid和主键有什么关联关系: 在主键的使用中存在哪些隐患: 如何来理解rowid的潜在瓶颈并调试验证. 本文要和大家一起讨论这几个问题,测试的环境基于MySQL 5.7.19版本. 问题1.如何感受到rowid的存在 我们不妨通过一个案例来进行说明. 记得有一天统计备份数据的时候,写了一条SQL,当看到执行结果时才发现SQL语句没有写完整,在完成统计工作之

  • MySQL数据库入门之多实例配置方法详解

    本文实例讲述了MySQL数据库入门之多实例配置方法.分享给大家供大家参考,具体如下: 前面介绍了相关的基础命令操作:MySQL数据库基础篇之入门基础命令 所有的操作都是基于单实例的,mysql多实例在实际生产环境也是非常实用的,因为必须要掌握. 1.什么是多实例 多实例就是一台服务器上开启多个不同的服务端口(默认3306),运行多个mysql的服务进程,这此服务进程通过不同的socket监听不同的服务端口来提供各在的服务,所有实例之间共同使用一套MYSQL的安装程序,但各自使用不同的配置文件.启

  • MySQL数据库设计概念及多表查询和事物操作

    目录 数据库设计概念 数据库设计简介 表关系(多对多) 表关系(一对多) 表关系之一对一 多表查询 笛卡尔积现象 内连接查询 嵌套查询(子查询) 事务操作 事务的概念 手动提交事务 自动提交事务 事务原理和四大特征 事务原理 事务的四大特征 事务的并发访问引发的三个问题(面试) 事务的隔离级别 数据库设计概念 数据库设计简介 1.数据库设计概念 数据库设计就是根据业务系统具体需求,结合我们所选用的DBMS,为这个业务系统构造出最优的数据存储模型. 建立数据库中的表结构以及表与表之间的关联关系的过

  • Go实现分布式唯一ID的生成之雪花算法

    目录 背景: 特性: 雪花算法: 分布式唯一ID的生成 背景: 在分布式架构下,唯一序列号生成是我们在设计一个尤其是数据库使用分库分表的时候会常见的一个问题 特性: 全局唯一,这是基本要求,不能出现重复数字类型,趋势递增,后面的ID必须比前面的大长度短,能够提高查询效率,这也是从MySQL数据库规范出发的,尤其是ID作为主键时**信息安全,**如果ID连续生成,势必会泄露业务信息,所以需要无规则不规则高可用低延时,ID生成快,能够扛住高并发,延时足够低不至于成为业务瓶颈. 雪花算法: ​ sno

随机推荐