聊聊数据库~MySQL环境篇 (2)

其他配置MariaDB提供了样本:

[dnt@localhost ~] ls /usr/share/mysql/ | grep .cnf my-huge.cnf # 超大内存配置参考 my-innodb-heavy-4G.cnf # 4G内存配置参考 my-large.cnf # 大内存配置 my-medium.cnf # 中等内存配置 my-small.cnf # 小内存配置

PS:thread_concurrency=CPU数*2最佳,修改配置后记得重启数据库

远程访问

1.之前安全初始化的时候把root禁止远程登录了,现在我们创建一个其他用户

1.新增用户.png

2.给用户权限

1.给权限.png

3.防火墙放行指定端口

1.防火墙.png

4.远程客户端测试一下

1.成功.png

Code如下:

# 分配权限 grant all privileges on 数据库.* to 用户名@"%" identified by "密码"; # 刷新设置 flush privileges; # 显示服务状态 systemctl status firewalld # 添加 --permanent永久生效(没有此参数重启后失效) firewall-cmd --zone=public --add-port=80/tcp --permanent # 重新载入 firewall-cmd --reload # 查看 firewall-cmd --zone= public --query-port=80/tcp # 删除 firewall-cmd --zone= public --remove-port=80/tcp --permanent

SQLServer远程连接:https://www.cnblogs.com/dunitian/p/5474501.html

MySQL军规(58)

文章结尾贴一节58的MySQL军规:(适用于并发量大,数据量大的典型互联网业务

1.基础规范

表存储引擎必须使用InnoDB

表字符集默认使用utf8,必要时候使用utf8mb4

utf8通用,无乱码风险,汉字3字节,英文1字节

utf8mb4是utf8的超集,存储4字节时使用(eg:表情符号)

禁止使用存储过程,视图,触发器,Event

调试,排错,迁移都比较困难,扩展性较差

对数据库性能影响较大,互联网业务,能让站点层和服务层干的事情,不要交到数据库层

禁止在数据库中存储大文件(eg:照片)

可以将大文件存储在对象存储系统,数据库中存储路径

禁止在线上环境做数据库压力测试

测试,开发,线上数据库环境必须隔离

2.命名规范

库名,表名,列名必须用小写,采用下划线分隔

abc,Abc,ABC都是给自己埋坑

库名,表名,列名必须见名知义,长度不要超过32字符

tmp,wushan谁TM知道这些库是干嘛的

库备份必须以bak为前缀,以日期为后缀

从库必须以-s为后缀

备库必须以-ss为后缀

3.表设计规范

单实例表个数必须控制在2000个以内

单表分表个数必须控制在1024个以内

表必须有主键,推荐使用unsigned整数为主键

潜在坑:删除无主键的表,如果是row模式的主从架构,从库会挂住

禁止使用外键,如果要保证完整性,应由应用程式实现

外键使得表之间相互耦合,影响update/delete等SQL性能

有可能造成死锁,高并发情况下容易成为数据库瓶颈

建议将大字段,访问频度低的字段拆分到单独的表中存储,分离冷热数据

垂直拆分的依据,尽量把长度较短,访问频率较高的属性放在主表里

流量大数据量大时,数据访问要有service层,并且service层不要通过join来获取主表和扩展表的属性

具体可以参考沈剑大牛写的《如何实施数据库垂直拆分》

4.列设计规范

根据业务区分使用tinyint/int/bigint,分别会占用1/4/8字节

根据业务区分使用char/varchar(PS:没有MSSQL里的nvarchar)

字段长度固定,或者长度近似的业务场景,适合使用char,能够减少碎片,查询性能高

字段长度相差较大,或者更新较少的业务场景,适合使用varchar,能够减少空间

根据业务区分使用datetime/timestamp

datetime占用5个字节,timestamp占用4个字节

存储年使用year,存储日期使用date,存储时间使用datetime

必须把字段定义为NOT NULL并设默认值

NULL需要更多的存储空间

NULL的列使用索引,索引统计,值都更加复杂,MySQL更难优化

NULL只能采用IS NULL或者IS NOT NULL,而在=http://www.likecs.com/!=http://www.likecs.com/in/not in时有大坑

使用int unsigned存储IPv4,不要用char(15)

使用varchar(20)存储手机号,不要使用整数

手机号不会用来做数学运算

varchar可以模糊查询(eg:like ‘138%’)

牵扯到国家代号,可能出现+、-、()等字符,eg:+86

使用tinyint来代替enum

enum增加新值要进行DDL操作

5.索引规范(常用)

唯一索引使用uniq_字段名来命名

非唯一索引使用idx_字段名来命名

单张表索引数量建议控制在5个以内

互联网高并发业务,太多索引会影响写性能

异常复杂的查询需求,可以选择ES等更为适合的方式存储

生成执行计划时,如果索引太多,会降低性能,并可能导致MySQL选择不到最优索引

组合索引字段数不建议超过5个

如果5个字段还不能极大缩小row范围,八成是设计有问题

不建议在频繁更新的字段上建立索引

非必要不要进行join查询,如果要进行join查询,被join的字段必须类型相同,并建立索引

join字段类型不一致容易导致全表扫描

理解组合索引最左前缀原则,避免重复建设索引

如果建立了(a,b,c),相当于建立了(a), (a,b), (a,b,c)

6.SQL规范(常用)

禁止使用select *,只获取必要字段

指定字段能有效利用索引覆盖

select *会增加cpu/io/内存/带宽的消耗

指定字段查询,在表结构变更时,能保证对应用程序无影响

insert必须指定字段,禁止使用insert into T values()

指定字段插入,在表结构变更时,能保证对应用程序无影响

隐式类型转换会使索引失效,导致全表扫描(很重要)

禁止在where条件列使用函数或者表达式

导致不能命中索引,全表扫描

禁止负向查询以及%开头的模糊查询

导致不能命中索引,全表扫描

禁止大表join和子查询

同一个字段上的or必须改写为in,in的值必须少于50个

应用程序必须捕获SQL异常(方便定位线上问题)

课后思考:为什么select uid from user where phone=13811223344不能命中phone索引?

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/wpjdyw.html