SQLServer 2000 升级到 SQLServer 2008 性能之需要注意的地方之
今天在 相同环境测试 2000 和 2008 性能 让我意外的是 2008 明显比2000 慢很多,因为不能简单的升级,sql语句也需要优化
测试sql:代码如下:
SET STATISTICS IO ON
SET STATISTICS TIME ON
SELECT COUNT(1)
FROM dbo.tbtext a
INNER LOOP JOIN dbo.tbtext b
ON a.id = b.id option (maxdop 1)
SET STATISTICS IO Off
SET STATISTICS TIME Off
表结构:
代码如下:
CREATE TABLE [dbo].[tbtext](
[id] [int] IDENTITY(1,1) NOT NULL,
[VALUE] [int] NULL
) ON [PRIMARY]
单这句测试,看执行计划根本看不出区别。
|--Compute Scalar(DEFINE:([Expr1006]=CONVERT_IMPLICIT(int,[Expr1009],0)))
|--Stream Aggregate(DEFINE:([Expr1009]=Count(*)))
|--Nested Loops(Inner Join, WHERE:([northwind].[dbo].[tbtext].[id] as [b].[id]=[northwind].[dbo].[tbtext].[id] as [a].[id]))
|--Table Scan(OBJECT:([northwind].[dbo].[tbtext] AS [a]))
|--Table Spool
|--Table Scan(OBJECT:([northwind].[dbo].[tbtext] AS [b]))
2008r2:
代码如下:
/*
警告: 由于使用了本地联接提示,联接次序得以强制实施。
表 'tbtext'。扫描计数 1,逻辑读取 46 次
(1 行受影响)
表 'Worktable'。扫描计数 1,逻辑读取 290098 次,物理读取 0 次,预读 0 次,lob 逻辑读取 0 次,lob 物理读取 0 次,lob 预读 0 次。
表 'tbtext'。扫描计数 2,逻辑读取 262 次,物理读取 0 次,预读 0 次,lob 逻辑读取 0 次,lob 物理读取 0 次,lob 预读 0 次。
(1 行受影响)
SQL Server 执行时间:
CPU 时间 = 32828 毫秒,占用时间 = 32846 毫秒。
SQL Server 执行时间:
CPU 时间 = 0 毫秒,占用时间 = 0 毫秒。
*/
2000sp4:
代码如下:
/*
警告: 由于使用了局部联接提示,所以联接次序得以强制实施。
表 'tbtext'。扫描计数 1,逻辑读 131 次,物理读 0 次,预读 0 次。
SQL Server 执行时间:
CPU 时间 = 0 毫秒,耗费时间 = 0 毫秒。
表 'Worktable'。扫描计数 9999,逻辑读 180001 次,物理读 0 次,预读 0 次。
表 'tbtext'。扫描计数 2,逻辑读 262 次,物理读 0 次,预读 138 次。
SQL Server 执行时间:
CPU 时间 = 17188 毫秒,耗费时间 = 17261 毫秒。
(1 行受影响)
SQL Server 执行时间:
CPU 时间 = 0 毫秒,耗费时间 = 0 毫秒。
*/
比较2000 和 2008的执行就能发现 2008 的cpu 时间明显比 2000 高,2008 的worktable 逻辑读取量,比2000的高,
这个有个worktable 的扫描技术,2000的是9999,2008的是1,这个让人难免有的疑惑是什么情况,都是nest loop,worktable 扫描不应该是1才对。
性能差怎么大会不会是 worktable 搞的鬼呢?
那么就开始调节,过滤id 会有啥发现呢?
代码如下:
SET STATISTICS IO ON
SET STATISTICS TIME ON
SELECT COUNT(1)
FROM dbo.tbtext a
INNER LOOP JOIN dbo.tbtext b
ON a.id = b.id
WHERE a.id SELECT COUNT(1)
FROM dbo.tbtext a
SET STATISTICS IO Off
SET STATISTICS TIME Off
2008r2:
SELECT COUNT(1) FROM dbo.tbtext a INNER LOOP JOIN dbo.tbtext b ON a.id = b.id WHERE a.id |--Compute Scalar(DEFINE:([Expr1006]=CONVERT_IMPLICIT(int,[Expr1009],0)))
|--Stream Aggregate(DEFINE:([Expr1009]=Count(*)))
|--Nested Loops(Inner Join, WHERE:([northwind].[dbo].[tbtext].[id] as [b].[id]=[northwind].[dbo].[tbtext].[id] as [a].[id]))
|--Table Scan(OBJECT:([northwind].[dbo].[tbtext] AS [a]), WHERE:([northwind].[dbo].[tbtext].[id] as [a].[id]|--Table Spool
|--Table Scan(OBJECT:([northwind].[dbo].[tbtext] AS [b]), WHERE:([northwind].[dbo].[tbtext].[id] as [b].[id] 代码如下:
表 'Worktable'。扫描计数 1,逻辑读取 6006 次,物理读取 0 次,预读 0 次,lob 逻辑读取 0 次,lob 物理读取 0 次,lob 预读 0 次。
表 'tbtext'。扫描计数 2,逻辑读取 262 次,物理读取 0 次,预读 0 次,lob 逻辑读取 0 次,lob 物理读取 0 次,lob 预读 0 次。
2000sp4:
|--Compute Scalar(DEFINE:([Expr1002]=Convert([Expr1006])))
|--Stream Aggregate(DEFINE:([Expr1006]=Count(*)))
|--Nested Loops(Inner Join, WHERE:([b].[id]=[a].[id]))
|--Table Scan(OBJECT:([Northwind].[dbo].[tbtext] AS [a]), WHERE:([a].[id]|--Table Spool
|--Table Scan(OBJECT:([Northwind].[dbo].[tbtext] AS [b]))
代码如下:
表 'Worktable'。扫描计数 999,逻辑读 27001 次,物理读 0 次,预读 0 次。
表 'tbtext'。扫描计数 2,逻辑读 262 次,物理读 0 次,预读 0次。
进入 lazy spool的数据完全不一样了,2008 只是进入了1000 条数据,但是2000 全都进去了。
在逻辑读上面 2008 明显低于 2000. cpu时间也明显比2000少。
通过调节id 的值,2000 我推出了一个公式 逻辑读= 10001+(17*n) ,
但是2008的算法十分奇怪,
当n 当 3862000的逻辑读是线性增长,2008 是分段的线性增长,每个分段 f '(x) 都不一样。
2008 的lazy spool适合选择度高的,选择度低的时候完全不行。
从2000到2008 不单单是多了sqlos和表面上的一些功能,很多执行计划的操作符都被重写了,像lazy spool 。
所以在升级到2008 之前,
各位朋友,是否都应该重写一下sql 呢?单单优化 索引 已经解决不了根本问题了。

ホットAIツール

Undresser.AI Undress
リアルなヌード写真を作成する AI 搭載アプリ

AI Clothes Remover
写真から衣服を削除するオンライン AI ツール。

Undress AI Tool
脱衣画像を無料で

Clothoff.io
AI衣類リムーバー

AI Hentai Generator
AIヘンタイを無料で生成します。

人気の記事

ホットツール

メモ帳++7.3.1
使いやすく無料のコードエディター

SublimeText3 中国語版
中国語版、とても使いやすい

ゼンドスタジオ 13.0.1
強力な PHP 統合開発環境

ドリームウィーバー CS6
ビジュアル Web 開発ツール

SublimeText3 Mac版
神レベルのコード編集ソフト(SublimeText3)

ホットトピック









vivox100s と x100 携帯電話はどちらも vivo の携帯電話製品ラインの代表的なモデルであり、それぞれ異なる時代における vivo のハイエンド技術レベルを代表するものであるため、2 つの携帯電話にはデザイン、性能、機能に一定の違いがあります。この記事では、消費者が自分に合った携帯電話をより適切に選択できるように、これら 2 つの携帯電話を性能比較と機能分析の観点から詳しく比較します。まずはvivox100sとx100の性能比較を見てみましょう。 vivox100s には最新の機能が搭載されています。

このチュートリアルでは、Windows 11 の隠れたパフォーマンス オーバーレイを明らかにするのに役立ちます。 Windows 11 のパフォーマンス オーバーレイ機能を使用すると、システム リソースをリアルタイムで監視できます。コンピューター画面上でリアルタイムの CPU 使用率、ディスク使用率、GPU 使用率、RAM 使用率などを表示できます。これは、ゲームをプレイしているときや大規模なグラフィック プログラム (ビデオ エディターなど) を使用しているときに、特定のプログラムの使用時にシステム パフォーマンスがどの程度影響を受けるかを確認する必要がある場合に便利です。システム パフォーマンスを監視するための優れた無料ソフトウェアがいくつかあり、リソース モニターなどの組み込みツールを使用してシステム パフォーマンスをチェックできますが、パフォーマンス オーバーレイ機能にも利点があります。たとえば、現在使用しているプログラムやアプリを終了する必要はありません。

Windows 10 と Windows 11 のパフォーマンス比較: どちらが優れていますか?テクノロジーの継続的な開発と進歩により、オペレーティング システムは常に更新され、アップグレードされます。世界最大のオペレーティング システム開発者の 1 つとして、Microsoft の Windows シリーズ オペレーティング システムは常にユーザーから大きな注目を集めてきました。 2021 年、Microsoft は Windows 11 オペレーティング システムをリリースし、広範な議論と注目を引き起こしました。では、Windows 10 と Windows 11 のパフォーマンスの違いは何でしょうか?

Windows オペレーティング システムは、常にパーソナル コンピューターで最も広く使用されているオペレーティング システムの 1 つであり、最近 Microsoft が新しい Windows 11 システムを発売するまで、Windows 10 は長い間 Microsoft の主力オペレーティング システムでした。 Windows 11 システムのリリースに伴い、Windows 10 と Windows 11 システムのパフォーマンスの違いに関心が集まっていますが、どちらの方が優れているのでしょうか?まずはWを見てみましょう

モバイルインターネットの時代において、スマートフォンは人々の日常生活に欠かせないものになりました。多くの場合、スマートフォンのパフォーマンスはユーザー エクスペリエンスの品質に直接影響します。スマートフォンの「頭脳」であるプロセッサーの性能は特に重要です。市場では、Qualcomm Snapdragon シリーズは常に強力なパフォーマンス、安定性、信頼性の代表格であり、最近では Huawei も独自の Kirin 8000 プロセッサを発売し、優れたパフォーマンスを備えていると言われています。一般ユーザーにとって、性能の良い携帯電話をいかに選ぶかは重要な課題となっている。今日はそうします

PHP と Go は一般的に使用される 2 つのプログラミング言語であり、それぞれに異なる特徴と利点があります。その中でも性能差は誰もが一般的に気にする問題です。この記事では、パフォーマンスの観点から PHP 言語と Go 言語を比較し、具体的なコード例を通じてパフォーマンスの違いを示します。まずは、PHPとGo言語の基本的な機能を簡単に紹介します。 PHP は、もともと Web 開発用に設計されたスクリプト言語で、学習と使用が簡単で、Web 開発の分野で広く使用されています。 Go 言語は、Google によって開発されたコンパイル言語です。

Ollama は、Llama2、Mistral、Gemma などのオープンソース モデルをローカルで簡単に実行できるようにする非常に実用的なツールです。この記事では、Ollamaを使ってテキストをベクトル化する方法を紹介します。 Ollama をローカルにインストールしていない場合は、この記事を読んでください。この記事では、nomic-embed-text[2] モデルを使用します。これは、短いコンテキストおよび長いコンテキストのタスクにおいて OpenAI text-embedding-ada-002 および text-embedding-3-small よりも優れたパフォーマンスを発揮するテキスト エンコーダーです。 o が正常にインストールされたら、nomic-embed-text サービスを開始します。

さまざまな Java フレームワークのパフォーマンス比較: REST API リクエスト処理: Vert.x が最高で、リクエスト レートは SpringBoot の 2 倍、Dropwizard の 3 倍です。データベース クエリ: SpringBoot の HibernateORM は Vert.x や Dropwizard の ORM よりも優れています。キャッシュ操作: Vert.x の Hazelcast クライアントは、SpringBoot や Dropwizard のキャッシュ メカニズムよりも優れています。適切なフレームワーク: アプリケーションの要件に応じて選択します。Vert.x は高パフォーマンスの Web サービスに適しており、SpringBoot はデータ集約型のアプリケーションに適しており、Dropwizard はマイクロサービス アーキテクチャに適しています。
