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

1.命名规范

1.库名、表名、字段名必须使用小写字母,并采用下划线分割

a)MySQL有配置参数lower_case_table_names,不可动态更改,linux系统默认为 0,即库表名以实际情况存储,大小写敏感。如果是1,以小写存储,大小写不敏感。如果是2,以实际情况存储,但以小写比较。

b)如果大小写混合使用,可能存在abc,Abc,ABC等多个表共存,容易导致混乱。

c)字段名显示区分大小写,但实际使?用不区分,即不可以建立两个名字一样但大小写不一样的字段。

d)为了统一规范, 库名、表名、字段名使用小写字母。

2.库名、表名、字段名禁止超过32个字符。

库名、表名、字段名支持最多64个字符,但为了统一规范、易于辨识以及减少传输量,禁止超过32个字符。

3.使用INNODB存储引擎。

INNODB引擎是MySQL5.5版本以后的默认引擘,支持事务、行级锁,有更好的数据恢复能力、更好的并发性能,同时对多核、大内存、SSD等硬件支持更好,支持数据热备份等,因此INNODB相比MyISAM有明显优势。

4.库名、表名、字段名禁止使用MySQL保留字。

当库名、表名、字段名等属性含有保留字时,SQL语句必须用反引号引用属性名称,这将使得SQL语句书写、SHELL脚本中变量的转义等变得?非常复杂。

5.禁止使用分区表。

分区表对分区键有严格要求;分区表在表变大后,执?行DDL、SHARDING、单表恢复等都变得更加困难。因此禁止使用分区表,并建议业务端手动SHARDING。

6.建议使用UNSIGNED存储非负数值。

同样的字节数,非负存储的数值范围更大。如TINYINT有符号为 -128-127,无符号为0-255。

7.建议使用INT UNSIGNED存储IPV4。

用UNSINGED INT存储IP地址占用4字节,CHAR(15)则占用15字节。另外,计算机处理整数类型比字符串类型快。使用INT UNSIGNED而不是CHAR(15)来存储IPV4地址,通过MySQL函数inet_ntoa和inet_aton来进行转化。IPv6地址目前没有转化函数,需要使用DECIMAL或两个BIGINT来存储。

例如:

SELECT INET_ATON(‘209.207.224.40‘); 3520061480
SELECT INET_NTOA(3520061480); 209.207.224.40

8.强烈建议使用TINYINT来代替ENUM类型。

ENUM类型在需要修改或增加枚举值时,需要在线DDL,成本较高;ENUM列值如果含有数字类型,可能会引起默认值混淆。

9.使用VARBINARY存储大小写敏感的变长字符串或二进制内容。

VARBINARY默认区分大小写,没有字符集概念,速度快。

10.INT类型固定占用4字节存储

例如INT(4)仅代表显示字符宽度为4位,不代表存储长度。数值类型括号后面的数字只是表示宽度而跟存储范围没有关系,比如INT(3)默认显示3位,空格补齐,超出时正常显示,python、java客户端等不具备这个功能。

11.区分使用DATETIME和TIMESTAMP。

存储年使用YEAR类型。存储日期使用DATE类型。 存储时间(精确到秒)建议使用TIMESTAMP类型。

DATETIME和TIMESTAMP都是精确到秒,优先选择TIMESTAMP,因为TIMESTAMP只有4个字节,而DATETIME8个字节。同时TIMESTAMP具有自动赋值以及?自动更新的特性。注意:在5.5和之前的版本中,如果一个表中有多个timestamp列,那么最多只能有一列能具有自动更新功能。

如何使用TIMESTAMP的自动赋值属性?

a)自动初始化,而且自动更新:

column1 TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATECURRENT_TIMESTAMP

b)只是自动初始化:

 column1 TIMESTAMP DEFAULT CURRENT_TIMESTAMP

c)自动更新,初始化的值为0:

 column1 TIMESTAMP DEFAULT 0 ON UPDATE CURRENT_TIMESTAMP

d)初始化的值为0:

column1 TIMESTAMP DEFAULT 0

12.所有字段均定义为NOT NULL。

a)对表的每一行,每个为NULL的列都需要额外的空间来标识。

b)B树索引时不会存储NULL值,所以如果索引字段可以为NULL,索引效率会下降。

c)建议用0、特殊值或空串代替NULL值。

MySQL使用技巧

1.将大字段、访问频率低的字段拆分到单独的表中存储,分离冷热数据。

有利于有效利用缓存,防?止读入无用的冷数据,较少磁盘IO,同时保证热数据常驻内存提?高缓存命中率。

2.禁止在数据库中存储明文密码。

采用加密字符串存储密码,并保证密码不可解密,同时采用随机字符串加盐保证密码安全。

3.表必须有主键,推荐使用UNSIGNED自增列作为主键。

表没有主键,INNODB会默认设置隐藏的主键列;没有主键的表在定位数据行的时候非常困难,也会降低基于行复制的效率。

4.禁止冗余索引。

索引是双刃剑,会增加维护负担,增?大IO压力。(a,b,c)、(a,b),后者为冗余索引。可以利用前缀索引来达到加速目的,减轻维护负担。

5.禁止重复索引。

primary key a;uniq index a;重复索引增加维护负担、占用磁盘空间,同时没有任何益处。

6.不在低基数列上建立索引,例如“性别”。

大部分场景下,低基数列上建立索引的精确查找,相对于不建立索引的全表扫描没有任何优势,而且增大了IO负担。

7.合理使用覆盖索引减少IO,避免排序。

覆盖索引能从索引中获取需要的所有字段,从?而避免回表进行二次查找,节省IO。

INNODB存储引擎中,secondary index(非主键索引,又称为辅助索引、二级索引)没有直接存储行地址,而是存储主键值。

如果用户需要查询secondary index中所不包含的数据列,则需要先通过secondary index查找到主键值,然后再通过主键查询到其他数据列,因此需要查询两次。覆盖索引则可以在?一个索引中获取所有需要的数据,因此效率较高。

例如SELECT email,uid FROM user_email WHERE uid=xx,如果uid不是主键,适当时候可以将索引添加为index(uid,email),以获得性能提升。

8.用IN代替OR。SQL语句中IN包含的值不应过多,应少于1000个。

IN是范围查找,MySQL内部会对IN的列表值进行排序后查找,比OR效率更高。

9.表字符集使用UTF8,必要时可申请使用UTF8MB4字符集。

a)UTF8字符集存储汉字占用3个字节,存储英文字符占用一个字节。

b)UTF8统一而且通用,不会出现转码出现乱码风险。

c)如果遇到EMOJ等表情符号的存储需求,可申请使用UTF8MB4字符集。

10.用UNION ALL代替UNION。

UNION ALL不需要对结果集再进行排序。

11.禁止使用order by rand()。

order by rand()会为表增加一个伪列,然后用rand()函数为每一行数据计算出rand()值,然后基于该行排序,这通常都会生成磁盘上的临时表,因此效率非常低。建议先使用rand()函数获得随机的主键值,然后通过主键

获取数据。

12.建议使用合理的分页方式以提高分页效率。

假如有类似下面分页语句:

SELECT * FROM table ORDER BY TIME DESC LIMIT 10000,10;

这种分页方式会导致大量的io,因为MySQL使用的是提前读取策略。

推荐分页方式:

SELECT * FROM table WHERE TIME<last_TIME ORDER BY TIME DESC LIMIT 10.
SELECT * FROM table inner JOIN (SELECT id FROM table ORDER BY TIME LIMIT 10000,10) as t
USING(id)

13.SELECT只获取必要的字段,禁?止使用SELECT *。

减少网络带宽消耗;

能有效利用覆盖索引;

表结构变更对程序基本无影响。

14.SQL中避免出现now()、rand()、sysdate()、current_user()等不确定结果的函数。

语句级复制场景下,引起主从数据不一致;不确定值的函数,产?生的SQL语句无法利用QUERY CACHE。

15.采用合适的分库分表策略。例如千库十表、十库百表等。

采用合适的分库分表策略,有利于业务发展后期快速对数据库进行水平拆分,同时分库可以有效利?用MySQL

的多线程复制特性。

16.减少与数据库交互次数,尽量采用批量SQL语句。

使用下面的语句来减少和db的交互次数:

a)INSERT ... ON DUPLICATE KEY UPDATE
b)REPLACE INTO
c)INSERT IGNORE
d)INSERT INTO VALUES() 

17.拆分复杂SQL为多个小SQL,避免大事务。

简单的SQL容易使?用到MySQL的QUERY CACHE;减少锁表时间特别是MyISAM;可以使用多核 CPU。

18.对同一个表的多次alter操作必须合并为一次操作。

mysql对表的修改绝大部分操作都需要锁表并重建表,而锁表则会对线上业务造成影响。为减少这种影响,必须把对表的多次alter操作合并为一次操作。例如,要给表t增加一个字段b,同时给已有的字段aa建立索引,

通常的做法分为两步:

alter table t add column b varchar(10);

然后增加索引:

alter table t add index idx_aa(aa);

正确的做法是:

alter table t add column b varchar(10),add index idx_aa(aa);

19.避免使用存储过程、触发器、视图、自定义函数等。

这些高级特性有性能问题,以及未知BUG较多。业务逻辑放到数据库会造成数据库的DDL、SCALE OUT、

SHARDING等变得更加困难。

20.禁止有super权限的应用程序账号存在。

安全第一。super权限会导致read only失效,导致较多诡异问题而且很难追踪。

21.不要在MySQL数据库中存放业务逻辑。

数据库是有状态的服务,变更复杂而且速度慢,如果把业务逻辑放到数据库中,将会限制业务的快速发展。建议把业务逻辑提前,放到前端或中间逻辑层,而把数据库作为存储层,实现逻辑与存储的分离。

版权声明:本文为博主原创文章,未经博主允许不得转载。

时间: 2024-08-16 20:54:39

MySQL开发规范与使用技巧总结的相关文章

[转载] 根据多年经验整理的《互联网MySQL开发规范》

原文: http://weibo.com/p/2304181380b3f180102vsg5 根据多年经验整理的<互联网MySQL开发规范> 写在前面:无规矩不成方圆.对于刚加入互联网的朋友们,肯定会接触到MySQL,MySQL作为互联网最流行的关系型数据库产品,它有它擅长的地方,也有它不足的短板,针对它的特性,结合互联网大多应用的特点,笔者根据自己多年互联网公司的MySQLDBA经验,现总结出互联网MySQL的一些开发规范,仅供参考. 一.基础规范 (1) 使用INNODB存储引擎 (2) 

MySQL开发规范

字符设计规范:1. 选择合适的字符集,短字符集更利于传输和存储:通常使用UTF8字符集.如果确认系统只需要支持英文字符,则用latin1:如果只需要支持中文,则用GBK,GB2312;需要国际化,则用UTF82. character-set-server服务端(db,table,filed)--- default_character_set客户端(connection)--工具(GUI).确保这三种字符集一致,才可以避免乱码的问题3. 校验字符集: collation-server=*_ci,*

根据多年经验整理的《互联网MySQL开发规范》

一.基础规范 使用 INNODB 存储引擎 表字符集使用 UTF8  所有表都需要添加注释 单表数据量建议控制在 5000W 以内 不在数据库中存储图?.文件等大数据 禁止在线上做数据库压力测试 禁?从测试.开发环境直连数据库 二.命名规范 库名表名字段名必须有固定的命名长度,12个字符以内 库名.表名.字段名禁?止超过32个字符.须见名之意 库名.表名.字段名禁?止使?用MySQL保留字 临时库.表名必须以tmp为前缀,并以?日期为后缀 备份库.表必须以bak为前缀,并以日期为后缀 三.库.表

MySQL开发规范和原则大全

一. 表设计 库名.表名.字段名必须使用小写字母,“_”分割. 库名.表名.字段名必须不超过12个字符. 库名.表名.字段名见名知意,建议使用名词而不是动词. 建议使用InnoDB存储引擎. 存储精确浮点数必须使用DECIMAL替代FLOAT和DOUBLE. 建议使用UNSIGNED存储非负数值. 建议使用INT UNSIGNED存储IPV4. 整形定义中不添加长度,比如使用INT,而不是INT(4). 使用短数据类型,比如取值范围为0-80时,使用TINYINT UNSIGNED. 不建议使用

老叶观点:MySQL开发规范之我见

大多数MySQL规范在网上也都能找得到相关的分享,在这里要分享的是老叶个人认为比较重要的,或者容易被忽视的,以及容易被混淆的一些地方. 1.默认使用InnoDB引擎[老叶观点]已多次呼吁过了,InnoDB适用于几乎99%的MySQL应用场景,而且在MySQL 5.7的系统表都改成InnoDB了,还有什么理由再死守MyISAM呢. 此外,频繁读写的InnoDB表,一定要使用具有自增/顺序特征的整型作为显式主键. [参考]:[MySQL FAQ]系列 — 为什么InnoDB表要建议用自增列做主键.

MySQL生产库开发规范

MySQL开发规范 文件状态:[  ] 草稿[√] 正式发布[  ] 正在修改 文件标识:  当前版本: V1.0 作    者: 贺磊 完成日期: 2016-05-24 变更记录序号 修改日期 修改内容 修改人 审核人 批准人 批准日期1 2016-05-24 MySQL开发规范 贺磊 MySQL开发规范1. 简介持续借鉴.收集并整理一些开发规范和技巧,期望能更充分利用MySQL的特性,得到更好的性能.规范是死的,人是活的.现在定义的规范,是为以后推翻准备的.1.1 目的提供给开发人员参考,方

MySQL 数据库规范--调优篇(终结篇)

前言 这篇是MySQL 数据库规范的最后一篇--调优篇,旨在提供我们发现系统性能变弱.MySQL系统参数调优,SQL脚本出现问题的精准定位与调优方法. 目录 1.MySQL 调优金字塔理论 2.MySQL 慢查询分析--mysqldumpslow.pt_query_digest工具的使用(SQL脚本层面) 3.选择合适的数据类型 4.去除无用的索引--pt_duplicate_key_checker工具的使用(索引层面) 5.反范式化设计(表结构) 6.垂直水平分表 7.MySQL 重要参数调优

MySQL 设计与开发规范

1 目的 本规范的主要目的是希望规范数据库设计与开发,尽量避免由于数据库设计与开发不当而产生的麻烦:同时好的规范,在执行的时候可以培养出好的习惯,好的习惯是软件质量的很好保证. 2 适用范围 本规划的适用人员范围包括涉及数据库设计与开发的相关技术人员. 3 术语约定 本规范采用以下术语描述: ★规则:也称为强规范是编程时必须强制遵守的原则 ★建议:编程时必须加以考虑的原则 ★说明:对此规则或建议进行必要的解释 ★示例:对此规则或建议从正.反两个方面给出 4 规范及建议 4.1 书写规范 4.1.

mysql数据库设计开发规范

1.设计 1. 一般都使用INNODB存储引擎,除非读写比率<1%,才考虑使用MYISAM存储引擎:其他存储引擎请在DBA的建议下使用. 2. Stored procedure (包括存储过程,函数,触发器)对于MYSQL来说还不是很成熟,没有完善的出错记录处理,不建议使用. 3. UUID(),USER()这样的MYSQL INSIDE函数对于复制来说是很危险的,会导致主备数据.不一致.所以请不要使用.如果一定要使用UUID作为主键,让应用程序来产生. 4. 请不要使用外键约束,如果数据存在外