没有合适的资源?快使用搜索试试~ 我知道了~
资源推荐
资源详情
资源评论
大数据量高并发的数据库优化
文章分类:Java
编程
Java 代码
1.
2. 大数据量高并发的数据库优化
3. 一、数据库结构的设计
4.
5. 如果不能设计一个合理的数据库模型,不仅会增加客户端和服务器段
程序的编程和维护的难度,而且将会影响系统实际运行的性能。所以,
在一个系统开始实施之前,完备的数据库模型的设计是必须的。
6.
7. 在一个系统分析、设计阶段,因为数据量较小,负荷较低。我们往往
只注意到功能的实现,而很难注意到性能的薄弱之处,等到系统投入实
际运行一段时间后,才发现系统的性能在降低,这时再来考虑提高系统
性能则要花费更多的人力物力,而整个系统也不可避免的形成了一个打
补丁工程。
8.
9. 所以在考虑整个系统的流程的时候,我们必须要考虑,在高并发大数
据量的访问情况下,我们的系统会不会出现极端的情况。(例如:对外
统计系统在 7 月 16 日出现的数据异常的情况,并发大数据量的的访问
造成,数据库的响应时间不能跟上数据刷新的速度造成。具体情况是:
在日期临界时(00:00:00),判断数据库中是否有当前日期的记录,
没有则插入一条当前日期的记录。在低并发访问的情况下,不会发生问
题,但是当日期临界时的访问量相当大的时候,在做这一判断的时候,
会出现多次条件成立,则数据库里会被插入多条当前日期的记录,从而
造成数据错误。),数据库的模型确定下来之后,我们有必要做一个系
统内数据流向图,分析可能出现的瓶颈。
10.
11. 为了保证数据库的一致性和完整性,在逻辑设计的时候往往会设计
过多的表间关联,尽可能的降低数据的冗余。(例如用户表的地区,我
们可以把地区另外存放到一个地区表中)如果数据冗余低,数据的完整
性容易得到保证,提高了数据吞吐速度,保证了数据的完整性,清楚地
表达数据元素之间的关系。而对于多表之间的关联查询(尤其是大数据
表)时,其性能将会降低,同时也提高了客户端程序的编程难度,因此,
物理设计需折衷考虑,根据业务规则,确定对关联表的数据量大小、数
据项的访问频度,对此类数据表频繁的关联查询应适当提高数据冗余设
计但增加了表间连接查询的操作,也使得程序的变得复杂,为了提高系
统的响应时间,合理的数据冗余也是必要的。设计人员在设计阶段应根
据系统操作的类型、频度加以均衡考虑。
12. 另外,最好不要用自增属性字段作为主键与子表关联。不便于系统的
迁移和数据恢复。对外统计系统映射关系丢失(******************)。
13.
14. 原来的表格必须可以通过由它分离出去的表格重新构建。使用这个
规定的好处是,你可以确保不会在分离的表格中引入多余的列,所有你
创建的表格结构都与它们的实际需要一样大。应用这条规定是一个好习
惯,不过除非你要处理一个非常大型的数据,否则你将不需要用到它。
(例如一个通行证系统,我可以将
USERID,USERNAME,USERPASSWORD,单独出来作个表,再把
USERID 作为其他表的外键)
15.
16. 表的设计具体注意的问题:
17.
18. 1、数据行的长度不要超过 8020 字节,如果超过这个长度的话在物
理页中这条数据会占用两行从而造成存储碎片,降低查询效率。
19. 2、能够用数字类型的字段尽量选择数字类型而不用字符串类型的
(电话号码),这会降低查询和连接的性能,并会增加存储开销。这是
因为引擎在处理查询和连接回逐个比较字符串中每一个字符,而对于数
字型而言只需要比较一次就够了。
20.
21. 3、对于不可变字符类型 char 和可变字符类型 varchar都是 8000
字节,char 查询快,但是耗存储空间,varchar 查询相对慢一些但是节
省存储空间。在设计字段的时候可以灵活选择,例如用户名、密码等长
度变化不大的字段可以选择 CHAR,对于评论等长度变化大的字段可以
选择 VARCHAR。
22.
23. 4、字段的长度在最大限度的满足可能的需要的前提下,应该尽可能
的设得短一些,这样可以提高查询的效率,而且在建立索引的时候也可
以减少资源的消耗。
24.
25.
26. 二、查询的优化
27.
28. 保证在实现功能的基础上,尽量减少对数据库的访问次数;通过搜索参
数,尽量减少对表的访问行数,最小化结果集,从而减轻网络负担;能够
分开的操作尽量分开处理,提高每次的响应速度;在数据窗口使用 SQL
时,尽量把使用的索引放在选择的首列;算法的结构尽量简单;在查询
时,不要过多地使用通配符如 SELECT*FROMT1 语句,要用到几列
就选择几列如:SELECTCOL1,COL2FROMT1;在可能的情况下尽量
限制尽量结果集行数如:SELECTTOP300COL1,COL2,COL3FROM
T1,因为某些情况下用户是不需要那么多的数据的。
29. 在没有建索引的情况下,数据库查找某一条数据,就必须进行全表扫描
了,对所有数据进行一次遍历,查找出符合条件的记录。在数据量比较
小的情况下,也许看不出明显的差别,但是当数据量大的情况下,这种
情况就是极为糟糕的了。
30. SQL 语句在 SQLSERVER 中是如何执行的,他们担心自己所写的 SQL
语句会被 SQLSERVER 误解。比如:
31. select*fromtable1wherename='zhangsan'andtID>1000
0
32. 和执行:
33. select*fromtable1wheretID>10000andname='zhangsan
'
34. 一些人不知道以上两条语句的执行效率是否一样,因为如果简单的从语
句先后上看,这两个语句的确是不一样,如果 tID 是一个聚合索引,那
么后一句仅仅从表的 10000 条以后的记录中查找就行了;而前一句则要
先从全表中查找看有几个 name='zhangsan'的,而后再根据限制条件
条件 tID>10000 来提出查询结果。
35. 事实上,这样的担心是不必要的。SQLSERVER 中有一个“查询分析优
化器”,它可以计算出 where 子句中的搜索条件并确定哪个索引能缩小
表扫描的搜索空间,也就是说,它能实现自动优化。虽然查询优化器可
以根据 where 子句自动的进行查询优化,但有时查询优化器就会不按照
您的本意进行快速查询。
36. 在查询分析阶段,查询优化器查看查询的每个阶段并决定限制需要扫描
的数据量是否有用。如果一个阶段可以被用作一个扫描参数
(SARG),那么就称之为可优化的,并且可以利用索引快速获得所需
数据。
37. SARG 的定义:用于限制搜索的一个操作,因为它通常是指一个特定的
匹配,一个值的范围内的匹配或者两个以上条件的 AND 连接。形式如下:
38. 列名 操作符 <常数 或 变量>或 <常数 或 变量>操作符 列名
39. 列名可以出现在操作符的一边,而常数或变量出现在操作符的另一边。
如:
40. Name=’张三’
41. 价格>5000
42. 5000<价格
43. Name=’张三’ and价格>5000
44. 如果一个表达式不能满足 SARG 的形式,那它就无法限制搜索的范围
了,也就是 SQLSERVER 必须对每一行都判断它是否满足 WHERE 子
句中的所有条件。所以一个索引对于不满足 SARG 形式的表达式来说是
无用的。
45. 所以,优化查询最重要的就是,尽量使语句符合查询优化器的规则
避免全表扫描而使用索引查询。
46.
47. 具体要注意的:
48.
49. 1.应尽量避免在 where子句中对字段进行 null值判断,否则将导致引
擎放弃使用索引而进行全表扫描,如:
50. selectidfromtwherenumisnull
剩余12页未读,继续阅读
资源评论
老帽爬新坡
- 粉丝: 79
- 资源: 2万+
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功