主键的SQL Server BIGINT或DECIMAL(18,0)
我们有一个SQL Server 2005数据库,我们想要提高批量删除/插入/选择的性能,我注意到它的主键使用十进制(18,0).我知道这将给我们提供比bigint更多的价值,但希望它可能是一个快速的胜利,并且应该通过我的计算让我们持续数百万年的增长. 我在.net docs小数中看到16个字节而不是long需要的8个字节,但在SQL Server中它看起来像bigint take 8 bytes但小数(18,0)仅占用5 bytes – 如同选择DATALENGTH(max(id)所见)从表.它是否正确? 有没有其他原因bigint可能会更慢或我应该坚持十进制(18,0)? 解决方法在计算字节数之前,DATALENGTH会转换为varchar.所以你的最大值是< 100000. 用这个可以证明9个字节. sys.columns有一个max_length列(十进制是固定长度所以它总是9个字节,在你另外要求之前)CREATE TABLE dbo.foo (bar decimal(18,0)) GO SELECT * FROM sys.columns WHERE object_id = OBJECT_ID('foo') GO DROP TABLE dbo.foo GO 由于遗留原因,在使用SQL Server 2000添加bigint之前,十进制(18,0)通常用作“64位整数”的代理. 十进制(18,0)和bigint在范围内大致相同:根据文档,十进制是9字节多一个字节 最重要的是,普通整数将比小数快一些(可能不可测量).如果说,如果预计明年或5年将有超过40亿行,那么表现应该很重要.如果没有,那么只需使用int (编辑:西安站长网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |
- 硕泰克K8主板驾到,64位元时代就从今天开始!
- HP台式电脑新品面世:政府教育类PC需求凸显
- sql-server – 如何在DST之前或之后的日期获得UTC与本地时间
- sql – pgAdmin III错误行为?
- sql-server-2008 – 如何使用SQL Server DDL进行事务处理?
- SQL Server:只有GROUP BY中的最后一个条目
- 利用CodeWeavers软件包 Linux上可跑Office XP
- 实体框架 – 具有Identity列的SQL Server Compact 4.0表中插
- sql-server – 未记录的CONVERT样式 – datetime 23
- 无线路由器ARP攻击故障排除方法