Domande di intervista SQL Server: Come spiegare il tuo ragionamento sui database ad alta voce

Le domande di intervista SQL Server raramente si fermano al richiamo della sintassi. Un panel sa già che puoi cercare la clausola JOIN corretta o la funzione finestra. Quello che stanno testando è se puoi ragionare su un problema di database in tempo reale e spiegare questo ragionamento a qualcun altro, sia che quella persona sia un DBA collega, uno sviluppatore di applicazioni o una parte interessata non tecnica.

Per i ruoli di traccia DBA, aspettati un peso maggiore su backup, modelli di recupero, manutenzione degli indici e configurazione del server. Per i ruoli di traccia sviluppatore, aspettati un peso maggiore su modelli T-SQL, progettazione delle query e come il tuo codice interagisce con l'ottimizzatore di query. La maggior parte delle aziende miscela entrambi, perché uno sviluppatore che comprende l'indicizzazione scrive query più veloci, e un DBA che comprende la logica dell'applicazione fornisce migliori consigli di ottimizzazione.

Una domanda di apertura comune è qualcosa come "guidami nella progettazione della strategia di indicizzazione per una nuova tabella di reporting." Non c'è una singola risposta corretta, quindi l'intervistatore sta veramente valutando il tuo processo: come chiarisci prima i modelli di query, come consideri la performance di lettura rispetto al costo di scrittura, e come convalideresti la scelta in seguito con dati reali invece di indovinare.

Il filo conduttore attraverso ogni buona risposta è la narrazione. Dì cosa verificheresti per primo, perché lo verificheresti e cosa il risultato ti direbbe. Gli intervistatori stanno ascoltando un processo decisionale, non una definizione memorizzata, e questa abitudine di pensare ad alta voce vale la pena di essere praticata prima di sedersi mai di fronte a un panel.

Le domande su indicizzazione sono il checkpoint tecnico più comune in un'intervista SQL Server. Probabilmente ti verrà chiesto di descrivere la differenza tra un indice cluster e un indice non cluster, quando un indice di copertura aiuta, e come accelereresti una query che funziona lentamente.

Struttura la tua risposta attorno a un percorso diagnostico reale invece di una definizione da libro di testo. Inizia con il piano di esecuzione: "Prenderei il piano di esecuzione effettivo e cercherei uno scan dove mi aspetto un seek, poi verificherei se le colonne di predicato sono indicizzate." Spiega qual è il costo di una ricerca di chiave e quando l'aggiunta di una colonna inclusa la rimuove. Menziona le statistiche: le statistiche obsolete possono fare scegliere al compilatore un piano non ottimale anche quando l'indice giusto esiste, e un aggiornamento di statistiche non aggiornate è una delle prime cose che i candidati esperti controllano.

Agli intervistatori piace anche approfondire ulteriormente con domande di follow-up su indici filtrati, fattore di riempimento e frammentazione dell'indice. Sii pronto a spiegare che un indice filtrato copre solo un subset di righe e può ridurre drasticamente un indice su una colonna per lo più nulla o per lo più inattiva, e che il fattore di riempimento scambia dello spazio sprecato oggi per meno divisioni di pagina più tardi su una tabella con inserimenti pesanti.

Risposte di esempio: "Una query di report si stava timeout perché filtrava su una colonna senza indice e univa tre tabelle grandi. Ho tirato il piano, ho visto uno scan dell'indice cluster e un ordinamento costoso, ho aggiunto un indice non cluster sulla colonna di filtro con colonne incluse per l'elenco SELECT, ho aggiornato le statistiche, e lo scan si è trasformato in un seek. La durata è scesa da dodici secondi a meno di uno." Quel tipo di storia specifica causa-effetto è quello che separa una risposta forte da una generica.

Oltre alle istruzioni SELECT di base, gli intervistatori di solito indagano su una manciata di aree T-SQL: funzioni finestra come ROW_NUMBER, RANK e DENSE_RANK, espressioni di tabella comune rispetto a tabelle temporanee, logica basata su set rispetto a cursori, e come NULL si comporta nei confronti e nelle aggregate.

Quando ti viene chiesto perché eviteresti un cursore, non dire solo "i cursori sono lenti." Spiega il meccanismo: un cursore elabora le righe una alla volta, mentre una query basata su set consente al compilatore di lavorare sull'intero set di risultati contemporaneamente, che è quasi sempre più veloce su larga scala. Se un cursore è genuinamente lo strumento giusto, ad esempio in uno script amministrativo che deve essere eseguito in una sequenza rigorosa, dilo e spiega perché.

Potrebbe anche essere chiesto di confrontare una tabella temporanea e una variabile di tabella. Una buona risposta copre l'ambito, il comportamento della registrazione delle transazioni, e il fatto che il compilatore crea statistiche per le tabelle temporanee ma non per le variabili di tabella, il che conta per i piani di query su numeri di righe più grandi. Mantieni la spiegazione pratica: descrivi quando hai effettivamente scelto l'una o l'altra e cosa è cambiato di conseguenza.

Aspettati almeno una domanda sui tipi di join e la costruzione di query: la differenza tra un INNER JOIN e un LEFT JOIN, quando un CROSS APPLY è utile per la logica riga per riga che un JOIN semplice non può esprimere, e come un'istruzione MERGE può combinare un insert, update e delete in un'unica operazione. Potresti anche ricevere una breve domanda sulla gestione degli errori con TRY/CATCH e come XACT_ABORT cambia il comportamento di rollback all'interno di una transazione. Rispondi a ciascuno nominando una situazione reale in cui l'hai usato, non solo la sintassi.

Le domande di progettazione verificano se pensi a uno schema prima di pensare a una query. Aspettati una domanda sulla normalizzazione: perché dividere i dati in tabelle correlate riduce le anomalie di aggiornamento, e quando denormalizzare intenzionalmente una tabella per la performance di lettura è un compromesso ragionevole piuttosto che un errore.

Sii pronto a spiegare la differenza tra una chiave primaria e un vincolo univoco, perché una chiave esterna è importante anche quando l'applicazione applica la relazione nel codice, e come sceglieresti tra una chiave naturale e una chiave surrogata per una nuova tabella. Se viene chiesto su una colonna di identità rispetto a un GUID come chiave primaria, menziona l'impatto pratico: un'identità sequenziale mantiene efficienti gli inserimenti dell'indice cluster, mentre un GUID casuale può frammentare rapidamente l'indice a meno che non usi una variante sequenziale.

Una domanda di follow-up orientata alla progettazione potrebbe chiederti di disegnare uno schema per uno scenario specifico, come un sistema di ordini con clienti, prodotti e voci di riga. Narrata il tuo ragionamento: quali entità hanno bisogno della propria tabella, quali colonne dovrebbero essere indicizzate per i modelli di query attesi, e dove un vincolo catturerebbe un inserimento non valido prima che diventi un problema di qualità dei dati a valle.

Le domande su backup e recupero verificano se comprendi i compromessi alla base di una strategia di recupero, non solo i comandi. Sii pronto a spiegare i tre modelli di recupero: semplice, completo e registrazione in massa, e come ciascuno influisce sul fatto che il recupero point-in-time sia anche possibile.

Cammina attraverso la differenza tra un backup completo, un backup differenziale e un backup del log delle transazioni, e come si combinano durante un ripristino. Gli intervistatori spesso seguono con uno scenario: il database è fallito alle 14:00, l'ultimo backup completo era ieri sera, e hai backup dei log ogni quindici minuti. Rispondi nominando la sequenza di ripristino e il punto di recupero risultante, quindi collegalo a RPO e RTO in termini semplici: quanta perdita di dati è accettabile e quanto velocemente il sistema ha bisogno di tornare.

Gli intervisti più senior potrebbero anche chiederti di confrontare le opzioni di alta disponibilità a livello concettuale: come i gruppi di disponibilità Always On differiscono dalla spedizione dei log, e perché un'azienda potrebbe comunque scegliere l'opzione più semplice anche se si recupera più lentamente. Non hai bisogno di avere configurato ogni opzione, ma dovresti essere in grado di spiegare quale problema risolve ciascuno.

Se hai gestito un ripristino reale o un failover, descrivilo brevemente: cosa si è rotto, quale catena di backup hai usato, quanto tempo ha preso il ripristino, e cosa hai cambiato dopo per ridurre la finestra di recupero la prossima volta. Menzionare che testi effettivamente i ripristini secondo una pianificazione, piuttosto che assumere che un file di backup sia buono fino a prova contraria, è il genere di dettaglio che segnala una vera esperienza operativa.

Le domande sulle transazioni verificano se comprendi cosa succede quando più utenti toccano gli stessi dati contemporaneamente. Inizia da ACID: atomicità, coerenza, isolamento e durabilità, poi sposta rapidamente qualcosa di più concreto dell'acronimo.

Sii pronto a confrontare i livelli di isolamento: lettura impegnata, che è l'impostazione predefinita di SQL Server, rispetto a lettura non impegnata, lettura ripetibile, serializzabile e isolamento snapshot. Spiega quale problema risolve ciascuno, come letture sporche o letture fantasma, e quale costa in concorrenza. Un candidato forte può anche descrivere come l'isolamento snapshot utilizza il versionamento delle righe in tempdb invece di bloccare i lettori contro gli scrittori, e perché potrebbe scambiare memoria e carico tempdb per meno reclami di blocco dai team delle applicazioni.

Le domande sui deadlock si presentano spesso. Descrivi come identificarne uno usando il grafico deadlock in Extended Events, spiega cosa sia effettivamente un deadlock, due sessioni ognuna in possesso di un blocco di cui l'altra ha bisogno, e descrivi una correzione come il riordino coerente dell'accesso alle tabelle o l'accorciamento della transazione. Se l'intervistatore chiede dei suggerimenti di blocco come NOLOCK o ROWLOCK, spiega il compromesso in termini semplici: NOLOCK evita il blocco ma può restituire righe non impegnate o duplicate, quindi appartiene alle query di reporting in cui i risultati approssimativi sono accettabili, non nei calcoli finanziari.

Un candidato che può narrare un'indagine su deadlock passo dopo passo, dal notare il timeout, al tirare il grafico, all'identificazione della query da riscrivere, di solito si distingue più di uno che definisce solo il termine.

Una domanda di intervista SQL Server frequente ti chiede di passare attraverso la diagnosi di un server che improvvisamente rallenta. Trattalo come una narrazione di risoluzione dei problemi dal vivo, non come un elenco di strumenti. Inizia con quello che controlleresti per primo: statistiche di attesa correnti, richieste attive e sessioni di blocco, utilizzando viste come sys.dm_exec_requests, sys.dm_exec_sessions e sys.dm_os_wait_stats.

Spiega come diresti la differenza tra un problema legato alla CPU, un problema legato all'I/O e una catena di blocco nominando i tipi di attesa che cercheresti, come le attese PAGEIOLATCH che indicano pressione del disco o le attese LCK_M_X che indicano blocco. Menziona la contesa tempdb come una causa comune ma spesso trascurata di rallentamento inspiegabile, specialmente su server con attività di tabella temporanea o ordinamento pesante, e menziona lo sniffing dei parametri come una causa di una query che è veloce per un input e lenta per un altro usando lo stesso piano memorizzato nella cache.

Se l'intervistatore spinge ulteriormente, descrivi come isoleresti la query specifica: acquisendo una traccia o una sessione Extended Events, quindi esaminando il piano di esecuzione dell'istruzione offensiva e confrontando i conteggi di righe stimati rispetto a quelli effettivi per confermare se una stima errata sta guidando il rallentamento.

Gli intervistatori fanno queste domande basate su scenari perché leggere una definizione da una diapositiva è facile, ma narrare un'indagine dal vivo sotto pressione di tempo non lo è. Pratichare la sequenza ad alta voce, nell'ordine in cui lo faresti effettivamente, rende la differenza ovvia a chiunque ascolti.

Crea un breve elenco di scenari reali dal tuo lavoro: una correzione di indicizzazione, un'indagine su deadlock o blocco, una situazione di backup o ripristino, e una riscrittura di query che ha migliorato le prestazioni. Per ciascuno, annota il sintomo, i tuoi passaggi diagnostici, la correzione e il risultato misurabile.

Poi pratica a dire ogni storia ad alta voce, non solo leggerla in silenzio. Gli intervisti tecnici premiano i candidati che riescono a spiegare una decisione chiaramente sotto pressione di tempo, e quella competenza non viene dalla rilettura delle note. SayNow ti permette di provare le domande di intervista SQL Server con prompt di follow-up realistici, quindi ti abitui a spiegare un piano di esecuzione o una scelta di livello di isolamento nella conversazione invece che nella tua testa per la prima volta durante l'intervista effettiva.

Prova ad alta voce anche espone i vuoti che la revisione silenziosa nasconde. È comune pensare di comprendere i livelli di isolamento chiaramente fino a quando non cerchi di spiegare l'isolamento snapshot a un'altra persona e realizzi che la tua spiegazione si perde a metà. Scoprirlo nella pratica è molto meglio che scoprirlo davanti a un panel di personale.

Infine, prepara alcune domande tue: come il team monitora le prestazioni delle query, quale sia il processo di test di backup e recupero, o come le modifiche dello schema vengono riviste. Le domande ponderose segnalano lo stesso giudizio operativo che l'intervista stava testando in primo luogo.