仓酷云

 找回密码
 立即注册
搜索
热搜: 活动 交友 discuz
查看: 712|回复: 8
打印 上一主题 下一主题

[学习教程] MSSQL网站制作之SQL Server援用的各类工具的最年夜值

[复制链接]
因胸联盟 该用户已被删除
跳转到指定楼层
楼主
发表于 2015-1-16 22:22:38 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式

马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
对于update操作,event中依次记录旧行,新行的值。server|工具|最年夜值最年夜容量申明
新增信息-2001年9月

第一个表申明关于一切MicrosoftSQLServer2000版本都不异的最年夜容量。第二个和第三个表申明因SQLServer2000的版本和操纵体系的分歧而异的容量。
下表申明在MicrosoftSQLServer数据库中界说的,或在Transact-SQL语句中援用的各类工具的最年夜值(数目或巨细)。下表不包括MicrosoftSQLServer2000WindowsCE版。

最年夜值(数目或巨细)工具SQLServer7.0SQLServer2000批处置巨细65,536*收集数据包巨细165,536*收集数据包巨细1每一个排序字符串列的字节数8,0008,000每一个textntext、或image列的字节数2GB-22GB-2每一个GROUPBY、ORDERBY的字节数8,0608,060每一个索引中的字节数9009002每一个外键的字节数900900每一个主键的字节数900900每行字节数8,0608,060存储历程源文本中的字节数批处置巨细之较小者大概250MB批处置巨细之较小者大概250MB每一个数据表的会萃索引数11GROUPBY、ORDERBY中的列数只受每一个GROUPBY、ORDERBY子句的字节数限定只受每一个GROUPBY、ORDERBY子句的字节数限定GROUPBYWITHCUBE或WITHROLLUP语句中的列数或表达式数量10每一个索引的列数1616每一个外键的列数1616每一个主键的列数1616每一个基本数据表的列数1,0241,024每一个SELECT语句的列数4,0964,096每一个INSERT语句的列数1,0241,024每一个客户真个毗连个数已设置毗连的最年夜值已设置毗连的最年夜值数据库巨细1,048,516TB31,048,516TB3每一个SQLServer实例的数据库个数32,76732,767每一个数据库的文件组个数256256每一个数据库的文件个数32,76732,767文件巨细(数据)32TB32TB文件巨细(日记)4TB32TB每一个数据表的外键表援用253253标识符长度(以字符计)128128每台盘算机的实例数暂缺16包括SQL语句的字符串长度(批处置巨细)65,536*收集数据包巨细165,536*收集数据包巨细1每一个毗连的锁数每一个服务器的最年夜锁数每一个服务器的最年夜锁数每一个SQLServer实例的锁数2,147,483,647(静态)
SQLServer40%的内存(静态)2,147,483,647(静态)
SQLServer40%的内存(静态)嵌套存储历程层数3232嵌套子查询3232嵌套触发器层数3232每一个数据表的非会萃索引个数249249SQLServer实例中同时翻开的工具个数42,147,483,647(或可用内存)2,147,483,647(或可用内存)每一个数据库中的工具个数2,147,483,64742,147,483,6474每一个存储历程的参数个数1,0242,100每一个数据表的REFERENCE个数253253每一个数据表的行数受可用存储资本限定受可用存储资本限定每一个数据库的数据表个数受数据库中的工具个数限定4受数据库中的工具个数限定4每一个SELECT语句的数据表个数256256每一个数据表的触发器个数受数据库中的工具个数限定4受数据库中的工具个数限定4每一个数据表的UNIQUE索引个数或束缚个数249个非会萃索引和1个会萃索引249个非会萃索引和1个会萃索引

1收集数据包巨细是表格格局数据计划(TDS)数据包的巨细,该数据包用于使用程序和干系数据库引擎之间的通信。默许的数据包巨细为4KB,由networkpacketsize设置选项把持。
2在SQLServer2000中,任何键的最年夜字节数不克不及凌驾900。可使用可变长度的列来界说键,只需在这类列中不拔出数据凌驾900字节的行,其最年夜巨细就能够在900以上。有关更多信息,请拜见索引键的最年夜值。
3当利用SQLServer2000DesktopEngine或Microsoft数据引擎(MSDE)1.0时,数据库的巨细不克不及凌驾2GB。
4数据库工具包含一切的表、视图、存储历程、扩大存储历程、触发器、划定规矩、默许值及束缚。一个数据库中一切工具的总数不得凌驾2,147,483,647。
SQLServer2000版本撑持的最年夜处置器数

下表列出各SQLServer2000版本中的数据库引擎在对称多处置(SMP)盘算机上可以利用的最年夜处置器数。安装SQLServer盘算机的处置器数目能够年夜于该版本数据库引擎所请求的处置器数目,但数据库引擎利用的处置器数目不会年夜于下表中指定的数目。比方,能够在具有8个处置器的Windows2000AdvancedServer盘算机上安装SQLServer尺度版,但数据库引擎利用的处置器不会凌驾4个。



操纵体系

企业版

尺度版

团体版

开辟版

DesktopEngine

SQLServerCE企业评价版MicrosoftWindows2000DataCenter3242322暂缺32Windows2000AdvancedServer84282暂缺8Windows2000Server44242暂缺4Windows2000Professional暂缺暂缺222暂缺2MicrosoftWindowsNT?4.0Server企业版88282暂缺8WindowsNT4.0Server44242暂缺4WindowsNT4.0Workstation暂缺暂缺222暂缺2MicrosoftWindows98暂缺暂缺1利用DesktopEngine1暂缺暂缺MicrosoftWindowsCE暂缺暂缺暂缺暂缺暂缺1暂缺

SQLServer2000版本撑持的最年夜物理内存量

下表列出各SQLServer2000版中的数据引擎可以撑持的最年夜物理内存量或RAM。



操纵体系

企业版

尺度版

团体版

开辟版

DesktopEngine

SQLServerCE企业评价版Windows2000DataCenter64GB2GB2GB64GB2GB暂缺64GBWindows2000AdvancedServer8GB2GB2GB8GB2GB暂缺8GBWindows2000Server4GB2GB2GB4GB2GB暂缺4GBWindows2000Professional暂缺暂缺2GB2GB2GB暂缺2GBWindowsNT4.0Server企业版3GB2GB2GB3GB2GB暂缺3GBWindowsNT4.0Server2GB2GB2GB2GB2GB暂缺2GBWindowsNT4.0Workstation暂缺暂缺2GB2GB2GB暂缺2GB


刚安装好的MySql包含一个含空密码的root帐户和一个匿名帐户,这是很大的安全隐患,对于一些重要的应用我们应将安全性尽可能提高,在这里应把匿名帐户删除、root帐户设置密码
兰色精灵 该用户已被删除
沙发
发表于 2015-1-19 09:45:10 | 只看该作者
而SQLServer如果能像Oracle一样可以为登陆分配如:5%的cpu,10%的内存。就可以解决这个漏洞。
谁可相欹 该用户已被删除
板凳
发表于 2015-1-24 15:52:01 | 只看该作者
分区表是个亮点!从分区表也能看出微软要做大作强SQLServer的信心。资料很多,这里不详细说。但是重点了解的是:现在的SQLServer2005的表,都是默认为分区表的。因为它要支持滑动窗口的这个特性。这种特性对历史数据和实时数据的处理是很有帮助的。
再见西城 该用户已被删除
地板
发表于 2015-2-2 07:26:48 | 只看该作者
需要注意的一点,也是我使用过程中发现的一个问题。在建立function->schema->table后,如果在现有的分区表上建立没有显式声明的聚集索引时,分区表会自动变为非分区表。这一点很让我纳闷。
山那边是海 该用户已被删除
5#
发表于 2015-2-7 17:40:59 | 只看该作者
varchar(max)\\\\nvarchar(max)类型的引入大大的提高了编程的效率,可以使用字符串函数对CLOB类型进行操作,这是一个亮点。
只想知道 该用户已被删除
6#
发表于 2015-2-22 20:11:25 | 只看该作者
代替了原来VB式的错误判断。比Oracle高级不少。
爱飞 该用户已被删除
7#
发表于 2015-3-7 02:07:27 | 只看该作者
作了些试验,发现使用CLR的存储过程或函数在达到一定的阀值的时候,系统性能会呈指数级下滑!这是非常危险的!只使用几个可能没有问题,当一旦大规模使用会造成严重的系统性能问题!
金色的骷髅 该用户已被删除
8#
发表于 2015-3-14 08:56:58 | 只看该作者
学习SQL语言的话如果要学会去做网站就不是很难!但是要做数据库管理的话就有难度了!
乐观 该用户已被删除
9#
发表于 2015-3-21 01:56:14 | 只看该作者
可能有的朋友会抱怨集成的orderby,其实如果使用ranking函数,Orderby是少不了的。如果担心Orderby会影响效率,可以为orderby的字段建立聚集索引,查询计划会忽略orderby操作(因为本来就是排序的嘛)。
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

QQ|Archiver|手机版|仓酷云 鄂ICP备14007578号-2

GMT+8, 2024-12-23 05:03

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

快速回复 返回顶部 返回列表