SQL 성능에 linq에 대한 많은 기사를 읽었습니다. 내가 얻은 결과는 일반적인 접근 방식 (DAL 또는 Microsoft Enterprise 라이브러리)보다 느리다는 것입니다.성능 튜닝 후에도 읽기 및 쓰기 작업 모두가 느려짐ObjectTracking 및 기타 트릭을 비활성화하십시오. 빠른 개발, 깨끗한 코드 등의 발음이 있지만 성능은 어떻습니까?
내가 읽기 작업에만 사용한다면 어떨까요?
제안을 해주십시오.
stackoverflow ;-p에 대해 충분히 잘 작동하는 것 같습니다. 특히 사용하는 경우컴파일 된 쿼리, 적절한 DB 디자인과 비교하고 (예를 들어) 적절한 열 / 행을 가져 오는 것과 n + 1 로딩을 피하는 것과 같은 병목 현상이 발생하지는 않습니다.
읽기 작업의 경우 LINQ To SQL은 SQL을 직접 작성하는 것만 큼 빨라야합니다. SQL 작성의 오버 헤드는 눈에 띄지 않아야합니다. 수작업으로 쿼리를 작성한 것처럼 최적으로 처리되지 않는 쿼리가있을 수 있지만 대부분의 경우 내 경험에 비추어 볼 때 매우 좋습니다.
대량 업데이트의 경우 LINQ To SQL은 한 번에 하나씩 행을 처리하기 때문에 일반적으로 속도가 느립니다. 너는 뭔가를 할 수 없다.UPDATE Foo SET x = 0 WHERE id BETWEEN 100 AND 200모든 행을 가져 오지 않고 LINQ to SQL에서. 현재이 유형의 조작을 위해 SQL을 직접 작성하는 것이 가장 좋습니다.
업데이트 및 삭제는 영향을받는 각 개체에 대해 별도의 문이 생성되므로 LINQ to SQL이 현재 문제가되는 부분입니다.
즉,이 블로그 게시물은 성능을 향상시키는 데 도움이되는 두 가지 작업을 모두 하나의 명령문으로 처리하는 방법을 자세히 설명합니다.LINQ to SQL을 통한 일괄 업데이트 및 삭제.
컴파일 된 쿼리는 자주 사용되는 쿼리, 특히 매개 변수를 사용하여 특정 결과를 얻는 쿼리에도 유용합니다. 이 게시물이 도움이 될 수도 있습니다.LINQ to SQL 응용 프로그램 성능 향상을위한 10 가지 팁.