นี่คือคำตอบที่ดีที่สุดของฉันในการตอบคำถามเดิม:
ลองสิ่งนี้:
/* create a deterministic schema bound function */
CREATE FUNCTION FloorDate(@dt datetime)
RETURNS datetime
WITH SCHEMABINDING
AS
BEGIN
RETURN CONVERT(datetime, FLOOR(CONVERT(float, @dt)))
END
GO
หากต้องการทดสอบ ให้ลองทำดังนี้ โปรดสังเกตการใช้ "PERSISTED" สำหรับคอลัมน์จากการคำนวณและการใช้ [dbo.] เมื่ออ้างถึงฟังก์ชัน
/*create a test table */
CREATE TABLE [dbo].[TableTestFloorDate](
[Id] [int] IDENTITY(1,1) NOT NULL,
[TestDate] [datetime] NOT NULL,
[TestFloorDate] AS ([dbo].[FloorDate]([TestDate])) PERSISTED,
CONSTRAINT [PK_TableTestFloorDate] PRIMARY KEY CLUSTERED
(
[Id] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON)
)
ตอนนี้คุณควรจะสามารถเพิ่มดัชนีในคอลัมน์ที่คำนวณได้ (แต่ดู gotcha ในภายหลัง)
CREATE INDEX IX_TestFloorDate ON [dbo].[TableTestFloorDate](TestFloorDate)
แทรกข้อมูลสุ่มหลาย ๆ ครั้งตามที่คุณต้องการ แต่มากกว่า (1,000+) จะดีกว่าหากคุณต้องการทดสอบแผนการใช้งาน / การดำเนินการดัชนี
INSERT INTO TableTestFloorDate (TestDate) VALUES( convert(datetime, RAND()*50000))
รับผลลัพธ์
SELECT * FROM TableTestFloorDate WHERE TestFloorDate='2013-2-2'
นี่คือ GOTCHA... ไม่ได้ใช้ดัชนีที่สร้างขึ้นในคอลัมน์จากการคำนวณ! แม้ว่าเมื่อเลือกข้อมูลในฟิลด์ TestFloorDate ที่มีอยู่แล้ว SQLServer (หรืออย่างน้อยเวอร์ชันของฉัน) ก็ชอบดัชนีบน TestDate
CREATE INDEX IX_TestFloorDate ON [dbo].[TableTestFloorDate](TestDate)
ฉันค่อนข้างแน่ใจว่า (จากหน่วยความจำ) ว่าการจัดทำดัชนีในคอลัมน์ที่คำนวณและคงอยู่นั้นมีประโยชน์จากมุมมองของประสิทธิภาพ - ฉันเดาว่าคุณจะต้องลอง / ทดสอบสำหรับการใช้งานเฉพาะของคุณเอง
(หวังว่าฉันได้ช่วย!)
person
dunxz
schedule
24.07.2013