sql >> Base de Datos >  >> RDS >> Sqlserver

Mitos dañinos y generalizados sobre el rendimiento de SQL Server

Entre mis viajes, presentaciones y moderación de preguntas y respuestas, hablo con mucha gente sobre una amplia variedad de problemas de rendimiento de SQL Server. Recientemente, he tenido algunas interacciones en las que las personas creen cosas que son completamente incorrectas o solo son correctas en un conjunto muy limitado de casos de uso. Sin embargo, su insistencia en que estas cosas son universalmente ciertas es inquietante.

Entonces, pensé en comenzar una nueva serie para ayudar a acabar con algunos de estos mitos. No para señalar a las personas y demostrar que están equivocadas, sino para detener la propagación. Cuando hacen estas declaraciones generales en su lugar de trabajo, en Twitter o en foros, si no se controlan, pueden "enseñar" a usuarios impresionables o con menos experiencia.

Tenga en cuenta que no pretendo demostrar que estas cosas nunca cierto, porque algunos ciertamente pueden ser ciertos en escenarios aislados o artificiales . Mi objetivo es simplemente demostrar al menos un caso en el que no es cierto; con suerte, esto puede comenzar a cambiar estas mentalidades obstinadas.

Estos son algunos de los "hechos" que me han contado recientemente, sin ningún orden en particular:

  • "Un índice agrupado siempre es mejor que un índice no agrupado"
  • "SQL dinámico hizo que mi consulta fuera lenta"
  • "PIVOT es más rápido que SUM(CASE)"
  • "Los valores NULL siempre causan terribles problemas de rendimiento"
  • "Los planes de ejecución son inútiles excepto por los índices que faltan"
  • "NOLOCK está bien porque mucha gente lo usa"
  • "Está bien sobredimensionar las columnas varchar/nvarchar"

Mientras escribo cada publicación, actualizaré esta página vinculando el elemento correspondiente en la lista anterior.

¿Tiene algún mito de rendimiento que se transmite como un hecho absoluto, pero sospecha (o tal vez incluso sabe) que no siempre es cierto? Házmelo saber en los comentarios a continuación, en Twitter o en [email protected].