How to Think Like the SQL Server Engine, Part 6: Translating SQL into Storage

The query processor builds execution plans, and the storage engine translates those into page reads and writes. Learn how small selects, big selects, and DUI operations turn into disk drive accesses.

[@martinwood9419]

I never really used to care that much about databases. I've always been a full stack guy, and I knew my way around sql relatively well, but I always left the harder work, the performance issues, indexes, all that stuff to more experience developers and I just wrote the SQL that I needed. Recently though I've been doing some sql and even some basic tuning things that I've not only started to enjoy, but was really impressed with myself. Found Brent totally by chance while I was searching for useful tips that I could use to develop myself as a database guy, and frankly I'm loving his guides. The bad humor, I can take or leave ;) but the knowledge and the delivery of teaching is unbeatable! Please keep it up Brent, I'm loving your work :D

[@TheBrentOzar]

Thanks, glad you like our work!

[@RC-nn1ld]

Superb, loving it!

[@LinkMassing]

My biggest question: I understand (and Brent touched on this in another demo) that external index fragmentation is performance impacting when it is needed to be pulled from disk. Depending on the size of the table, will it ever matter if that entire HUGE table (and massively fragmented indexes) is in memory? I understand all those needed pages are held "randomly" in memory but would a terribly fragmented table ever hit a point in memory where there could be benefit to rebuild all those needed indexes? Brent, I again thank you and your team for all the wonderful shared knowledge!

[@tz100000000]

3:31 - Reference to those old Pace Picante Salsa commercials?