MySQL开发规范

字符设计规范:
1. 选择合适的字符集,短字符集更利于传输和存储:通常使用UTF8字符集。如果确认系统只需要支持英文字符,则用latin1;如果只需要支持中文,则用GBK,GB2312;需要国际化,则用UTF8
2. character-set-server服务端(db,table,filed)--- default_character_set客户端(connection)--工具(GUI)。确保这三种字符集一致,才可以避免乱码的问题
3. 校验字符集: collation-server=*_ci,*_bin
4. 字符集和校验规则的指定:就近原则 ( 级别高低 server > database > table > column )
5. MySQL数据库脚本文件字符集,要与数据库保持一致。( Latin1—ISO-8859-1;GBK,GB2312—UTF8;UTF8—UTF8),确保mysql执行这些脚本的时候,不会乱码

mysql 索引规范:
1. 索引的顺序
向右匹配直到遇到范围查询就停止匹配
等值(=) -> 范围( < , > , between , like ) -> join -> 排序 ( order by , group by , distinct )
2. 尽量使用复合索引覆盖单列索引
3. 避免重复索引
同一个表有 (a)单列索引, (a,b)组合索引 和 (a,b,c)组合索引
4. 不要在索引列使用函数: max(id) , mysql不支持函数索引
5. 尽量使用选择率高的字段作为前缀索引
count(distinct column)/count(*) ,越高越好
6. 索引中字段数不超过5个
7. 唯一索引和主键重复
8. order by , group by , distinct字段需要在索引后面添加
9. SQL上线前查看explain检查执行计划是否合理,避免extra列出现 using filesort , using temporay
10. varchar字段建立索引时,不超过15个字符长度前缀索引
下面的表增加一列url_crc32,然后对 url_crc32 建立索引,减少索引字段的长度,提高效率,前面的url字段最好是唯一字符,提高选择率
CREATE TABLE all_url(
ID INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
url VARCHAR(255) NOT NULL DEFAULT 0,
url_crc32 BIGINT UNSIGNED NOT NULL DEFAULT 0,
index i_url_crc32(url_crc32)
)engine = InnoDB;
合理创建联合索引(避免冗余),(a,b,c) 索引已经可以覆盖 (a) 、(a,b) ,就没必要创建后两个索引了
合理利用覆盖索引,也就是尽可能在SELECT 中包含索引中的字段,减少回表读取产生的I/O 读
11. 类型隐式转换导致执行计划改变

mysql ddl规范:
1. 所有变更至少提前1天提交
2. 所有dll需求要Team Leader审核通过之后提交
3. 所有新上线的表都必须确定索引后才能上线

mysql sql语句开发:
1. 少用触发器
2. 不使用 * , select 使用具体的字段名
3. 减少锁等待和竞争,避免使用大事务,使用短小事务
4. 禁止使用% 前缀模糊查询 where like ‘%xxx‘
5. 某些低版本mysql 尽量使用join 代替子查询
6. 使用延迟关联解决大offset分页问题
7. 禁止并发执行 count(*)
8. 禁止使用order by rand()
9. 批量更新和删除 , 不要一次更新大量数据
10. sql使用in 代替 or (or效率高于in)

命名规范:
1. 数据库名,表名和字段名不要超过32个字符
2. 禁用特殊符号
3. 不得与rdbms保留字冲突
4. 库/表/字段/索引名称一律小写

表设计规范:
1. 只使用innodb存储引擎 , 支持事务 , myisam引擎不支持事务和只有表级别锁
2. auto_increment 必须有并且自增主键跟业务是透明的,因为透明主键对业务操作不会有任何影响,主从同步也优先根据主键进行
3. 禁止联合字段和字符字段做主键 , 主键字段过长导致性能问题 , 联合字段容易导致死锁问题
4. 不在数据库中存储图片,文件等大数据
5. 禁止使用分区表
6. 避免使用数据库保留字段

列设计规范:
1. 尽量减少存储空间
2. 尽量使用数值类型 + unsigned
3. 少用blog/text字段 , 如有需要 , 将该表分为主表和子表用主键一一对应 , 子表只存放blog/text字段和对应主表的主键
4. 禁止使用外健 , 对于数据库的所有外键的每次插入、更新和删除后,进行完整性检查是一个耗费时间和资源的过程,它可能影响性能,特别是当处理复杂的或者是缠绕的连接树时。
5. 使用unsigned存储非负整数
6. varchar(N) 是表示字符数
7. 用tinyint来替换枚举类型enum和集合类型set
8. 时间使用datetime 或者使用时间戳

语句实现的锁
1. select ... from , 一致性非锁定读
2. lock in shared mode , 共享
3. select ... for update , 排他
4. update / delete, 排他
5. insert ... on duplicate key update , 排他
6. replace , 没冲突/重复时,和insert 一样
7. insert into t select ... from s , t表加排他
8. create table t ... select , t表加排他
9. replace into t select ... from s where 或者 update t ... where col in (select ... from s),都会在s表上排他

时间: 2024-12-26 08:51:17

MySQL开发规范的相关文章

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

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

根据多年经验整理的《互联网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开发规范与使用技巧总结

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

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. 请不要使用外键约束,如果数据存在外