为部门整理的mysql_db使用军规

Posted 2020-09-27 yutingliuyl

mysql_db使用军规:

1、禁止开发測试人员在IDC环境手工删除和改动数据

 

2、全部需求通过DB工具系统提交

 

3、禁止在IDC环境DB进行測试

 

4、IDC环境提交的sql语句一定要经过非正式环境验证。且经过"explain sql;"检验过运行计划有走索引

 

5、IDC环境库表创建统一用小写，库表用英文简称，力求精简

 

6、禁止web机器直连DB

 

7、每条记录要保存数据的创建和改动时间，表通常要有主键。使用innodb引擎

 

8、IDC环境db仅仅授权增查改,删除权限DBA评估

 

9、预估和控制单表的数据量在百万以内，数据量过大需清理或分表

 

10、IDC环境禁止使用mysql视图，存储过程。触发器，自己定义函数

 

 

一、表的一句话优化

 

1.   int型不超过1000w。含char则不超过500w

数字和字符装不下的情况，考虑多字段。

 

2.   按时间分表,按主键取模/hash分表，按量分表

红包是按量来的。

 

3.   限制单库表的数量在万级以内   

 

4.   拒绝text和blob类型

实在避免不了要用text和blob类型，拆表吧。或者弄成本地保存。多机器分片存储。

 

5.   分区的算法能够按时间

比方天、月。便于针对性的查询，命中率100%

 

 

二、字段的一句话优化

 

1   长度能够冗余，可适量10%左右    

tinyint(1Byte)smallint(2Byte)mediumint(3Byte)int(4Byte)bigint(8Byte)认清长度，选择好类型。

 

2   你认识null吗?

避免使用NULL字段,由于NULL字段非常难查询优化。NULL字段的索引须要额外空间；NULL字段的复合索引无效。

错误的样例：`Fpacket_name` char(32) default null。

正确的样例：`Fpacket_name` varchar(60) NOT NULL DEFAULT ‘‘。

`Fface_value` int(10) unsigned NOT NULLDEFAULT ‘0‘。"

 

3   业务上有关联的字段。要定义同样类型

同样的类型做语句操作有助于提高操作效率。降低转换成本。

 

4   选择类型请用数字、枚举

数字表示意思的，来替代字符串。

正确的样例：性别，0男，1女；时间用时间戳的数字形式。IP用数字型等等。

 

三、语句的一句话优化

 

1     利用explain神器来优化语句利弊

Type结果集：显示连接使用了何种类型。从最好到最差的连接类型为const、eq_reg、ref、range、index和all。

 

2     Truncate比delete要快

Delete 计数器不清零, 按行删, 慢。

Truncate相当于删掉重建, 最快。

批量删除最好导出实用数据,然后删掉旧表, 新表重命名。

 

3     用join取代子查询

Join原理,nested loop。Left Join 数据量小的在前面，Straight_JOIN。

 

4     自带函数运算

不要让MYSQL用自己函数，他已经非常累。尽量在程序内实现，比方now()，放到程序里取到了再传入给mysql处理。

更不要在mysql去处理大逻辑运算。

 

5     要知道一条语句是依赖一个CPU内核的

一条语句一个内核。大语句能够拆开多语句，多核机共用，还能够降低mysql锁时间。

 

6     不要select *

除非你查询的全部字段都要用到。

。

。。

否则你占用这么多内存。宽带，CPU时间，IO干鸟蛋。

 

7     假设能用in，就不要用or

or的时间复杂度是n,in的时间复杂度是log(n)。

错误的样例：select Fpacket_name from t_account_packet where Fpacket_id =68698080 or Fpacket_id = 68711068;

正确的样例：select Fpacket_name from t_account_packet where Fpacket_id in(68698080,68711068);"

 

8     假设能用union。就不要用or

和上边同理

 

9     合理使用limit

拍拍数据一般都是自增的，所以定位的话一般都要倒序来看近期时间的。但limit又是最慢的一个倒序合理结合limit的话，能体现出更高的效率。

 

近期的2个批次，正确的样例：select Fpacket_id from t_account_packet order by Fpacket_id desclimit 2；

错误的思路：select count(*) from t_account_packet ; =>879446;

                   selectFpacket_id from t_account_packet limit 879444,879446;

近期的第2个批次，正确的样例：selectFpacket_id from t_account_packet order by Fpacket_id desc limit 1,1。"

错误的思路：select count(*) from t_account_packet ; =>879446;

                   selectFpacket_id from t_account_packet limit 879444,879445;

 

10  假设能用load data，就不要用insert

做幸运占卜师活动的时候，默认是要加载非常多血型和性格相关数据的。当时用的是source+逐行insert方法导数据，或者考虑load data。它的原理是在运行load之前,会关掉索引,当load所有运行完毕后,再又一次创建索引。

而insert的原理是：每插入一条则更新一次数据库,更新一次索引。所以要慢非常多倍。详细多少倍，依赖待处理的数量级。

 

 

四、索引的一句话优化

 

1.   尽量选择区分度高的索引进行检索 

错误的样例：name。

正确的样例：id。

 

2.   不易过多

表数据与索引的容量比保持在1:1       ，至少一条语句中存在一个索引。

 

3.   索引是从左向右原则  

 

4.   利用explain神器来运行和分析索引的覆盖   

 

5.   不要用索引字段做计算    

你见过哪个应急通道上，有自驾车站位的？

 

6.   要认识他们MyISAM(重搜索), Innodb(默认。事务性、重业务)

innodb主键推荐使用自增列