日志表设计一例分析

关于关系表的设计归根结底有两个方面。
第一，就是完全按照范式理论去设计，一般来说达到第三范式就可以了，或者你可以划分的更细到达更上一层次。比如第四，第五，第六等等。这种设计有自己的可读性很强，但是有一点，在检索数据的时候增加了多张关系表来做关联的开销。
第二，就是在范式理论上适当的做些反范式，有的东西还是不要太剥离的好。（窄表以及宽表） 这点和软件设计中的紧耦合松耦合理论一致。

下面我就以常用的LOG表来做下演示，其中有两种表的实际，一种是窄表，一种是稍微宽一点的表。
窄表：log_ytt

mysql> show create table log_ytt;
+-------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Table       | Create Table                                                                                                                                                             |
+-------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| log_ytt | CREATE TABLE `log_ytt` (
  `ids` bigint(20) DEFAULT NULL,
  `log_time` datetime DEFAULT NULL,
  KEY `idx_u1` (`ids`,`log_time`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 |
+-------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)


表记录数

mysql>  select * from log_ytt where ids > ‘4875000001‘;                                                                                    +------------+---------------------+
| ids        | log_time            |
+------------+---------------------+
| 7110000001 | 2014-05-20 21:56:42 |
| 6300000001 | 2014-05-20 21:56:42 |
| 6750000001 | 2014-05-20 21:56:42 |
| 5310000001 | 2014-05-20 21:56:42 |
| 7200000001 | 2014-05-20 21:56:42 |
| 7380000001 | 2014-05-20 21:56:42 |
| 5760000001 | 2014-05-20 21:56:42 |
| 6930000001 | 2014-05-20 21:56:42 |
| 6660000001 | 2014-05-20 21:56:42 |
| 5670000001 | 2014-05-20 21:56:42 |
| 6210000001 | 2014-05-20 21:56:42 |
| 5850000001 | 2014-05-20 21:56:42 |
| 6570000001 | 2014-05-20 21:56:42 |
| 5580000001 | 2014-05-20 21:56:42 |
| 5130000001 | 2014-05-20 21:56:42 |
| 7290000001 | 2014-05-20 21:56:42 |
| 6390000001 | 2014-05-20 21:56:42 |
| 5490000001 | 2014-05-20 21:56:42 |
| 5220000001 | 2014-05-20 21:56:42 |
| 7560000001 | 2014-05-20 21:56:42 |
| 7470000001 | 2014-05-20 21:56:42 |
| 7020000001 | 2014-05-20 21:56:42 |
| 6840000001 | 2014-05-20 21:56:42 |
| 6030000001 | 2014-05-20 21:56:42 |
| 6480000001 | 2014-05-20 21:56:42 |
| 7650000001 | 2014-05-20 21:56:42 |
| 5940000001 | 2014-05-20 21:56:42 |
| 6120000001 | 2014-05-20 21:56:42 |
| 7740000001 | 2014-05-20 21:56:42 |
| 5400000001 | 2014-05-20 21:56:42 |
| 5760000001 | 2014-05-21 03:19:07 |
| 6840000001 | 2014-05-21 03:19:17 |
| 7020000001 | 2014-05-21 03:19:32 |
| 7200000001 | 2014-05-21 03:19:45 |
| 7110000001 | 2014-05-21 03:19:46 |
| 7380000001 | 2014-05-21 03:19:48 |
| 5670000001 | 2014-05-21 03:19:58 |
| 6930000001 | 2014-05-21 03:19:59 |
| 6030000001 | 2014-05-21 03:20:00 |
| 5940000001 | 2014-05-21 03:20:00 |
| 7290000001 | 2014-05-21 03:20:02 |
| 6120000001 | 2014-05-21 03:20:09 |
| 5850000001 | 2014-05-21 03:20:18 |
| 5580000001 | 2014-05-21 03:20:24 |
| 6480000001 | 2014-05-21 03:25:05 |
| 6390000001 | 2014-05-21 03:25:37 |
| 6210000001 | 2014-05-21 03:25:45 |
| 7470000001 | 2014-05-21 03:26:14 |
| 6750000001 | 2014-05-21 03:27:17 |
| 5310000001 | 2014-05-21 03:27:33 |
| 5130000001 | 2014-05-21 03:27:34 |
| 6570000001 | 2014-05-21 03:27:34 |
| 7560000001 | 2014-05-21 03:27:45 |
| 5220000001 | 2014-05-21 03:27:45 |
| 5400000001 | 2014-05-21 03:27:53 |
| 5490000001 | 2014-05-21 03:27:55 |
| 6660000001 | 2014-05-21 03:28:07 |
| 6300000001 | 2014-05-21 03:28:13 |
| 7740000001 | 2014-05-21 03:28:26 |
| 7650000001 | 2014-05-21 03:28:37 |
+------------+---------------------+
60 rows in set (0.00 sec)

接下来，我们要检索所有IDS的平均时间。 有以下两种方式：
第一， 对表进行了两次访问，并且有GROUP BY 操作，不可取。

mysql> select sec_to_time(avg(timestampdiff(second,a.times,b.times)))  as ‘running‘
    -> from
    -> (select ids,min(log_time) as times from log_ytt where 1 group by ids ) as a,
    -> (select ids,max(log_time) as times from log_ytt where 1 group by ids) as b where a.ids = b.ids;
+---------------+
| running       |
+---------------+
| 05:27:08.8333 |
+---------------+
1 row in set (0.00 sec)

第二，虽然对表进行了最少的访问，但是也有一次GROUP BY 操作。也没办法，表设计如此。

mysql> SELECT SEC_TO_TIME(AVG(times)) AS ‘Running‘ FROM
    -> (
    -> SELECT TIMESTAMPDIFF(SECOND,MIN(log_time),MAX(log_time)) AS times FROM log_ytt GROUP BY ids
    -> ) AS T;
+---------------+
| Running       |
+---------------+
| 05:27:08.8333 |
+---------------+
1 row in set (0.00 sec)

宽表：log_ytt_horizontal.

mysql> show create table log_ytt_horizontal;
+------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Table                  | Create Table                                                                                                                                                                                              |
+------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| log_ytt_horizontal | CREATE TABLE `log_ytt_horizontal` (
  `ids` bigint(20) NOT NULL,
  `start_time` datetime DEFAULT NULL,
  `end_time` datetime DEFAULT NULL,
  PRIMARY KEY (`ids`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 |
+------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)

表记录数：

mysql> select * from log_ytt_horizontal;
+------------+---------------------+---------------------+
| ids        | start_time          | end_time            |
+------------+---------------------+---------------------+
| 5130000001 | 2014-05-20 21:56:42 | 2014-05-21 03:27:34 |
| 5220000001 | 2014-05-20 21:56:42 | 2014-05-21 03:27:45 |
| 5310000001 | 2014-05-20 21:56:42 | 2014-05-21 03:27:33 |
| 5400000001 | 2014-05-20 21:56:42 | 2014-05-21 03:27:53 |
| 5490000001 | 2014-05-20 21:56:42 | 2014-05-21 03:27:55 |
| 5580000001 | 2014-05-20 21:56:42 | 2014-05-21 03:20:24 |
| 5670000001 | 2014-05-20 21:56:42 | 2014-05-21 03:19:58 |
| 5760000001 | 2014-05-20 21:56:42 | 2014-05-21 03:19:07 |
| 5850000001 | 2014-05-20 21:56:42 | 2014-05-21 03:20:18 |
| 5940000001 | 2014-05-20 21:56:42 | 2014-05-21 03:20:00 |
| 6030000001 | 2014-05-20 21:56:42 | 2014-05-21 03:20:00 |
| 6120000001 | 2014-05-20 21:56:42 | 2014-05-21 03:20:09 |
| 6210000001 | 2014-05-20 21:56:42 | 2014-05-21 03:25:45 |
| 6300000001 | 2014-05-20 21:56:42 | 2014-05-21 03:28:13 |
| 6390000001 | 2014-05-20 21:56:42 | 2014-05-21 03:25:37 |
| 6480000001 | 2014-05-20 21:56:42 | 2014-05-21 03:25:05 |
| 6570000001 | 2014-05-20 21:56:42 | 2014-05-21 03:27:34 |
| 6660000001 | 2014-05-20 21:56:42 | 2014-05-21 03:28:07 |
| 6750000001 | 2014-05-20 21:56:42 | 2014-05-21 03:27:17 |
| 6840000001 | 2014-05-20 21:56:42 | 2014-05-21 03:19:17 |
| 6930000001 | 2014-05-20 21:56:42 | 2014-05-21 03:19:59 |
| 7020000001 | 2014-05-20 21:56:42 | 2014-05-21 03:19:32 |
| 7110000001 | 2014-05-20 21:56:42 | 2014-05-21 03:19:46 |
| 7200000001 | 2014-05-20 21:56:42 | 2014-05-21 03:19:45 |
| 7290000001 | 2014-05-20 21:56:42 | 2014-05-21 03:20:02 |
| 7380000001 | 2014-05-20 21:56:42 | 2014-05-21 03:19:48 |
| 7470000001 | 2014-05-20 21:56:42 | 2014-05-21 03:26:14 |
| 7560000001 | 2014-05-20 21:56:42 | 2014-05-21 03:27:45 |
| 7650000001 | 2014-05-20 21:56:42 | 2014-05-21 03:28:37 |
| 7740000001 | 2014-05-20 21:56:42 | 2014-05-21 03:28:26 |
+------------+---------------------+---------------------+
30 rows in set (0.00 sec)

如果对这种稍微冗余一些的表来进行查询，那么对表的访问以及CPU的资源占用都达到了最低。

mysql> select sec_to_time(avg(timestampdiff(second,start_time,end_time))) as ‘Running‘  from log_ytt_horizontal;
+---------------+
| Running       |
+---------------+
| 05:27:08.8333 |
+---------------+
1 row in set (0.00 sec)

日志表设计一例分析,布布扣,bubuko.com

时间： 2024-12-21 21:03:00

日志表设计一例分析的相关文章

优化Oracle数据库表设计

绝大多数的Oracle数据库性能问题都是由于数据库设计不合理造成的,只有少部分问题根植于Database Buffer.Share Pool.Redo Log Buffer等内存模块配置不合理,I/O争用,CPU争用等DBA职责范围上.所以除非是面对一个业已完成不可变更的系统,否则我们不应过多地将关注点投向内存.I/O.CPU等性能调整项目上,而应关注数据库表本身的设计是否合理,库表设计的合理性才是程序性能的真正执牛耳者.合理的数据库设计需要考虑以下的方面: ·业务数据以何种方式表达.如一个员工

表设计的原则与方法分析：追求表价值的最大化

表设计的原则与方法分析:追求表价值的最大化 在对象关系映射的应用系统设计中,对象就是表.对象关系即表关系,脱离对象设计表是错误的.对象的存在或价值在于它与其他对象的关系(设计研究的就是怎样处理对象以及对象之间的关系),不与其他对象产生关系的对象,或者说不与其他表有关系的表是没有价值的,不应创建. 当需求确定開始对系统进行设计时,首先进行对象分析.每个对象应具有唯一性,即对象的属性和方法唯一,能够明白的代表现实世界中的一种对象,因此与该对象相应的表的字段也具备唯一性.即在其它表中不应有反复字段.

mysql中的索引原理与表设计

索引是有效使用数据库的基础,但你的数据量很小的时候,或许通过扫描整表来存取数据的性能还能接受,但当数据量极大时,当访问量极大时,就一定需要通过索引的辅助才能有效地存取数据.一般索引建立的好坏是性能好坏的成功关键. 1.InnoDb数据与索引存储细节 使用InnoDb作为数据引擎的Mysql和有聚集索引的SqlServer的数据存储结构有点类似,虽然在物理层面,他们都存储在Page上,但在逻辑上面,我们可以把数据分为三块:数据区域,索引区域,主键区域,他们通过主键的值作为关联,配合工作.默认配置下

LoadRunner性能测试样例分析

LR性能测试结果样例分析 测试结果分析 LoadRunner性能测试结果分析是个复杂的过程,通常可以从结果摘要.并发数.平均事务响应时间.每秒点击数.业务成功率.系统资源.网页细分图.Web服务器资源.数据库服务器资源等几个方面分析,如图1- 1所示.性能测试结果分析的一个重要的原则是以性能测试的需求指标为导向.我们回顾一下本次性能测试的目的,正如 所列的指标,本次测试的要求是验证在30分钟内完成2000次用户登录系统,然后进行考勤业务,最后退出,在业务操作过程中页面的响应时间不超过3秒,并且服

20170105数据库表设计知识点

20170105数据库表设计知识点 ------指导老师    星哥 1.PHP(MYSQL)擅长单表操作,不要做过多无谓的连接查询 2.表字段名不要使用大驼峰命名方式,最好采用下划线,命名要和团队习惯一致,通俗易懂. 3.表级.字段都要有注释 4.MyISAM 适合于一些需要大量查询的应用,但其对于有大量写操作并不是很好.甚至你只是需要update一个字段,整个表都会被锁起来,而别的进程,就算是读进程都无法操作直到读操作完成.另外,MyISAM 对于 SELECT COUNT(*) 这类的计算

mysql web数据库的设计归范-2表设计原则

[职责分离原则] 职责分离原则是指在设计的时候应当考虑到数据的产生,聚合使用等原则,每个系统干自己能干的事情,每个系统只干自己的事情.一个数据表应该放在哪个系统中,通常取决于几点: 1. 谁产生这个信息:通常情况下谁产生了这个数据应当对此数据负责:也就是考虑该数据的创建,发展,销毁等全生命周期的定义,并将这个定义维护起来提供给消费者作为消费原则: 2. 谁最经常使用这个信息:如果某个系统最经常使用这个数据,最经常去修改某个数据,也应该由该系统来负责保存维护该数据: 3. 遵守高内聚,低耦合的考虑

MyBatis架构设计及源代码分析系列(一):MyBatis架构

如果不太熟悉MyBatis使用的请先参见MyBatis官方文档,这对理解其架构设计和源码分析有很大好处. 一.概述 MyBatis并不是一个完整的ORM框架,其官方首页是这么介绍自己 The MyBatis data mapper framework makes it easier to use a relational database with object-oriented applications. MyBatis couples objects with stored procedur

信息系统实践手记5-CACHE设计一例

说明:信息系统实践手记系列是系笔者在平时研发中先后遇到的大小的问题,也许朴实和细微,但往往却是经常遇到的问题.笔者对其中比较典型的加以收集,描述,归纳和分享. 摘要:此文描述了笔者接触过的部分信息系统或平台之间的对接构型和情况,挂一漏万的总结分享之. 正文 系列随笔目录:信息系统实践手记 (http://www.cnblogs.com/taichu/p/5305603.html) 作者:太初 转载说明:请指明原作者,连接,及出处. 1.CACHE是啥? 最近一直在弄scala,Spark,Pyt

转：LR性能测试结果样例分析 测试结果分析

LoadRunner性能测试结果分析是个复杂的过程,通常可以从结果摘要.并发数.平均事务响应时间.每秒点击数.业务成功率.系统资源.网页细分图.Web服务器资源.数据库服务器资源等几个方面分析,如图1- 1所示.性能测试结果分析的一个重要的原则是以性能测试的需求指标为导向.我们回顾一下本次性能测试的目的,正如 所列的指标,本次测试的要求是验证在30分钟内完成2000次用户登录系统,然后进行考勤业务,最后退出,在业务操作过程中页面的响应时间不超过3秒,并且服务器的CPU使用率.内存使用率分别不超过