Inilah jawaban terbaik saya untuk menjawab pertanyaan awal:
Coba ini:
/* 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
Untuk mengujinya, coba yang berikut ini. Harap perhatikan penggunaan "PERSISTED" untuk kolom terhitung dan penggunaan [dbo.] ketika mengacu pada fungsi
/*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)
)
Anda sekarang seharusnya dapat menambahkan indeks pada kolom yang dihitung (tetapi lihat gotcha nanti)
CREATE INDEX IX_TestFloorDate ON [dbo].[TableTestFloorDate](TestFloorDate)
Masukkan beberapa data acak sebanyak yang Anda inginkan tetapi lebih banyak (1000+) lebih baik jika Anda ingin menguji rencana penggunaan/eksekusi indeks
INSERT INTO TableTestFloorDate (TestDate) VALUES( convert(datetime, RAND()*50000))
Dapatkan hasilnya
SELECT * FROM TableTestFloorDate WHERE TestFloorDate='2013-2-2'
Sekarang inilah GOTCHA... Indeks yang telah dibuat pada kolom terhitung tidak digunakan! Sebaliknya, bahkan ketika memilih data pada bidang TestFloorDate yang bertahan, SQLServer (atau setidaknya versi saya) lebih memilih indeks pada TestDate.
CREATE INDEX IX_TestFloorDate ON [dbo].[TableTestFloorDate](TestDate)
Saya cukup yakin (dari ingatan) bahwa indeks pada kolom yang dihitung dan dipertahankan bermanfaat dari perspektif kinerja - saya kira Anda hanya perlu mencoba/menguji untuk penggunaan spesifik Anda sendiri
(Semoga saya telah membantu!)
person
dunxz
schedule
24.07.2013