mysql数据库架构设计与优化

数据库设计规范

  • 数据库设计规范
    • 1. 数据库命名规范
    • 2. 数据库基本设计规范
    • 3. 数据库索引设计规范
    • 4. 数据库字段设计规范
    • 5. sql开发规范
    • 6. 数据库操作规范
  • 其他

以上所有规范并非完全不能违背,只是如果不符时,要和公司dba团队确认是否可以做相关操作

数据库设计规范

1. 数据库命名规范

  • 所有数据库对象名称必须使用小写字母并用下划线分隔
    mysql是大小写敏感的,sql除外。不同的数据库名:Dbname、dbname;不同的表名:Table、table
  • 所有数据库对象名称,禁止使用mysql保留关键字
    比如以下,查询的列表中有from关键字,必须用反单引号转义才行,否则会报错!
    select id,username,`from`,age from tb_user;
    常见的mysql关键字
  • 数据库对象的命名要能做到见名知意,并且最好不要超过32个字符
    例如:用户账号表 user_account
  • 临时库表必须以tmp为前缀,并以日期为后缀
  • 备份库,备份表必须以bak为前缀并以日期为后缀
  • 所有存储相同数据的列明和列类型必须一致
    mysql数据库架构设计与优化_第1张图片
    比如以上和以下的两个表中:customer_id列明,和列类型完全一致
    mysql数据库架构设计与优化_第2张图片

2. 数据库基本设计规范

  • 所有表没有特殊情况必须使用Innodb引擎
    5.6以后的默认存储引擎
    支持事务,行级锁,更好的恢复性,高并发下性能更好
  • 数据库和表的字符集统一使用UTF8
    utf8的兼容性更好
    不是说一定要用utf8,但是库表的字符集一定要统一,统一字符集可以避免由于字符集转换产生的乱码
    mysql中utf8字符集汉字占3个字节(比如定义:user_name varchar(255)会占用765个字节),ascII码占用1个字节。
  • 所有表和字段都要添加注释
    使用comment从句添加表和列的备注
    从一开始就进行数据字典的维护,项目前期不注意维护项目字典,项目后期如果人员变化比较大,就会造成不知道某个字段含义,等难以进行维护,必须读代码去了解含义。
  • 尽量控制单表数据量的大小, 建议控制在500万以内
    500万并不是mysql数据库的限制
    mysql最多可以存储多少万数据,取决于存储设置和文件系统
    可以用历史数据归档,分库分表等手段来控制数据量的大小
  • 谨慎使用mysql分区表
    分区表在物理上表现为多个文件,在逻辑上表现为一个表
    谨慎选择分区键,跨分区查询效率可能更低
    建议采用物理分表的形式管理大数据
  • 尽量做到冷热数据分离,减小表的宽度(冷数据:不常用的数据;热数据:常用的数据)
    mysql限制最多存储4096列,并且每一行的数据不能超过65535个字节。
    减少磁盘io,保证热数据的内存缓存命中率
    更有效的利用缓存,避免读入无用的冷数据(不可否认,很多人喜欢select *,会导致很多无用的冷数据被加载)
    把表中的列进行垂直拆分,经常一起使用的列放到一个表中,避免过多关联操作。
  • 禁止在表中建立预留字段
    预留字段的命名很难做到见名知意。
    预留字段无法确认存储的数据类型,所以无法选择合适的数据类型。
    对预留字段的类型的修改,会对表进行锁定。
    修改一个字段的开销,比增加一个字段更大。
  • 禁止在数据库中存储图片,文件等二进制数据
    文件一般都很大,会极大增加数据库的开销
  • 禁止在线上做数据库压力测试
    会产生大量垃圾数据,给以后带来不必要的麻烦
  • 禁止从开发环境,测试环境直连生产环境数据库
    如果直接从开发环境连接生产环境,很容易对生产环境的数据的完整性造成破坏。

3. 数据库索引设计规范

  • 限制每张表的索引的数量,建议单张表的索引数量不超过5个
    列的数量一般和索引的数量成正比,前面限制列的数量同时也是为了减少索引的途径。
    索引不是越多越好!索引可以提高效率,同时也会降低效率。
    索引是会占据一定的物理空间的。
    禁止给表的每个字段建立单独的索引。
  • 每个Innodb表必须有一个主键
      Innodb是按照主键索引的顺序来组织表的!如果没有为表指定主键,mysql会优先选择第一个非空唯一索引作为主键,如果连非空唯一索引都没有,mysql会生成一个占6个字节的主键,而这个主键的性能并不是最好的。
      不使用更新频繁的列作为主键,不使用多列主键。
      不使用UUID,MD5,HASH,字符串列作为主键。因为这些并不能保证生成的数值是有顺序的,新生成的数据可能会排序到之前的某个位置,增加io操作,浪费数据库开销。
      主键建议使用自增ID值
  • 常见索引列建议
    select 、update、delete语句的where从句中的列
    包含在order by、group by、distingct中的字段
    多表join的关联列
  • 如何选择索引列的顺序
    索引列是按照从左向右的顺序使用的
    区分度最高的列放在联合索引的最左侧
    尽量把字段长度小的列放在联合索引的最左侧
    使用最频繁的列放到联合索引的左侧
    注意合理选择符合索引键值顺序
  • 避免建立冗余索引和重复索引(冗余索引:列被多个索引包含;重复索引:索引列完全重复)
    如:primary key(id)、index(id)、unique index(id)-----对于id是完全重复的。
    如:index(a,b,c)、index(a,b)、index(a)-----这三个索引都包含a,产生了冗余。
  • 对于频繁的查询优先考虑使用覆盖索引
    覆盖索引:包含了所有查询字段的索引。
    避免Innodb表进行索引的二次查找
    可以把随机io变为顺序io加快查询的效率
  • 尽量避免使用外键
    不建议使用外键约束,但一定在表与表的关联键上建立索引。
    外键可以用于保证数据的参照完整性,但建议在业务端实现。
    外键会影响父表和子表的写操作,从而影响性能。

4. 数据库字段设计规范

  • 优先选择符合存储需要的最小的数据类型
    将字符串转化为数字类型存储
    INT_ATON('255.255.255.255')=4294967295
    INET_NTOA(4294967295)='255.255.255.255'
    对于非负整数来说,要优先使用无符号整型来存储。因为:无符号相对于有符号可以多出一倍的存储空间。
    SIGNED INT -2147483648~2147483647
    UNSIGNED INT 0~429467295
    注意:
    在mysql中VARCHAR(N)中的N代表的是字符数,而不是字节数。其他的关系型数据库可能是字节,N/3算可以容纳多少中文。
    使用UTF8存储汉字,VARCHAR(255)=765个字节。
    过大的长度会消耗更多的内存。
  • 避免使用TEXT、BLOB数据类型
    text分为:TinyText、Text、MidumText、LongText。Text可以存储下64k的数据。
    建议把BLOB或是TEXT列分离到单独的扩展表中。
    TEXT或BOLB类型只能使用前缀索引,并且这种类型不要有默认值。
  • 避免使用ENUM数据类型
    首先说明:enum类型的值是首先把类似varchar类型的值转化为int类型进行存储,减小存储开销这是好的一点,但是毙大于利。
    (1)修改ENUM值需要使用ALTER语句。对表级别的操作存在误操作的风险,带来不可预知的后果。
    (2)enum类型的order by操作效率低,需要额外操作。因为:如果是varchar类型的值enum会先将int类型转化为varchar再排序,比较消耗性能。
    (3)禁止使用数值作为enum的枚举值。因为:enum本身就是把int型外的转化为int存储,如果本身存储的值就是int会很容易造成逻辑上的混淆,一般如果我们存储的就是整型,就直接存储为整型。
  • 尽量把所有列定义为NOT NULL
    (1)索引null列需要额外的空间来保存,所以要占用更多的空间。
    (2)进行比较时要对null值做特别的处理。
  • 不要用字符串存储日期类型的数据
    (1)无法用日期函数进行计算和比较
    (2)用字符串存储要占用更多的空间,如果用字符串要至少占用16个字节,而用datetime只需要8个字节
  • 使用TIMESTAMP或DATETIME类型存储时间
    (1)timestamp存储的区间为1970-01-01 00:00:01~2038-01-19 03:14:07
    (2)timestamp占用4个字节和int相同,但比int可读性高
    (3)超出timestamp区间的使用datetime类型
  • 同财务相关的金额类数据,必须使用decimal类型
    (1)decimal类型为精准浮点数,在计算时不会丢失精度。
    (2)占用的空间由定义的宽度决定
    (3)可用于存储比bigint更大的整型数据

5. sql开发规范

  • 建议使用预编译语句进行数据库操作
    mysql数据库架构设计与优化_第3张图片
    (1)只传参数,比传递sql语句更高效
    (2)可以防范sql注入的风险
    (3)相同语句可以一次解析,多次使用,提高处理效率
  • 避免数据类型的隐式转换
    (1)隐式转换,会导致索引失效。
  • 合理充分利用存在索引,而不是盲目增加索引
    (1)避免使用双%号的查询条件,如:a like ‘%abc%’,去掉左边的%可以利用索引。
    (2)一个sql只能利用到符合索引中的一列进行范围查找。
    (3)使用left join或not exists来优化not in,因为not in会导致索引失效。
  • 程序连接不同的数据库使用不同的账号,禁止跨库查询
    (1)为数据库迁移和分库分表留出余地
    (2)降低业务的耦合度
    (3)避免权限过大而产生的安全风险
  • *禁止使用select ,必须使用select <字段列表>查询
    (1)消耗更多的cup和IO以及网络带宽资源,查询了更多无用数据。
    (2)无法使用覆盖索引
    (3)可减少表结构变更带来的影响
  • 禁止使用不含字段列表的INSERT语句
    (1)insert into t values('a',1);应该明确字段列表insert into t(c1,c2) values('a',1);
    (2)可以减少表结构变更带来的影响
  • 避免使用子查询,可以把子查询优化为join操作
    (1)子查询的结果集无法使用索引
    (2)子查询会产生临时表操作,如果子查询数据量大则严重影响效率。
    (3)子查询的临时表无索引,会产生大量慢查询,消耗过多cpu以及io资源。
  • 避免使用JOIN关联太多的表
    (1)每join一个表会多占用一部分内存(join_buffer_size)
    (2)会产生临时表操作,影响查询效率
    (3)mysql最多允许关联61个表,建议不超过5个
  • 减少同数据库的交互次数
    (1)数据库更适合批处理操作
    (2)合并多个相同的操作到一起,可以提高处理效率
alter table t1 add column c1 int,change column c2 int ...
  • 使用in代替or
    (1)in的值不要超过500个 。
    (2)in操作可以有效利用索引,而用or大多数情况下很少利用到索引。
  • 禁止使用order by rand()进行随机排序
    (1)会把表中所有符合条件的数据转载到内存中进行排序
    (2)会消耗大量的cpu以及io和内存资源
    (3)对于这种获取随机数据可以采用:在程序中获取一个随机值,可以是id,然后按照这个随机值从数据库中获取数据,也即这种随机获取的业务在代码中去实现。
  • WHERE从句中禁止对列进行函数转换和计算
    (1)对列进行函数转换或计算会导致无法使用索引
where date(createtime)='20190423'--这样会导致在createtime列上的索引失效
where createtime>='20190423' and createtime<'20190423'--这样索引不会失效
  • 在明显不会有重复值或可以允许有重复值时,使用UNION ALL而不是UNION
    (1)union会把所有数据放到临时表中然后进行去重操作
    (2)union all不会对结果集进行去重操作
  • 拆分复杂的大sql为多个小sql
    (1)mysql一个sql只能使用一个cpu进行计算
    (2)sql拆分后可以通过并行执行来提高处理效率

6. 数据库操作规范

  • 超过100万行的批量写操作,要分批多次进行操作
    (1)大批量操作可能会造成严重的主从延迟
    (2)binlog日志为row格式时会产生大量的日志
    (3)避免产生大事务操作
  • 对大表数据的修改一定要谨慎,有可能会造成严重的锁表操作,尤其是生产环境,是不能忍受的
  • 对大表使用pt-online-schema-change工具修改表结构
    (1)避免大表修改产生的主从延迟
    (2)避免对表修改时进行锁表
  • 禁止为程序使用的账号赋予super权限
    (1)当达到最大连接数限制时,还允许一个由super权限的用户连接。
    (2)super权限只能留给dba作为处理问题的账号使用。
  • 程序连接连接数据库账号,遵循权限最小原则
    (1)程序使用的数据库账号只能在一个db下使用,不准跨库。
    (2)程序使用的数据库账号,原则上不准有drop权限。

其他

  • 可以了解一下数据库三范式

你可能感兴趣的:(MySQL)