Microsoft SQL Server 総合スレ 12

**NAME IS NULL** · 2023/09/21(木) 08:50:54.98

Microsoft SQL Server (Transact-SQL) の総合スレッドです。

・Microsoft 公式サイト
http://www.microsoft.com/japan/sql/

**NAME IS NULL** · 2023/09/29(金) 10:19:10.16

どなたかご存知の方、ご教授お願いします。
SQLSERVER2014を2019(共にSTD)にインプレースアップグレードしました。
その後2014のDBバックアップを2019にリストアしようとすると、以前の数倍掛かる時が出てきました。
また互換性レベルを120に合わせているにも関わらず、2014の時より倍以上遅くなるSQL(ストアド)が見つかり、困っております。
有識者の方、解消のアドバイス宜しくお願い致します。

**NAME IS NULL** · 2023/09/29(金) 12:27:56.66

統計情報に一票

ストアドが遅い原因を推測するには
SQL文、テーブル/インデックス構造、2014/2019それぞれでの実行計画と計測した処理時間が必要

**NAME IS NULL** · 2023/09/29(金) 18:12:42.79

>>3
コメントありがとうございます！
ストアドについては2014と2019、同じバックアップを復元したあと、全く同じ操作をさせたのですが、統計情報が違って実行プランが変わる可能性があるのですね…確認してみます！

**NAME IS NULL** · 2023/10/16(月) 13:06:47.40

これはうれしい誤算だね！

**NAME IS NULL** · 2023/12/03(日) 23:55:20.02

tes

**NAME IS NULL** · 2024/01/26(金) 00:10:54.07

板ふっとんだんだ
こちらも2014から2019にあげたけど倍速になった
2016？で改善されたinsertスレッドマルチ化がめっちゃ効いてる
統計情報更新とか処理時間7割減で終わるようになってもう俺ごときのエンジニアいらんようになった感、、トラックドライバーにでも転職するかなあ

**NAME IS NULL** · 2024/03/26(火) 08:14:29.04

すんません、教えて

declare @Kijunbi datetime;
set @Kijunbi = '2024/03/31';

select Jininbi, Shimei from SampleTable where ( Jininbi is null or Jininbi>@Kijunbi );

Jininbi のデータ型はdatetime ですが、上記のSQLだとJininbiが2024/03/31 のデータが取得出来ないです。

@Kijunbiも、取得したいデータのJininbi列の値も
'2024-03-31 00:00:00.000' とかだと思うのですが…

**NAME IS NULL** · 2024/03/26(火) 08:35:04.38

ああなんか勘違いしておりました…

**NAME IS NULL** · 2024/04/06(土) 14:14:49.98

test