mysql配置-日志大小限制和自动删除

线上的项目磁盘消耗问题, 发现和MySQL日志有关系.

需要处理的问题

  • 如何限制大小 不让日志无限膨胀?
  • 配置日志不留?
  • 删除的方式和直接删除会对服务有什么影响?

解决方式

限制大小, 保留最近一段时间日志.

  1. set global expire_logs_days=7; # 命令行进入MySQL中, 临时设置保留最近7天日志文件.
  2. expire_logs_days = 7 # 打开 my.cnf 配置文件写入配置, 上面是临时设置的 重启后需要这个文件也要配置下.
  3. max_binlog_size = 100M # 打开 my.cnf 配置文件写入配置, 配置二进制日志每一文件的大小限制为100M.

当修改配置并重启后, 二进制超出配置的部分会被删除, 如果需要之前的日志文件, 注意先备份出来.

上面配置置参考[资料1]

继续阅读

分库分表

文章整理于网上内容, 更多详细内容参考底部[相关资料]

水平分表、垂直分表、水平分库分表、垂直分库

为什么要分库分表? 需要解决什么问题?

业务量高速增长后, 之前的数据表数据读写开始不适应, 响应系统效率及用户体验. 解决I/O问题.

垂直分表

通俗讲”大表拆小表”, 拆表便于开发和维护但是改写以前的查询语句, 会额外带来一定的成本和风险. 拆分字段的操作建议在数据库设计阶段做好.

垂直分库

垂直分库在”微服务”非常普及了, 按照业务模块划分出不同的数据库, 而不是所有的表都放在同一个数据库中.

水平分表

水平分表也叫横向分表, 将表中不同的数据行按照一定规律分布到不同的数据库表中, 降低单表数量, 优化查询性能. 常见方式通过主键或时间等字段进行Hash和取模后拆分. 分表后还是在同一个数据库中还是会有I/O瓶顶.

水平分库分表

思路和水平分表一样, 不同的是分的表在不同的数据库中, 很多大型互联网公司选择的做法.

跨库Join问题

全局表: 类似”数据字典”, 每个库都保留一份.

字段冗余: 需要关联查询的字段做冗余(空间换时间), 避免join.

数据同步: ETLI工具实施

系统层组装: 详见[分库分表的几种常见形式以及可能遇到的难]

跨库事务问题

以往在代码中通过spring注解简单配置就能实现事务的, 现在则需要花很大的成本去保证一致性.

相关资料

分库分表的几种常见形式以及可能遇到的难
大众点评订单系统分库分表实践

转-Centos 7 mysql 5.5 启用innodb引擎

  1. show engines; 可以发现, 有innodb 字段, 但是support 为 no, 表明需要配置一下 my.cnf 才能使他支持 innodb。
  2. service mysql stop 关闭服务
  3. vi /etc/my.cnf 修改数据库配置文件
  4. chmod -R 775 /usr/local/mysql/data 给予mysql用户有写入权限
  5. service mysql start 启动服务
  6. show engines;


转-Centos 7 mysql 5.5 启用innodb引擎
讨论-MySQL 将 MyISAM 转为 InnoDB 对数据会有什么影响么

MySQL多次select还是一次join

数据量偏大的话, 直接join,一下就卡死了。用from子查询 去限制 join的次数,因为是分页的,其实不用join全表,被join的那张表,往往也是不需要 join那么多数据,降低了join的次数(left join子查询),你join两张也好,四张也好,表里面几十万数据也好,都不会卡了, 订单表,只需要join 成功的订单,不需要对比 不成本的订单,要限制join的次数 或者有时候咱们只需要join 分页的十条数据. by-坑货亲测 – 2018年3月21日16:24:04


实验-四表关联查询-需要爬1万 10万 100万 数据对比.

相关资料

SQL 使用 Join 好还是多次 Select 好?

char与varchar

对于char与vafchar停留于一个定长和变长的概念中, 且还以为varchar是可自动变长.


如何可以查看到存储后值的长度?

varchar

可变长:指定长度后可系统自动计算存入的长度, 字符存入的长度不能超过指定的长度. eg: nickname varchar(5) 值1: abc 那么此时长度为3 值2:abcefg 超出部分g是无法存入的.
长度上加1字符: 每个值只占用刚好够用的字节再加上一个用来记录其长度的字节(即总长度为L+1字节)

  • 大于varchar(255)变为 tinytext
  • 大于varchar(500)变为 text
  • 大于varchar(20000)变为 mediumtext

char

定长: 定好字段长度后不管存入的字符多少占用的长度都是一样的. eg: nickname char(3) 值1: ac 占用长度为3 值2: abc 占用长度为3

差异与共同点

  • char(n)和varchar(n)中括号中n代表字符的个数,并不代表字节个数,所以当使用了中文的时候(UTF8)意味着可以插入m个中文,但是实际会占用m*3个字节
  • char的上限为255字节,varchar的上限65535字节,text的上限为65535
  • char在存储的时候会截断尾部的空格,varchar和text不会
  • varchar会使用1-3个字节来存储长度,text不会
  • char效率比varchar高
  • varchar比char节省空间-但不节省内存

查阅资料

MySQL之char、varchar和text的设计 文章写很清晰有各个属性占用字符长度的表格及分析了varchar与text性能与空间对比
mysql中char与varchar的区别分析 有关于存储引擎的建议
MySQL中varchar与char类型区别 提及到4.1与5.0之后版本对空格处理的不同, 关于内存使用情况 有对空格处理情况重现的实例
数据库字段类型中char和Varchar区别 一篇比较久远的文章, 提到了 varchar2 及 ASCII 占用大小

[转]数据库外键

外键是否采用看业务应用场景,以及开发成本的,大致列下什么时候适合,什么时候不适合使用:

  1. 互联网行业应用不推荐使用外键: 用户量大,并发度高,为此数据库服务器很容易成为性能瓶颈,尤其受IO能力限制,且不能轻易地水平扩展;若是把数据一致性的控制放到事务中,也即让应用服务器承担此部分的压力,而引用服务器一般都是可以做到轻松地水平的伸缩;

2.传统行业
1>.软件应用的人数有限,换句话说是可控的;
2>.数据库服务器的数据量也一般不会超大,且活跃数据有限;

综合上述2句话描述,也即数据库服务器的性能不是问题,所以不用过多考虑性能的问题;另外,使用外键可以降低开发成本,借助数据库产品自身的触发器可以实现表与关联表之间的数据一致性和更新;
最后一点,使用外键的方式,还可以做到开发人员和数据库设计人员的分工,可以为程序员承担更多的工作量;

为何说外键有性能问题:
1.数据库需要维护外键的内部管理;
2.外键等于把数据的一致性事务实现,全部交给数据库服务器完成;
3.有了外键,当做一些涉及外键字段的增,删,更新操作之后,需要触发相关操作去检查,而不得不消耗资源;
4.外键还会因为需要请求对其他表内部加锁而容易出现死锁情况;

数据库的诸多设计,帐号,权限,约束,触发器,都是为 C/S 结构设计的,是以 C 端不可信做为假设前提的。B/S 模式安全边界前移到 web 服务层,应用与数据库之间是可信的,应用自行完成这些功能更加灵活。所以能不用就不用。

以上内容转自知乎-大家设计数据库时使用外键吗