Rollback » index

Indexek, amiket a kutya sem használ

Erik — Sun, 18 Oct 2009 14:36:04 +0000

(apró technikai malőr miatt a táblázat pillanatnyilag bebújik a sidebar mögé, bocs, legjobb embereink dolgoznak a hiba elhárításán)

Az egyik nagy jósága a SQL 2005+ szervernek, hogy megmutatja az indexek ki(nem)használtságát, illetve elmondja, hogy milyen jelenleg nemlétező index mekkora hasznot hozna. Ezeket természetesen DMV-ken keresztül teszi meg velünk.

Az indexeink kihasználtságát a sys.dm_db_index_usage_stats DMV mutatja meg, egy kis minta így néz ki belőle:

SELECT top 3 * FROM sys.dm_db_index_usage_stats
WHERE object_id > 255

Az erősen irányított válasz pedig

database_id	object_id	index_id	user_seeks	user_scans	user_lookups	user_updates	last_user_seek	last_user_scan	last_user_lookup	last_user_update	system_scans	last_system_seek	last_system_scan	last_system_lookup	last_system_update
5	709577566	2	3	3456	0	2154356	NULL	2009.10.18 15:46	NULL	2009-10-18 16:00:37.097	34	NULL	2009-10-18 01:00:23.000	NULL	NULL
5	709577566	1	2154356	0	2154356	2154356	2009-10-18 16:00:37.097	NULL	2009-10-18 16:00:37.097	2009-10-18 16:00:37.097	34	NULL	2009-10-18 01:00:23.000	NULL	NULL
5	709577566	3	0	0	0	2154356	NULL	NULL	NULL	2009-10-18 16:00:37.097	34	NULL	2009-10-18 01:00:23.000	NULL	NULL

Ebből a következőket kell figyelnünk: a db-object-index id-k magukért beszélnek, abból tudjuk, hogy minek is nézzük az adatait. A user seek/scan/lookup és a hozzájuk tartozó last… oszlopok talán a legfontosabbak, ők mutatják meg a tényleges indexhasználatot. Az user_update oszlop érdekes, az index ugyanis akkor update-elődik, ha a tartalmazott adat változik. Ez az úgynevezett indexkarbantartás, ami kissé drága, ezért nem szeretjük a felesleges indexeket. Merő véletlenségből a fenti minta pont tartalmaz egy ilyen indexet, a 3-as számút (egy tábla három indexének az értékeit választottam ki). Látszik, hogy semmi másra nem használja a szerver az indexet, csak karbantartja, frissítgeti. Ez egy tipikus jó jelölt arra, hogy letörölje az ember fia egy vidám hétfő reggelen, ha elég nagy minta alapján még mindig nulla a három mező összege. Volt szerencsém találkozni olyan indexszel, amit 1.1 milliárdszor kellett update-elnie az engine-nek, és soha nem használta. Lehet azt mondani, hogy nem kér enni, de hát szemmel láthatóan ez nem igaz.

Éles szemű egyének észrevehetik, hogy azért a system_scan oszlop értéke egyáltalán nem nulla. Ez anna kköszönhető, hogy az indexstatisztikák frissítéséhez az SQL szerver scannel. Úgyhogy ezt nem kell feltétlenül figyelembe venni.

Mire jó még ez a használati statisztika? Láthatjuk, hogy user_lookup mindig csak az index_id = 1 indexeken történik, azaz a clustered indexen. Természetes, hiszen a bookmark/key lookup itt szokott történni. Lehet, hogy van rá ellenpélda, de azt most kihagynám. És most keressük meg a legnagyobb user_scan értékű indexeket és a hozzájuk tartozó clustered indexeket: ha nagyon magas a clustered indexen a user_lookup érték is és kicsi a scan, akkor találtunk egy jó ellenjelöltet clustered indexre.

És megint, csak egyetlen DMV a sokból, és milyen sok hasznos dolgot árul el… Hát nem csodálatos? (nem, a csodálatos az az, hogy három tesztgépre sikerült három különböző SQL verziót/editiont telepítenem, anélkül, hogy észrevettem volna addig, amíg el nem frakkolt a teszt…)

Visszatérve a címre:

select * from sys.dm_db_index_usage_stats
where object_id > 255
and user_seeks + user_scans + user_lookups = 0
order by database_id, object_id

Ők azok az indexek, akiket a kutya sem használt – az SQL Server legutóbbi indulása óta. Ez a DMV ugyanis minden szerver restartkor kiürül és újrakezdi a feltöltését a szerver. Tehát ha tegnap óta fut a gép, ne használjuk nagytakarításra az outputot. Tanácsos elmenteni a kimenetet – én mindennap elmentem egy külön táblába, és ha nem indult újra előző nap óta a szerver, akkor az előző napit meeg kitörlöm. Így csak legfeljebb egy napi statisztikát veszíthetek, de megvan hónapokra visszamenőleg minden.

UNIQUE és több NULL

admin — Sun, 04 May 2008 22:17:48 +0000

(This article has an English version…)
Ha szeretnénk biztosítani azt, hogy egy oszlop értékei mind egyeidek legyenek, akkor használhatjuk a UNIQUE kulcsszót (akár constraint, akár index formában), hogy ezt kierőszakoljuk. Ez eddig szép és jó, de mi a helyzet a NULL értékekkel? Egy NULL-t simán be tudunk szúrni (ez ugye a nagy különbség a UNIQUE és a PRIMARY KEY között, utóbbi nem enged semmilyen NULL-t), de mi van, ha sok NULL-t akarok bepakolni? Pl. tároljuk az ügyfelek pénzügyi azonosítóját a különféle ki- és befizetések azonosítására, de vannak ügyfeleink, akikkel nincs ilyen pénzügyi kapcsolatunk. A klasszikus ANSI SQL szerint lehet több NULL egy UNIQUE oszlopban, hiszen NULL <> NULL a definíció szerint. A Microsoft által használt megközelítés meg azt mondja, hogy ha megtalálom az értéket a táblában, akkor az nem lehet egyedi. Lehet vitatkozni a nézőpontokon (azt hiszem, meglepő módon a DB2 is az utóbbit használja), mindenesetre változtatni rajta nemigen lehet. Vannak mindenféle érdekes kerülőutak, de mindenesetre, ez elég bosszantó lehet. Annak, aki nem használ SQL Server 2008-at. A SQL 2008-ban bevezetett filtered index nevű feature lehetőséget biztosít arra, hogy ne az egész táblára, csak annak egy részére készítsük el az indexünket. A szintaktika roppant egyszerű:
Hogyan segít ez rajtunk? Hát, egyszerűen: adjuk hozzá azt a feltételt, hogy csak a nem NULL oszlopokra akarunk UNIQUE indexet készíteni. Rövid példa:

CREATE TABLE tempdb.dbo.t1 (col1 int)
CREATE UNIQUE INDEX IX_t1_col1 on tempdb.dbo.t1 (col1)
WHERE col1 IS NOT NULL
-- dobjunk be par sort...
INSERT INTO tempdb.dbo.t1 VALUES (1),(2),(NULL)
--ez bukta
INSERT INTO tempdb.dbo.t1 VALUES (1)
--ez nem bukta
INSERT INTO tempdb.dbo.t1 VALUES (NULL)

És tessék, máris Oracle-kompatibilis UNIQUE-or kaptunk. Jó, mi? :)

UNIQUE INDEX vs multiple NULL values

Erik — Fri, 18 Apr 2008 23:55:46 +0000

In Microsoft SQL Server, if you want to make sure that a column contains no duplicates, you can use the UNIQUE keyword to enforce this constraint, either by creating a unique index or by adding a unique constraint to the column. It’s very useful and nice, but… What about NULL values? I mean, obviously, you can insert the first NULL value, but what if you have more null values and you need to enforce only the uniqueness of the non-null values? (eg. you have to store social security numbers but you have people working in other countries with no SSN) The ANSI standards says that the non-null values should be unique, however, the MSSQL requires all value to be unique, that is, you can have only one null in a unique column. The first approach says that NULL can’t be equal to NULL by definition, so I can handle any number of NULL values. The second approach says that you can’t insert a value into the column which is already there, and I can find a NULL among the values… Whatever, the point is that it can be quite bothering, or to be precise, it could have been bothering as in SQL2008 you have an almost nice workaround for it. The filtered index is a special kind of index which contains the keys for only a subset of the table, filtered by a WHERE clause. So you can create a filtered index this way:

CREATE INDEX ix_filtered ON dbo.MyTable (col1) where col2 > 55

Or if you want to use it to remediate your unique index with multiple NULL values problem, it will look like this:

CREATE INDEX ix_filtered ON dbo.MyTable (col1) where col1 is not null

A short demo:

CREATE TABLE tempdb.dbo.t1 (col1 int)
CREATE UNIQUE INDEX IX_t1_col1 on tempdb.dbo.t1 (col1)
WHERE col1 IS NOT NULL
-- insert a few rows...
INSERT INTO tempdb.dbo.t1 VALUES (1),(2),(NULL)
--this will fail...
INSERT INTO tempdb.dbo.t1 VALUES (1)
-- but this won't...
INSERT INTO tempdb.dbo.t1 VALUES (NULL)

Here you go. It’s quite quick-and-not-so-dirty. :)