数据库数据优化故事多
基础调用评教系统接口,在运行程序时 我们看到IIS的进程居高不下。
于是想了几个方法进行数据库的而优化尝试。
第一 加索引。
索引是对数据库表中一列或多列的值进行排序的一种结构,使用索引可快速访问数据库表中的特定信息。索引对于数据库来说 就像目录和整本书的关系一样。有了数据库索引,我们就可以先查找目录,然后快速的找到我们想要查询的字段。如果想按特定学生的姓来查找他或她,则与在表中搜索所有的行相比,索引有助于更快地获取信息。
优点:
创建索引可以大大提高系统的性能。第一,通过创建唯一性索引,可以保证数据库表中每一行数据的唯一性。第二,可以大大加快数据的检索速度,这也是创建索引的最主要的原因。第三,可以加速表和表之间的连接,特别是在实现数据的参考完整性方面特别有意义。第四,在使用分组和排序子句进行数据检索时,同样可以显著减少查询中分组和排序的时间。
当然,它也有不利的一面就是要注意的是,建立太多的索引将会影响更新和插入的速度,因为它需要同样更新每个所以索引文件。
有了上面一些基础的理论,我们开始改革。由于上课班学生的数据量将会特别大,超过50多万条数据。再加索引时有几个基本的原则就是
1加在经常搜索的字段上面,因为索引已经排序,这样查询可以利用索引的排序,加快排序查询时间;
2加在需要按某字段排序的上面
3不加在值特别少的字段上面。例如 性别只有男女两个值。
好在数据导入之前我们就将索引加上了。再讲50万数据导入之后,再视图加索引时,就提示操作超时。。
第二 建立视图
这两天操作数据库,对表连接有了更深的理解。之前也写过一篇建立视图的博客,欢迎大家移步瞅一眼再回来。3.0优化查询-引入视图
它没有实际的物理纪录也特别适合于多表连接浏览是使用。像我们表中,我们需要查询一个学生上的所有课程,类型和任课老师的姓名。我们需要根据学生去班级表中查询班级ID,再根据班级ID 去上课班和行政班表中查询对应的上课班ID,有了上课班ID之后可以根据它去查询上课的老师ID,然后根据上课的老师ID 去查询老师表里面去查询老师的姓名。继续根据上课班ID去查询课程ID,然后再去课程表里面去查询课程的ID和名称。最后,根据课程的ID查到课程类型ID之后去 课程类型表中查询到课程的类型名称。
如此一个查询结果才显示出来。轻巧的是,用了视图之后呢。所有的信息都在一个表中。直接查询想要的字段。
只不过,在这里考虑到如果我们将所有的学生的所有的课程放在一个视图里面,一个学期的数据量基本在30000*10以上。于是我们想到一个折中的办法就是,一个视图表中存储该学生所在的班级中公共上的课。这样就将原本50多条学生数据 缩小到一条班级数据。虽然多了一层需要根据学号去查询班级信息,但是也减少了查询时间。
以上两个优化是我们真正在这次的系统中操作和实践的。关于数据库的优化还有很多。
例如应用存储过程。说到这,我们做了一个实验,再有50万数据的时候,写了一条低效率的查询语句。
如下select * from dbo.BasicTeacherEntities where TeacherID not in (select teacherID from dbo.BasicOnClassEntities where OnClassID not in
(select OnClassID from BasicOnClassStudentEntities where StudentID =‘193a83fc-558e-490c-b51f-04365a74a3be‘))
结果它第一次查询时用了11s,但是奇怪的是,当我第二次查询时仅用了不到1s.换一个StudentID也一样的不用等。
是不是和存储过程原理是一样滴?有待考究。
此外还有两点正在研究中。数据库的分表和数据字典前端缓存。博客会及时更新。
郑重声明:本站内容如果来自互联网及其他传播媒体,其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。