xml地图|网站地图|网站标签 [设为首页] [加入收藏]
server数据库压缩空间,有关站内信的数据库设计
分类:数据库

三范式

三范式定义(范式和反范式)

1NF:每个数据项都是最小单元,不可分割,确定行列之后只能对应一个数据。

2NF:每一个非主属性完全依赖于候选码(属性组的值能唯一的标识一个元组,但是其子集不可以)。

3NF:每一个非主属性既不传递依赖于,也不部分依赖于(主码=候选码为多个市,从中选出一个作为主码)。

BCNF主属性(候选码中的某一个属性)内部也不能部分或传递依赖于码。

4NF :没有多值依赖。

站内信:网站运营人员可以向单个(单发)或多个(群发)用户推送消息,站内信其实就是向数据库中插入一条条记录。

SQL server数据库,在手动删除或者自动删除数据后,查看数据库物理文件发现占用空间并没有释放,果断采用万能的重启。(反正是自己用的一个服务器,随便玩。如果不是只有自己用的服务器,还是建议让运维或者DBA来做)。

数据类型

MySQL数据类型-菜鸟教程 

MYSQL中数据类型介绍

整数: int(m)里的m是表示数据显示宽度,浮点数,定点数。

字符串:char(n)4.0 n 代表字节,5.0 n 代表字符 (UTF-8=3zj,GBK=2zj)

 char 固定的字符数,空格补上;检索速度快。

 varchar 字符数+1个字节(n<=255)或2个字节(n>255)

 text 字符数+2个字节;不能有默认值;索引要指定前多少个字符;文本方式存储

 blob 二进制方式存储

数据库设计:

message【站内信发件箱表】{每次运营人员发送一条站内信(无论是单发或是群发)就会在发件箱表中添加一条记录}

 图片 1

 表字段:ID、SendID、RecID、MessageID、Statue、DateTime

messagetext【站内信发件内容表】{每次运营人员发送站内信的内容就会保存到站内信发件内容表中}

图片 2

表字段:ID、Title、Message、PData

messageuserinfo【站内信接收箱表】{用户站内信收件箱}

图片 3

表字段:ID、SendID、RecID、MessageID、Statue、DateTime

 

服务器重启后发现还是没有释放空间,emmmmmm。。。。那就请教百度老师了。

存储引擎

各种存储引擎的区别与联系     (存储数据技术和策略,存储机制、索引技巧、锁定水平等)

数据库存储引擎     show table status 显示表的相关信息

InnoDB与MyISAM的比较(从5.7开始innodb存储引擎成为默认的存储引擎。)

 锁机制:行级锁,表级锁

 事务操作:事务安全,不支持

InnoDB (1)可靠性要求比较高,要求事务;(2)表更新和查询都相当的频繁,并且行锁定的机会比较大的情况。

 MySQL4.1之后每个表的数据和索引存储在一个文件里。

 InnoDB 采用了MVCC来支持高并发,并且实现了四个标准的隔离级别。其默认级别是REPEATABLE READ(可重复读) ,行级锁。

 自动灾难恢复。与其它存储引擎不同,InnoDB表能够自动从灾难中恢复。

 外键约束。MySQL支持外键的存储引擎只有InnoDB。

 支持自动增加列AUTO_INCREMENT属性。

MyIsam  (1)做很多count 的计算;(2)插入不频繁,查询非常频繁;(3)没有事务。

 表存储在两个文件中,数据文件(MYD)和索引文件(MYI)

 表级锁,读=共享锁,写=排它锁。

 适合选择密集型的表,插入密集型的表。

业务逻辑:在运营人员发送了一条站内信后,当用户再次登录时就会刷新历史站内信,而那些不活跃的用户就不会更新站内信。

场景:运营人员向某个(单发)或多个(群发)用户发送站内信

添加发件内容:向messagetext站内信发件内容表中添加一条内容记录 {这里先添加messagetext站内信发件内容表产生一条记录,后面message站内信发件箱表中才有MessageID可以关联}

添加发件人发件记录:向message站内信发件箱表中添加一条发送记录 {备注:如果是单发RecID则是指定用户的UserID,如果是群发RecID则是0。(0表示所有用户)}

用户登录时刷新与自己有关的站内信,并将数据添加到messageuserinfo站内信接收箱表

  1. 查询条件:【发件人不是自己】并且【收件人是自己或者收件人是所有人】并且【自己收件表中不存在的记录】

    select m.id from Message as m where (m.recid='所有人' or m.recid='自己的ID') and m.sendid!='自己的ID' and m.MessageID not in (select u.messageid from MessageUserInfo as u  where u.recid='自己的ID')
    

      

  2. 将相关的站内信消息添加到自己的收件表中,并标记未读。

    1.   将上面【查询条件】中查询出来的id信息用做查询message站内信发件箱表的条件

      select * from message  where id=上面的m.id
      

        

    2. 将获取到message站内信发件箱表数据添加到messageuserinfo站内信接收箱表

  3. 查询出自己的站内信记录

    select u.ID,u.RecID,m.Title,m.Message,u.Statue,m.PDate from messageuserinfo as u join messagetext as m on u.MessageID = m.ID where u.RecID='自己的ID'
    

      

     

网友的解答是,SQL server数据库不会自己压缩已经扩展的空间,如果需要压缩需要手动操作。

数据库ACID

数据库的ACID

数据库事务介绍

原子性(Atomicity)一个事务必须被视为一个不可分割的最小工作单元,整个事务中的所有操作要么全部提交成功,要么全部失败回滚,对于一个事务来说,不可能只执行其中的一部分操作。

一致性(Consistency)数据库总是从一个一致性的状态转换到另一个一致性的状态。

隔离性(Isolation)一个事务所做的修改在最终提交以前,对其他事务是不可见的。

持久性(Durability)一旦事务提交,则其所做的修改不会永久保存到数据库。

4 种隔离级别

MVVC的简单介绍

READ UNCOMMITTED(未提交读)脏读:事务中的修改,即使没有提交,对其他事务也都是可见的。

READ COMMITTED(提交读)不可重复读:事务从开始直到提交之前,所做的任何修改对其他事务都是不可见的。

REPEATABLE READ(可重复读):幻读:一个事务按相同的查询条件读取以前检索过的数据,其他事务插入了满足其查询条件的新数据。产生幻行。

SERIALIZABLE(可串行化) 强制事务串行执行

MVVC是个行级锁的变种,它在普通读情况下避免了加锁操作,自特定情况下加锁

压缩空间的方式有两种:1、数据库。2、文件。

Mysql死锁问题

Mysql悲观锁总结和实践

Mysql乐观锁总结和实践

SELECT ... LOCK IN SHARE MODE SELECT ... FOR UPDATE:(LOCK IN SHARE MODE 在有一方事务要Update 同一个表单时很容易造成死锁)

乐观锁:取锁失败,产生回溯时影响效率。

 取数据时认为其他线程不会对数据进行修改。

 更新时判断是否对数据进行修改,版本号机制或CAS操作。

悲观锁:每次取数据都会加锁。

innodb_lock_wait_timeout 等待锁超时回滚事务:  【超时法】

直观方法是在两个事务相互等待时,当一个等待时间超过设置的某一阀值时,对其中一个事务进行回滚,另一个事务就能继续执行。在innodb中,参数innodb_lock_wait_timeout用来设置超时时间。

wait-for graph算法来主动进行死锁检测:  【等待图法】

innodb还提供了wait-for graph算法来主动进行死锁检测,每当加锁请求无法立即满足需要并进入等待时,wait-for graph算法都会被触发。

在要收缩空间的数据库上右键--》任务--》收缩--》1、数据库,2文件(自己选择)。然后就等着吧。

索引

索引(存储引擎 快速找到记录的一种数据结构,索引的基本功能)

什么是B-Tree

MySQL索引背后的数据结构及算法原理

MySQL性能优化-慢查询分析、优化索引和配置

图片 4

本文由澳门新葡亰手机版发布于数据库,转载请注明出处:server数据库压缩空间,有关站内信的数据库设计

上一篇:MySQL高可用之MHA切换测试,ibdata1文件损坏时恢复 下一篇:没有了
猜你喜欢
热门排行
精彩图文