I've experienced the random GUID-"problem" upclose in other tables. Index is 98-99% fragmented just a few hours after a defragjob has completed. There's frequent INSERT and DELETE in that table.

A majority is below 3000 characters, most are alot smaller than that.

That LOB overflow stuff is nothing I've touched before (as far as I know anyway).

No, no datacompression here.

Datatypes used are guids, nvarchar(max/XXX), datetime's mostly.

It's difficult and exciting at the same time this stuff. 🙂

Staring at a table now, more than 6,000,000 rows, about 25 columns. Posts are not updated that much, but inserted...

If I've got a table with 20 million rows, and add an index with (alot) of included columns, wouldn't this take just as much storage as the original table.?

I've not designed this thing. I am nowhere near an SQL-expert either, but I do think this world is interesting and am trying to learn, that's why I'm in this...

I'm trying to learn more about indexes but it's so much stuff to learn. 🙂 But very interesting at the same time.

The reason for my uniqueidentifier non-clustered index is getting...

That's interesting hints. Setting the fillfactor here should not prevent, but slow down the current rapid fragmentation I guess?

I'm pretty sure fill factor is configured to "0" for that table...

The Id comes from some C# - code I'm afraid.

Found another script that didn't reported "duplicate" rows..

I'm just trying to force an old (=a few days) queryplan in QueryStore and it looks ok in the UI but when looking in the sys.tables I see this error....

I'm "playing around" with a script that feeds Reporting Services that starts another script. It seems (as far as I can see) the last script starts before the first one...

I've tried doing some basic queries with the sys.query_* tables but well, don't notice anything special. There's lots of data in some tables and it takes a little while to...

Nope. I'm a QueryStore newbie so I'm more comfortable with the UI at the moment. 🙂