我有算术溢出值插入一个查找表的行-ID设置为TINYINT数据类型的错误。 这是不是其中的唯一记录数超过255个值的情况。 这是一个有点不同寻常,在此设置的第一次测试没有出现。
下面的代码的量产版却只有66个独特的价值观,但它是可能的新值可以添加(缓慢,非常小的数字),随着时间的推移... 255个可用插槽应该是绰绰有余的这个寿命分析过程。
我最初的想法是,它可能是由于缓存计划承认分层源表中有超过255个值(有其实1028),和评估,这可能超过目标表的容量。 我已经测试然而,这是不正确的。
-- This table represents a small (tinyint) subset of unique primary values.
CREATE TABLE #tmp_ID10T_Test (
ID10T_Test_ID tinyint identity (1,1) not null,
ID10T_String varchar(255) not null
PRIMARY KEY CLUSTERED
(ID10T_String ASC)
WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = ON, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON)
) ON [PRIMARY]
-- This table represents a larger (smallint) set of non-unique source values, defined by a secondary key value (Value_Set).
CREATE TABLE #tmp_ID10T_Values (
ID10T_Value_ID smallint identity (1,1) not null,
ID10T_Value_Set tinyint not null,
ID10T_String varchar(255) not null
) ON [PRIMARY]
-- Create the initial dataset - 100 unique records; The insertion tests below illustrate that the INDEX is working
-- correctly on the primary key field for repetative values, however something is happening with the IDENTITY field...
DECLARE @ID10T tinyint
, @i tinyint -- A randomized value to determine which subset of printable ASCII characters will be used for the string.
, @String varchar(255)
SET @ID10T = 0
WHILE @ID10T < 100
BEGIN
SET @String = ''
WHILE LEN(@String) < (1+ROUND((254 * RAND(CHECKSUM(NEWID()))),0))
BEGIN
SELECT @i = (1 + ROUND((2 * RAND()),0)) -- Randomize which printable character subset is drawn from.
SELECT @String = @String + ISNULL(CASE WHEN @i = 1 THEN char(48 + ROUND(((57-48)* RAND(CHECKSUM(NEWID()))),0))
WHEN @i = 2 THEN char(65 + ROUND(((90-65) * RAND(CHECKSUM(NEWID()))),0))
WHEN @i = 3 THEN char(97 + ROUND(((122-97) * RAND(CHECKSUM(NEWID()))),0))
END,'-')
END
INSERT INTO #tmp_ID10T_Values (ID10T_Value_Set, ID10T_String)
SELECT 1, @String
SET @ID10T = @ID10T + 1
END
-- Demonstrate that IGNORE_DUP_KEY = ON works for primary key index on string-field
SELECT * FROM #tmp_ID10T_Values
-- Method 1 - Simple INSERT INTO: Expect Approx. (100 row(s) affected)
INSERT INTO #tmp_ID10T_Test (ID10T_String)
SELECT DISTINCT ID10T_String
FROM #tmp_ID10T_Values
GO
-- Method 2 - LEFT OUTER JOIN WHERE NULL to prevent dupes.
-- this is the test case to determine whether the procedure cache is mixing plans
INSERT INTO #tmp_ID10T_Test (ID10T_String)
SELECT DISTINCT T1.ID10T_String
FROM #tmp_ID10T_Values AS T1
LEFT OUTER JOIN #tmp_ID10T_Test AS t2
ON T1.ID10T_String = T2.ID10T_String
WHERE T2.ID10T_Test_ID IS NULL
GO
-- Repeat Method 1: Duplicate key was ignored (0 row(s) affected).
INSERT INTO #tmp_ID10T_Test (ID10T_String)
SELECT DISTINCT ID10T_String
FROM #tmp_ID10T_Values
GO
这似乎不是一个查询计划缓存的问题 - 我应该看到算术错误的方法1个复试,如果这是真的。
-- Repeat Method 1: Expected: Arithmetic overflow error converting IDENTITY to data type tinyint.
INSERT INTO #tmp_ID10T_Test (ID10T_String)
SELECT DISTINCT ID10T_String
FROM #tmp_ID10T_Values
GO
我特别好奇,为什么异常会被抛出。 我可以理解,在方法1中的所有100个独特的值进行测试......所以可以想象查询代理看到的200所记录的二次插入尝试之后潜在的; 我不明白为什么它会第三重复之后看300个记录的潜力 - 在第二次尝试导致了0行,以便顶多会有200个唯一值的潜力。
有人能解释这个吗?