null51CTO博客 - 娱乐之横扫全球

null51CTO博客

2019年03月05日10时17分54秒 | 作者: 运骏 | 标签: | 浏览: 411

DBA操作标准

1、触及事务上的修正/删去数据,在得到事务方、CTO的邮件同意后方可履行,履行前提早做好备份,必要时可逆。


2、一切上线需求有必要走工单体系,口头告诉视为无效。


3、在对大表做表结构改变时,如修正字段特点会形成锁表,并会形成从库推迟,然后影响线上事务,有必要在清晨0:00 后事务低峰期履行,另共同用东西 pt-online-schema-change 防止锁表且下降推迟履行时刻。

运用典范:

#pt-online-schema-change  alter="add index IX_id_no(id_no)"  \
no-check-replication-filters  recursion-method=none  user=dba  \  
password=123456  D=test,t=t1 execute

关于MongoDB创立索引要在后台创立,防止锁表。

运用典范:

db.t1.createIndex({idCardNum:1},{background:1})

4、一切线上事务库均有必要树立MHA高可用架构,防止单点问题。


5、给事务方开权限时,暗码要用MD5加密,至少16位。权限如没有特别要求,均为select查询权限,并做库表级约束。


6、删去默许空暗码账号。

delete from mysql.user where user= and password=;

flush privileges;

7、汇总库敞开Audit审计日志功用,呈现问题时方可追溯。


行为标准

8、制止一个MySQL实例寄存多个事务数据库,会形成事务耦合性过高,一旦呈现问题会殃及池鱼,添加了定位毛病问题的难度。一般选用多实例处理,一个实例一个事务库,互不搅扰。


9、制止在主库上履行后台办理和核算类的功用查询,这种杂乱类的SQL会形成CPU的升高,进而会影响事务。


10、批量清洗数据,需求开发和DBA一起进行检查,应避开事务高峰期时段履行,并在履行进程中调查效劳状况。


11、促销活动等应提早与DBA当面交流,进行流量评价,比方提早一周添加机器内存或扩展架构,防止DB呈现功用瓶颈。


12、制止在线上做数据库压力测验。


根本标准

13、制止在数据库中存储明文暗码。


14、运用InnoDB存储引擎。

  • 支撑事务,行级锁,更好的恢复性,高并发下功用更好。
  • InnoDB表防止运用COUNT(*)操作,因内部没有计数器,需求一行一行累加核算,计数核算实时要求较强能够运用memcache或许Redis。

15、表字符集共同运用UTF8。

  • 不会发生乱码危险。

16、一切表和字段都需求添加中文注释。

  • 便利别人、便利自己。

17、不在数据库中存储图片、文件等大数据。

  • 图片、文件更适宜于GFS散布式文件体系,数据库里寄存超链接即可。

18、防止运用存储进程、视图、触发器、事情。

MySQL是OLTP运用,最拿手简略的增、删、改、查操作,但对逻辑核算剖析类的运用,并不适宜,所以这部分的需求最好通进程序上完成。


19、防止运用外键,外键用来保护参照完整性,可在事务端完成。

  • 外键会导致父表和子表之间耦合,非常影响SQL功用,呈现过多的锁等候,甚至会形成死锁。

20、对事务共同性要求不高的事务,如日志表等,优先挑选存入MongoDB。

  • 其本身支撑的sharding分片功用,增强了横向扩展的才干,开发不必过多调整事务代码。

库表规划标准

21、表有必要有主键,例如自增主键。

  • 这样能够确保数据行是依照次序写入,关于SAS传统机械式硬盘写入功用更好,依据主键做相关查询的功用也会更好,并且还便利了数据仓库抽取数据。从功用的视点来说,运用UUID作为主键是个最欠好的办法,它会使刺进变得随机。

22、制止运用分区表。

  • 分区表的优点是关于开发来说,不必修正代码,经过后端DB的设置,比方关于时刻字段做拆分,就能够轻松完成表的拆分。但这里边触及一个问题,查询的字段有必要是分区键,否则会遍历一切的分区表,并不会带来功用上的进步。此外,分区表在物理结构上仍旧是一张表,此刻咱们更改表结构,相同不会带来功用上的进步。所以应选用切表的方法做拆分,如程序上需求对前史数据做查询,可经过union all的方法相关查询。别的跟着时刻的推移,前史数据表不再需求,只需在从库上dump出来,即快捷地迁移至备份机上。
字段规划标准

23、用DECIMAL替代FLOAT和DOUBLE存储准确浮点数。
浮点数的缺陷是会引起精度问题,请看下面一个比方:

mysql> CREATE TABLE t3 (c1 float(10,2),c2 decimal(10,2));   
Query OK, 0 rows affected (0.05 sec)
>mysql> insert into t3 values (999998.02, 999998.02);  
Query OK, 1 row affected (0.01 sec)
>mysql> select * from t3;
+-+-+
| c1    | c2    |
+-+-+
| 999998.00 | 999998.02 |
+-+-+
1 row in set (0.00 sec)

能够看到c1列的值由999998.02变成了999998.00,这就是float浮点数类型的不准确性形成的。因而对钱银等对精度灵敏的数据,应该用定点数表明或存储。


24、运用TINYINT来替代ENUM类型。

  • 选用enum枚举类型,会存在扩展的问题,例如用户在线状况,假如此刻添加了:5表明请勿打扰、6表明开会中、7表明隐身对老友可见,那么添加新的ENUM值要做DDL修正表结构操作了。

25、字段长度尽量按实际需求进行分配,不要随意分配一个很大的容量。

挑选字段的一般原则是保小不保大,能用占用字节少的字段就不必大字段。比方主键,强烈主张用int整型,不必uuid,为什么?省空间啊。空间是什么?空间就是功率!按4个字节和按32个字节定位一条记载,谁快谁慢太显着了。触及几个表做join时,作用就更显着了。更小的字段类型占用的内存就更少,占用的磁盘空间和磁盘I/O也会更少,并且还会占用更少的带宽。

有不少开发人员在规划表字段时,只要是针对数值类型的悉数用int,但这不必定适宜,就比方用户的年纪,一般来说,年纪大都在1~100岁之间,长度只要3,那么用int就不适宜了,能够用tinyint替代。又比方用户在线状况,0表明离线、1表明在线、2表明脱离、3表明繁忙、4表明隐身等,其实相似这样的状况,用int都是没有必要的,糟蹋空间,选用tinyint完全能够满足需求,int占用的是4字节,而tinyint才占用1个字节。

int整型有符号(signed)最大值是2147483647,而无符号(unsigned)最大值是4294967295,假如你的需求没有存储负数,那么主张改成有符号(unsigned),能够添加int存储规模。

int(10)和int(1)没有什么区别,10和1仅是宽度罢了,在设置了zerofill扩展特点的时分有用,例:

root@localhost(test)10:39>create table test(id int(10) zerofill,id2 int(1));
Query OK, 0 rows affected (0.13 sec)
root@localhost(test)10:39>insert into test values(1,1);
Query OK, 1 row affected (0.04 sec)
root@localhost(test)10:56>insert into test values(1000000000,1000000000);
Query OK, 1 row affected (0.05 sec)
root@localhost(test)10:56>select * from test;
+++
| id   | id2    |
+++
| 0000000001 |    1 |
| 1000000000 | 1000000000 |
+++
2 rows in set (0.01 sec)

26、字段界说为NOT NULL要供给默许值。
从运用层视点来看,能够削减程序判别代码,比方你要查询一条记载,假如没默许值,你是不是得先判别该字段对应变量是否被设置,假如没有,你得经过java把该变量置为或许0,假如设了默许值,判别条件可直接略过。

NULL值很难进行查询优化,它会使索引核算愈加杂乱,还需求MySQL内部进行特别处理。


27、尽可能不运用TEXT、BLOB类型。

  • 添加存储空间的占用,读取速度慢。
索引标准

28、索引不是越多越好,按实际需求进行创立。

  • 索引是一把双刃剑,它能够进步查询功率但也会下降刺进和更新的速度并占用磁盘空间。恰当的索引对运用的功用至关重要,并且在MySQL中运用索引它的速度是极快的。惋惜的是,索引也有相关的开支。每次向表中写入时(如INSERT、UPDATEH或DELETE),假如带有一个或多个索引,那么MySQL也要更新各个索引,这样索引就添加了对各个表的写入操作的开支。只要当某列被用于WHERE子句时,才干享受到索引的功用进步的优点。假如不运用索引,它就没有价值,并且会带来保护上的开支。

29、查询的字段有必要创立索引。

  • 如:1、SELECT、UPDATE、DELETE句子的WHERE条件列;2、多表JOIN的字段。

30、不在索引列进行数学运算和函数运算。
无法运用索引,导致全表扫描。
例:SELECT * FROM t WHERE YEAR(d) >= 2016;
因为MySQL不像Oracle那样支撑函数索引,即便d字段有索引,也会直接全表扫描。
应改为->
SELECT * FROM t WHERE d >= 2016-01-01;


31、不在低基数列上树立索引,例如‘性别’。
有时分,进行全表阅读要比有必要读取索引和数据表更快,尤其是当索引包括的是均匀散布的数据集是更是如此。对此典型的比方是性别,它有两个均匀散布的值(男和女)。经过性别需求读取大约一半的行。在种状况下进行全表扫描阅读要更快。


32、不运用%前导的查询,如like ‘%xxx’。
无法运用索引,导致全表扫描。

低效查询
SELECT * FROM t WHERE name LIKE %de%;
->
高效查询
SELECT * FROM t WHERE name LIKE de%;

33、不运用反向查询,如 not in / not like。
无法运用索引,导致全表扫描。


34、防止冗余或重复索引。
联合索引IX_a_b_c(a,b,c) 相当于 (a) 、(a,b) 、(a,b,c),那么索引 (a) 、(a,b) 就是剩余的。


SQL规划标准

*35、不运用SELECT ,只获取必要的字段。**
耗费CPU和IO、耗费网络带宽;
无法运用掩盖索引。


36、用IN来替换OR。

低效查询
SELECT * FROM t WHERE LOC_ID = 10 OR LOC_ID = 20 OR LOC_ID = 30;
->
高效查询
SELECT * FROM t WHERE LOC_IN IN (10,20,30);

37、防止数据类型不共同。

SELECT * FROM t WHERE id = 19;
->
SELECT * FROM t WHERE id = 19;

38、削减与数据库的交互次数。

INSERT INTO t (id, name) VALUES(1,Bea);
INSERT INTO t (id, name) VALUES(2,Belle);
INSERT INTO t (id, name) VALUES(3,Bernice);
->
INSERT INTO t (id, name) VALUES(1,Bea), (2,Belle),(3,Bernice);

Update … where id in (1,2,3,4);

Alter table tbl_name add column col1, add column col2;

39、拒绝大SQL,拆分红小SQL。

低效查询
SELECT * FROM tag
JOIN tag_post ON tag_post.tag_id = tag.id
JOIN post ON tag_post.post_id = post.id
WHERE tag.tag = mysql;
能够分解成下面这些查询来替代
->
高效查询
SELECT * FROM tag WHERE tag = mysql
SELECT * FROM tag_post WHERE tag_id = 1234
SELECT * FROM post WHERE post_id in (123, 456, 567, 9098, 8904);

40、制止运用order by rand()

SELECT * FROM t1 WHERE 1=1 ORDER BY RAND() LIMIT 4;
>
SELECT * FROM t1 WHERE id >= CEIL(RAND()*1000) LIMIT 4;
版权声明
本文来源于网络,版权归原作者所有,其内容与观点不代表娱乐之横扫全球立场。转载文章仅为传播更有价值的信息,如采编人员采编有误或者版权原因,请与我们联系,我们核实后立即修改或删除。

猜您喜欢的文章