Można zapewne wymienić wiele powodów, jednak jednym z najistotniejszych jest to, że programiści nadużywają tej funkcjonalności w sytuacjach, gdy istnieje alternatywa w postaci operacji na zestawach danych, co przekłada się zazwyczaj na wyższe obciążenie serwera. Drugą bardzo istotną kwestią jest stosowanie kursorów tam, gdzie istnieje bardziej efektywna alternatywa, np. złączenia, podzapytania, CTE, funkcje, lub obiekty CLR.

Poruszając temat wydajności kursorów, należy pamiętać, że wpływ na nią mają m.in. ustawienia definiowane podczas tworzenia kursora. Wśród ustawień szczególnie istotne są: zakres (LOCAL/GLOBAL), sposób dostępu (FORWARD_ONLY/SCROLL) oraz tryb dostępu (READ_ONLY/FOR UPDATE).

Dla referencji składnia deklaracji kursora:

DECLARE cursor_name CURSOR [ LOCAL | GLOBAL ] 
     [ FORWARD_ONLY | SCROLL ] 
     [ STATIC | KEYSET | DYNAMIC | FAST_FORWARD ] 
     [ READ_ONLY | SCROLL_LOCKS | OPTIMISTIC ] 
     [ TYPE_WARNING ] 
     FOR select_statement 
     [ FOR UPDATE [ OF column_name [ ,...n ] ] ]

Efektywne przetwarzanie danych można uzyskać np. w lokalnym kursorze ustawiając opcje tworzenia kursora na FAST_FORWARD (FORWARD_ONLY, READ_ONLY).

Szczegółową analizę sytuacji prezentującej wady kursora można znaleźć np. w artykule:

http://blogs.msdn.com/b/sqlprogrammability/archive/2008/03/18/increase-your-sql-server-performance-by-replacing-cursors-with-set-operations.aspx