为SQLServer查找表使用tinyint而不是int值得麻烦吗？
技术问答
381 人阅读
|
0 人回复
|
2023-09-14
|
|
在SqlServer: s) T' A# ~! r3 i) g3 @. d
2005中设计查找表（枚举）时，如果您知道条目数永远不会变得很高，是否应该使用tinyint而不是int？我最关心的是性能，尤其是索引的效率。
W8 V. I3 b8 h! G7 q假设您有以下代表性表格：
" ^" Q& I2 Q0 h' o* x% uPerson
$ z4 i' t; U8 `* B2 G; T6 p: L+ \7 v* P------
2 N: R$ ^' f8 j, @& w8 m3 ?PersonId int (PK)& @* F; }1 \- Y
PersonTypeId tinyint (FK to PersonTypes)
& p: ]9 g7 s) Z3 h! X& }和% p1 {* D# m2 f+ T; x
PersonTypes
: G- B- Z. }3 y) H2 I5 C3 O& U+ Z3 d4 H [-----------
0 l2 u# d! q Y7 p9 [PersonTypeId tinyint
, L3 t9 t& m2 ~3 ^! g8 J- ePersonTypeName varchar(50)
, I8 m/ v3 Q* ?9 i显而易见的因素是数据大小和编码麻烦。当我们在人员表中获得1亿行时，我们使用tinyint而不是int来存储3亿个字节，再加上索引占用的空间。不是大量的数据，但如果将设计决策应用于数十个大表，则非常重要。当然，编码方面的麻烦来自ASP.NET
3 ]. w" d3 ]* rC＃/ VB代码中的所有转换问题。, }) s; f6 J! B5 N$ P
如果我们撇开这两个问题，还有什么要考虑的？索引页的减少会减少查询的效率吗？还是发生某种填充会否定利益的填充？还有其他陷阱吗？, L) y2 _. S' M8 J# s) f, s! v1 G
我一直只是个人使用ints，但我正在考虑tinyint即将在一些大桌子上进行重新设计/迁移工作，因此，我很乐意寻求一些建议。
# }0 @8 M9 d( v2 m; ~[编辑]
8 F* L7 t. ~) E$ ~3 P2 |2 I在对此进行了试验之后，我预料到的编码麻烦是没有问题的。从int更改为tinyint根本不会导致任何转换问题。+ a$ W# v0 \% c% Y4 g Y
' q% x/ `& g5 Y. l+ _4 p
解决方案:2 b8 T- ~; m8 e0 |' x
+ O- L/ x- ?3 ~
: Q3 G+ W+ d2 u- J; ]% p; a5 I
, ]6 I" Y2 |4 z% Z; c& s 表（或索引节点条目）越窄，单个IO页上可容纳的记录（或索引节点）越多，任何查询所需的物理（和逻辑）读取IO操作越少。同样，在单个页面上的索引节点越多，从根到叶的索引中索引的级别可能越少，如果通过使表变窄，则通过了可以使索引小一级的阈值，这对性能有很大的影响。
+ m/ [3 G9 u8 w6 f如果通过切换到TinyInt将表从200字节宽更改为197字节宽，这可能不会有任何区别…但是，如果将表从20字节更改为14，（例如，其中有2个int），那可能是戏剧性的… |
|
|
|
|
|
|
|
|
|
