数据库查询优化(主从表的设计)

举一个例子,我现在有一些新闻信息,它包括这些字段;新闻ID,新闻Name,新闻ShortIntro,新闻Detail,新闻PublishTime。我现在要把它存放在数据库中,然后从数据库中将其取出来放在GridView中分页显示。

我现在就以一种我所见过的常见的思维方式来一步一步模拟这个实现过程。

第一步:建立新闻数据表。

在这一步,很多人都会直接建一张News表,里面包括了上面说的那些字段。

第二步:查询数据。

写一个方法,把News表中满足查询条件的数据取出来放在DataSet(DataTable)中,作为数据源。

第三步:绑定到GridView。

设置GridView的分页属性,将上面查询得到的数据源绑定到GridView,实现数据在GridView中的分页显示。

上面就是我们常见的做法了。

我的做法会是这样:

第一步:建立新闻数据主-从表。

我们在系统开发过程中会发现,其实在一条的完整的数据信息中,其实很多时候,很多列表项并不会用到。我们分析News信息,我们可以初步的把ID,Name,ShortIntro,PublishTime作为主要信息,我们将这些信息集中起来,新建一张表News(ID,Name,ShortIntro,PublishTime),另外一个字段Detail放在另一张从表中,新建一张表NewsDetail(ID,Detail,NewsID)。这样做有什么好处呢,首先我们降低了表的“重量”。我们将最重要,最常用的信息简化出来放在一个主表中,这样在使用过程中,我们只需要从这张住表中获取我们所需的数据就可以了,而不需要像第一种方法一样遍历所有字段,这减少了数据库查询的时间,提高了性能。主-从表建立的原则是,将最重要的,最常用的分离出来作为主表,将那些描述性的,内容庞大的作为从表。

第二步:编写适合的SQL语句。

我们应该为不同的功能实现编写适合的SQL语句。上面那种方法中,用一个方法查询出了所有的数据信息,这是满足所有场合的数据要求的。但是,我们并不需要这么多的数据内容,多余的数据内容耗费了我们大量的时间和空间。我们往往只需要其中的部分内容,比如说主要信息。这也印证了为什么我们上面要建立主-从表。我们在建立了主-从表之后,为满足各种场合,可以编写以下几种方法:GetNews(int? ID, string Name)//从主表中查询满足条件的数据,GetNewsDetail(int? ID, string Name)//从主表和从表中查询满足条件的数据。第一种方法提供了新闻主要信息,第二种方法提供了全面的信息,这两种方法基本上就能满足所有场景且不会带来过多的数据冗余。这里还要指出一点,有些人喜欢这么写GetNewsByID(int? ID ),GetNewsByName(string Name),这样写是很灵活,很有针对性,但是这样写完全没必要。

第三步:分页绑定。

上面那种方法是一次性取出所有数据给GridView,让控件自己去分页,这样做方便省事。但是会有几个问题:

(1)数据量大。因为是一次性取出所有满足条件的数据,所以数据量比较大,而这些数据是都需要放在内存中的,所以会影响系统性能。而且在初次载入时会有些卡,给人的感觉是系统加载不平顺。

(2)我们并不需要这么多数据。为什么我要这么说呢?研究用户的使用习惯我们会发现,用户大多数情况下并不会逐页的去浏览数据,用户关注的往往是前几页的前几条。所以取出来的数据很多时候并没有被用户查看。

所以在这里,使用分页查询的方式是更加合适的。每次只从数据库里面查询一页数据,这样系统负载小,页面载入平顺,而且完全能够满足用户的使用要求。有些人会问,你这样做不是会增加数据库IO次数,我想说的是,一次性获取大量冗余数据,并要承担冗余所带来的持久影响与这些比理论上增加的IO次数(用户并不会逐页查看,也就并不会产生那么多次分页查询)要小得多的访问相比,分页查询具有不可否定的优势。

(0)

相关推荐

  • MySQL查询优化:连接查询排序limit(join、order by、limit语句)介绍

    不知道有没有人碰到过这样恶心的问题:两张表连接查询并limit,SQL效率很高,但是加上order by以后,语句的执行时间变的巨长,效率巨低. 情况是这么一个情况:现在有两张表,team表和people表,每个people属于一个team,people中有个字段team_id. 下面给出建表语句: 复制代码 代码如下: create table t_team ( id int primary key, tname varchar(100) ); create table t_people (

  • MySQL查询优化--调整内部变量的详解

    MySQL是如此的开放,所以可轻松地进一步调整其缺省设置以获得更优的性能及稳定性.需要优化的一些关键变量如下: 改变索引缓冲区长度(key_buffer) 一般,该变量控制缓冲区的长度在处理索引表(读/写操作)时使用.MySQL使用手册指出该变量可以不断增加以确保索引表的最佳性能,并推荐使用与系统内存25%的大小作为该变量的值.这是MySQL十分重要的配置变量之一,如果你对优化和提高系统性能有兴趣,可以从改变 key_buffer_size变量的值开始. 改变表长(read_buffer_siz

  • mysql多表联合查询返回一张表的内容实现代码

    今天在使用mysql语句的时候老是报错,语句如下: Sql代码 复制代码 代码如下: SELECT sapcle FROM SellEnterpriseBaseInfor sebie,SellEnterpriseBaseInforVer sebive,SellApplyPermitChangeList sapcle WHERE 1=1 AND sebie.iVerID = sebive.id AND sapcle.iEnterpriseBaseInforID=sebive.id AND sapc

  • MySQL查询优化之索引的应用详解

    糟糕的SQL查询语句可对整个应用程序的运行产生严重的影响,其不仅消耗掉更多的数据库时间,且它将对其他应用组件产生影响. 如同其它学科,优化查询性能很大程度上决定于开发者的直觉.幸运的是,像MySQL这样的数据库自带有一些协助工具.本文简要讨论诸多工具之三种:使用索引,使用EXPLAIN分析查询以及调整MySQL的内部配置. MySQL允许对数据库表进行索引,以此能迅速查找记录,而无需一开始就扫描整个表,由此显著地加快查询速度.每个表最多可以做到16个索引,此外MySQL还支持多列索引及全文检索.

  • MySQL查询优化:连接查询排序浅谈

    情况是这么一个情况:现在有两张表,team表和people表,每个people属于一个team,people中有个字段team_id. 下面给出建表语句: 复制代码 代码如下: create table t_team(id int primary key,tname varchar(100)); create table t_people(id int primary key,pname varchar(100),team_id int,foreign key (team_id) referen

  • MySQL查询优化:用子查询代替非主键连接查询实例介绍

    一对多的两张表,一般是一张表的外键关联到另一个表的主键.但也有不一般的情况,也就是两个表并非通过其中一个表的主键关联. 例如: 复制代码 代码如下: create table t_team ( tid int primary key, tname varchar(100) ); create table t_people ( pid int primary key, pname varchar(100), team_name varchar(100) ); team表和people表是一对多的关

  • 详解Mysql多表联合查询效率分析及优化

    1. 多表连接类型 1. 笛卡尔积(交叉连接) 在MySQL中可以为CROSS JOIN或者省略CROSS即JOIN,或者使用','  如: SELECT * FROM table1 CROSS JOIN table2 SELECT * FROM table1 JOIN table2 SELECT * FROM table1,table2 由于其返回的结果为被连接的两个数据表的乘积,因此当有WHERE, ON或USING条件的时候一般不建议使用,因为当数据表项目太多的时候,会非常慢.一般使用LE

  • 浅谈MySQL中的子查询优化技巧

    mysql的子查询的优化一直不是很友好,一直有受业界批评比较多,也是我在sql优化中遇到过最多的问题之一,你可以点击这里 ,这里来获得一些信息,mysql在处理子查询的时候,会将子查询改写,通常情况下,我们希望由内到外,也就是先完成子查询的结果,然后在用子查询来驱动外查询的表,完成查询,但是恰恰相反,子查询不会先被执行:今天希望通过介绍一些实际的案例来加深对mysql子查询的理解: 案例:用户反馈数据库响应较慢,许多业务动更新被卡住:登录到数据库中观察,发现长时间执行的sql: | 10437

  • MSSQL Server 查询优化方法 整理

    1.没有索引或者没有用到索引(这是查询慢最常见的问题,是程序设计的缺陷) 2.I/O吞吐量小,形成了瓶颈效应. 3.没有 创建计算列导致查询不优化. 4.内存不足 5.网络速度慢 6.查询出的数据量过大(可以采用多次查询,其他的方法降低数据量) 7. 锁或者死锁(这也是查询慢最常见的问题,是程序设计的缺陷)sp_lock,sp_who,活动的用户查看,原因是读写竞争资源. 9.返回了不必 要的行和列 10.查询语句不好,没有优化 ●可以通过如下方法来优化查询 : 1. 把数据.日志.索引放到不同

  • 总结MySQL建表、查询优化的一些实用小技巧

    MySQL建表阶段是非常重要的一个环节,表结构的好坏.优劣直接影响着后续的管理维护,赶在明天上班前分享总结个人MySQL建表.MySQL查询优化积累的一些实用小技巧. 技巧一.数据表冗余记录添加时间与更新时间 我们用到的很多数据表大多情况下都会有表记录的"添加时间(add_time)",我建议大家再新增一个记录"更新时间(update_time)"字段,在我的工作里需要为市场部.运营部等建立各种报表,而很多报表里的数据都是需要到大记录表里去查询的,如果直接查询大表的

随机推荐